Develop Reference

Securing access to .NET Web API from both MVC client app and mobile applications

I have created a Web API application, an MVC application, and a mobile application.
The Web API should be decoupled from the other two applications as much as possible. I'm using the Password Grant flow here: clients using the Web API needs to send a POST to /Token with username and password. The returned access token is then used for further calls to the API using standard Authorization: Bearer <access_token>.
The MVC application is only accessible for a select few users, and it has its own database which contains the information and roles of these users. Some parts of the MVC application should be restricted to only one or two users (for example), while other parts should be accessible for all registered users. This can be done by using Authorize attributes on the specific controllers within the MVC application - all good. Furthermore, the MVC application should be able to interact with the Web API.
Secondly, I want to have a mobile application to be able to interact with the Web API. A key point here is that I won't require users to register in the app. So essentially, (how it's in my head right now) the only thing the API would see is "this token belongs to the "AndroidApp" user and has password X - sure thing, you're known to me, I'll grant you access". This seems to me a bit 'insecure', meaning that all users of the mobile app will share the same auth credentials.
Questions:
User A is one of the users who are allowed to access the MVC application - I want him to be recognized by both the MVC app, and thereafter the Web API. Is there an easy way to synchronize data between two databases, or should I just register him in both databases (one for MVC, one for API)? There is probably a better third option I haven't thought about.
User B is a user of the mobile application, and he should not be able to access the MVC application. How can this be ensured? Obviously, the MVC user database won't have any info about mobile app users. I'm just wondering about the security aspect of just having one single pair of auth credentials embedded in the app - doesn't sound good to me.
I stumbled upon this question, which basically is the same as mine. But I don't really see the need for Authorization Code Grant flow for the web app (MVC application in my case) as the accepted answer suggests.
I hope my questions make sense, otherwise please let me know :)

My answer doesn't directly answer your question but rather offers an alternative.
In the past when developing similar solutions I've used a specialist third party identity service Auth0.
With Auth0 you can have different application keys, profiles and also create rules (webhooks) which are executed as part of the authentication pipeline. They offer a range of social login as well as AD integration. They offer free and paid pricing.
I am not affiliated with Auth0 in any way, but will use their service as the starting point for any projects going forward - Yes it's a really impressive service!

Single login across multiple domain asp.net [duplicate]

I am tasked with implementing single sign-on for our customers as part of our next release. The flow exists as follows:
User logs into their school's main portal system using a student id/password provided to him/her by the school.
User clicks the link to my company's product.
User is automatically taken to the dashboard page as if they had just logged in through the login form on our site.
Thus, there are two mechanisms by which a user can be authenticated into our site:
Coming to our product's home page, and logging in using the email/password that we store in our local system.
Using the single sign-on where the student has already logged into the school's main system with a student id and password.
If our product's implementation is in ASP.NET (as opposed to Java/Ruby), should we be using CAS, JOSSO, or some other third party single sign-on product? Or is there something available to a .NET environment which would be simpler for us as a .NET company?

There are multiple options to implement SSO for a .NET application.
Check out the following tutorials online:
Basics of Single Sign on, July 2012
http://www.codeproject.com/Articles/429166/Basics-of-Single-Sign-on-SSO
GaryMcAllisterOnline: ASP.NET MVC 4, ADFS 2.0 and 3rd party STS integration (IdentityServer2), Jan 2013
http://garymcallisteronline.blogspot.com/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
The first one uses ASP.NET Web Forms, while the second one uses ASP.NET MVC4.
If your requirements allow you to use a third-party solution, also consider OpenID. There's an open source library called DotNetOpenAuth.
For further information, read MSDN blog post Integrate OpenAuth/OpenID with your existing ASP.NET application using Universal Providers.
Hope this helps!

I am late to the party, but for option #1, I would go with
IdentityServer3(.NET 4.6 or below) or IdentityServer4 (compatible with Core) .
You can reuse your existing user store in your app and plug that to be IdentityServer's User Store. Then the clients must be pointed to your IdentityServer as the open id provider.

There are several Identity providers with SSO support out of the box, also some third-party** services.
** The only problem with third-party services is that they might charge per user/month, which can be pretty expensive.
Some of the tools available and with APIs for .NET are:
Auth0
IdentityExpress (with Admin UI) by IdentityServer
Centrify Identity Service
Okta Identity (SAML 2.0)
OneLogin
If you decide to go with your implementation, you could use the frameworks below categorized by programming language.
C#:
IdentityServer3 (OAuth/OpenID protocols, OWIN/Katana)
IdentityServer4 (OAuth/OpenID protocols, ASP.NET Core)
OAuth 2.0 by Okta
JavaScript:
passport-openidconnect (node.js)
oidc-provider (node.js)
openid-client (node.js)
Python:
pyoidc
Django OIDC Provider
I would go with Auth0 as a service, as it's free for the first 7000 users, supports many languages, and not much needs to be done. However, if you need a more robust, manage yourself, and cheaper solution, I would configure IdentityServer4 and ASP.NET Core application and add authentication providers as necessary.
Both Auth0 and IdentityServer4 solutions use OAuth/OpenID protocols, supporting also WS-Federation and SAML 2.0 integration.

[disclaimer: I'm one of the contributors]
We built a very simple free/opensource component that adds SAML support for ASP.NET apps https://github.com/jitbit/AspNetSaml
Basically it's just one short C# file you can throw into your project (or install via Nuget) and use it with your app

UltimateSAML SSO is an OASIS SAML v1.x and v2.0 specifications compliant .NET toolkit. It offers an elegant and easy way to add support for Single Sign-On and Single-Logout SAML to your ASP.NET, ASP.NET MVC, ASP.NET Core, Desktop, and Service applications. The lightweight library helps you provide SSO access to cloud and intranet websites using a single credentials entry.
Detailed UltimateSAML SSO review can be found here

Abstracting out the OWIN authentication in an MVC web application

I'm working on a solution with others where we have built on a Visual Studio Web Project using MVC (5 I think) and WebApi2.0.
The nature of the solution is that it has 2 DALs, one of the DALs uses SQL to access another applications database, the other DAL uses entityframework codefirst to manage our applications database. There is also a service that is associated with the project so we have done our best to adapt the entire solution into a 3 tier pattern. This means there is a project that contains our BusinessLogic and both our service and our Controllers use it to access the DAL.
So all that out of the way...We are now adding in authentication on the web side. We were stuck for days until we really just embraced Microsoft's default project structure with the OWIN authentication. The downside is that we now have a separate User database that is essentially coupled with the Presentation/Web layer of the solution.
Is there any way to keep all the convenience of the default OWIN authentication in the MVC project AND abstract it out into the LogicLayer? I can't post what we've worked on, but needless to say it's failed every time because we are really struggling to identify what is being done for us behind the scenes (one example is the [assembly: OwinStartupAttribute(typeof(AlarmAggregator.Startup))] annotation). This annotation alone makes me think we will NOT be able to abstract it out.
I know I'm asking to have my cake and eat it too, but I was hoping someone had some insight if it was possible.
At the very least we were hoping there was a way that we could combine our internal database and our user database? I think this would have to happen at the context level? Would it be as simple as pointing our web.config at our internal context?

Since you have not mentioned what those 2 databases are, I assume they are not user databases and out of context. Focusing on the user identity storage, yes its going to be a separate entity unless you are using ADFS, LDAP or something. I would discourage you from building your own identity solution, rather look out for something more widely used and accepted because its a security topic.
Take a look at Thinktecture Identity Server. Its an OpenId Connect based open source solution built in .NET. It comes with its own database, supports same domain SSO, cookie based authentication and supports open id connect. It also supports federated authentication if you want to hookup a ADFS. Its also possible to do social sign in integration with it.
I have integrated .NET, Java and PHP solutions in production to the same instance and everything is fantastic and seamless.
You can host it as a separate service. You can register known clients (your apps and services), their incoming and redirect urls, including post logout Urls, so your application can seamlessly reach out and come back from identity server. The Identity Server comes with all the middleware you would need to protect your APIs and web applications. It also provides REST endpoints for getting and validating access tokens amongst others.
You can also set different scopes to specify the scopes against which a request can be processed.
Much of what I am talking about has directly to do with oAuth 2.0 specs so probably you can read a little about it here if you are not aware of it.
Using a typical oAuth Flow, (e.g implicit flow or authorization code flow), hooking up the right middleware in the Owin pipeline, and decorating your API resources with [Authorize] attribute, your Application will redirect to the identity server page where the user can login. Your APIs(the protected resource) can specify if they are expecting for a specific Scope, when a token is presented and allow to accept/deny your request based on that.
The client registration ensures that only known clients are accepted by identity server(as applications are generally internet facing) and you can either use the MembershipReboot component, also from Thinktecture(also opensource) as your identity store or write your own implementation of a "user service". There are way too many extension points available to play with and you can practically customize everything including the look and feel of the identity server pages to match the UI scheme of your client applications. There is IUserService(to plugin your own user store, ViewLoader to customize UI, CORS policy service to specify allowed origins per client, certificate based TokenSigningService to sign tokens(access/refresh tokens), ScopeStore, ClientStore, TokenHandleStore(to store scopes, client configurations, tokens), ClaimsFilters to filter what claims are included when a token is issued, which is helpful when you use external providers which might return more information that you need to store or provide)
I can go on for ever here but like I said its something available for use and I am using it for multiple applications in production, you can give that a try.
You can have it up and running in 30 mins on your local machine with both Identity Server and MembershipReboot databases setup. The support is very good from the authors and this is a very widely accepted solution for user authentication and authorization.
For example, securing a WebAPI is super simple:
decorate your APIs with [Authorize] and or [ScopeAuthorize] based on your need
This tells the API to go and check if you got something setup for Authorization in the owin pipeline.
In Owin startup just use:
app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions()
{
Authority = "http://your-idserver-url"
});
Yes that is all the change you need in your WebAPI. There is a separate way to setup open id configuration for MVC based web applications but that is anyway available in the documentations with sample code.
The documentation is pretty easy to follow and the server is easy to setup. It takes away all the complexity from your App and services so you can focus on what you want your App to do rather than worrying about handling Authentication and Authorization in each of your Apps or services.

C# ASP.NET Single Sign-On Implementation

I am tasked with implementing single sign-on for our customers as part of our next release. The flow exists as follows:
User logs into their school's main portal system using a student id/password provided to him/her by the school.
User clicks the link to my company's product.
User is automatically taken to the dashboard page as if they had just logged in through the login form on our site.
Thus, there are two mechanisms by which a user can be authenticated into our site:
Coming to our product's home page, and logging in using the email/password that we store in our local system.
Using the single sign-on where the student has already logged into the school's main system with a student id and password.
If our product's implementation is in ASP.NET (as opposed to Java/Ruby), should we be using CAS, JOSSO, or some other third party single sign-on product? Or is there something available to a .NET environment which would be simpler for us as a .NET company?

There are multiple options to implement SSO for a .NET application.
Check out the following tutorials online:
Basics of Single Sign on, July 2012
http://www.codeproject.com/Articles/429166/Basics-of-Single-Sign-on-SSO
GaryMcAllisterOnline: ASP.NET MVC 4, ADFS 2.0 and 3rd party STS integration (IdentityServer2), Jan 2013
http://garymcallisteronline.blogspot.com/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
The first one uses ASP.NET Web Forms, while the second one uses ASP.NET MVC4.
If your requirements allow you to use a third-party solution, also consider OpenID. There's an open source library called DotNetOpenAuth.
For further information, read MSDN blog post Integrate OpenAuth/OpenID with your existing ASP.NET application using Universal Providers.
Hope this helps!

I am late to the party, but for option #1, I would go with
IdentityServer3(.NET 4.6 or below) or IdentityServer4 (compatible with Core) .
You can reuse your existing user store in your app and plug that to be IdentityServer's User Store. Then the clients must be pointed to your IdentityServer as the open id provider.

There are several Identity providers with SSO support out of the box, also some third-party** services.
** The only problem with third-party services is that they might charge per user/month, which can be pretty expensive.
Some of the tools available and with APIs for .NET are:
Auth0
IdentityExpress (with Admin UI) by IdentityServer
Centrify Identity Service
Okta Identity (SAML 2.0)
OneLogin
If you decide to go with your implementation, you could use the frameworks below categorized by programming language.
C#:
IdentityServer3 (OAuth/OpenID protocols, OWIN/Katana)
IdentityServer4 (OAuth/OpenID protocols, ASP.NET Core)
OAuth 2.0 by Okta
JavaScript:
passport-openidconnect (node.js)
oidc-provider (node.js)
openid-client (node.js)
Python:
pyoidc
Django OIDC Provider
I would go with Auth0 as a service, as it's free for the first 7000 users, supports many languages, and not much needs to be done. However, if you need a more robust, manage yourself, and cheaper solution, I would configure IdentityServer4 and ASP.NET Core application and add authentication providers as necessary.
Both Auth0 and IdentityServer4 solutions use OAuth/OpenID protocols, supporting also WS-Federation and SAML 2.0 integration.

[disclaimer: I'm one of the contributors]
We built a very simple free/opensource component that adds SAML support for ASP.NET apps https://github.com/jitbit/AspNetSaml
Basically it's just one short C# file you can throw into your project (or install via Nuget) and use it with your app

UltimateSAML SSO is an OASIS SAML v1.x and v2.0 specifications compliant .NET toolkit. It offers an elegant and easy way to add support for Single Sign-On and Single-Logout SAML to your ASP.NET, ASP.NET MVC, ASP.NET Core, Desktop, and Service applications. The lightweight library helps you provide SSO access to cloud and intranet websites using a single credentials entry.
Detailed UltimateSAML SSO review can be found here

Can I use WIF to authenticate on services like Gmail and Hotmail?

Can Windows Identity Foundation allow us to connect to services and read contact information?
Here is a idea of how WIF advantages:
WIF externalizes authentication,
passing it over to security token
services (STS) and reducing the
demands on individual developers
WIF
also supports trust relationships
where a service trusts anyone
authenticated by the application
accessing it.
WIF provides support
for a single sign-on (SSO) for users
by sharing STS among applications.
Developers can also, at run time,
support both by creating a trust
relationship between the application
and service or bypassing the user's
credentials from the application to
the service.

Depending on what you want to do, the answer is Yes.
Using Azure ACS federated to WIF e.g., you can connect to Facebook and get all the Facebook user attributes that you have asked for (provided that the user agrees during login to provide them). You can also connect to Google.
Or you can write your own custom STS federated to WIF that has some kind of interface on the other side that invokes a service and passes the details through e.g. using DotNetOpenAuth to handle the OpenID protocol. See StarterSTS as an example.

Watch this video as a starting point. There is a link for the source code and documentation, so you can see if the direction fulfils your needs.