I'm working on an MVC4 site using SimpleMembership to handle user accounts and role based authentication. We have another site and we'd like to implement a single sign on system allowing users from the existing site to log in to the one I am building. What would be the best way to achieve this and hopefully leverage to the existing roles based authorization I'm using on the MVC4 site. Is it possible to have multiple membership providers (i.e. use the built in one and if the user is not found, attempt to authenticate via a custom provider that I'll write (once I work out how!). Or would it be better to abandon the built in membership/roles and roll my own?
I also thought of letting WebSecurity check the local database and if the user is not found, query the 2nd database and if the users credentials are valid, create a local account for them. One issue with this approach is if a user called Fred registers on the MVC site, and then a user from the other site called Fred logs in, we couldn't create them a local account with the same username. We could prefix/suffix the username with some text to indicate that they are from the other site but then we lose the single sign on feature.
We will also want to integrate AD authentication for staff in the future.
So essentially I'm looking for the best way to authenticate users from multiple databases and keep using roles based authentication?
I've also done a little digging was wondering if ADFS might be useful for this.
Any help or advice would be greatly appreciated!
I recommend the use of an Identity server to handle all your login request and switching to a claim based authentication instead of a role based authentication if you can.
I personally went with Thinktecture IdentityServer
pluralsight.com have a good course on it.
Thinktecture IdentityServer is build on top of simple Membership and it supports multiple protocol such as
WS-Federation
WS-Trust
OpenID Connect
OAuth2
ADFS Integration
Simple HTTP
I recommend checking it
Good Luck
Related
Context:
We have a monster ASP.NET MVC 5/Framework 4.5 application that is planned to be divided in several others, so each new application will deal with a specific business domain instead of many. All those applications together will provide the same functionalities and services that are provided today by the existing single application.
We plan to use our own OAuth server to provide authentication and authorization for all the new smaller applications, so the very same users that use the current large application will have the same rights in the same functionality.
Currently we use Windows Authentication mixed with a secondary custom structure to establish what a certain user can do. We have our own role provider to generate the roles assigned to the users. When a certain controller action asks for the list of roles af a certain user, our role provider search in our custom structure and provide those roles, following specific business rules that make sense in our application.
We understand that the same rules that establish the set of the roles assigned to a certain user will be moved to our OAuth server.
We understand that the role-based security will be replaced by a claim-based security.
We understand that we will stop testing for roles and start testing for claims.
We understand that the first step of this refactoring should be add external authentication in our current large application and then start to break it into parts so we will have our new ecosystem.
Question:
How to change my current large application so it authenticate and authorize requests by using the new OAuth server instead by itself?
Note:
I´ve read a lot of blog posts but so far I couldn´t find a simple code sample that shows me what to do to instruct my application to go for an authentication/authorization token in my OAuth server and use it to grant or deny the access to a given controller action.
I have an app that uses my own membership system. It uses ASP.NET MVC 3 which I'm updating to ASP.NET MVC 5. It's not possible to change the membership to use a new one like ASP.NET Identity. But, for the authentication side, do you think it is a good idea to replace my auth-ticket system with OWIN.Security? Are there any traps that I should know about?
The Katana security middleware is independent from ASP.NET Identity. You can use them both or just one.
There are some cases where it makes very good sense to use just the Owin/Katana middleware, but not involve aspnet identity.
I just rolled up a prototype webforms application using OpenID Connect against an Azure Domain. My domain is Federated with an on-prem ADFS. By the time I got OpenID Connect and the GraphAPI working, I realized that I didn't really need much from aspnet identity.
I use the GraphAPI to grab extra info about the user and their group memberships, and I am adding that info as claims on the user principal... my site's code can operate against just the information in the claims.
Of course, if you want to do any custom profile or role stuff in your application, it probably makes sense to link it to aspnet identity too.. create an aspnet identity user when a new user authenticates, map that user's AD groups to roles, etc. Then you can manage application specific data for the user directly in the application via aspnet identity, while relying on Azure AD for the core authentication, basic profile, and group/role assignments.
The "dream" is to use WindowsAuthentication for an intranet site. However, we need to hit a 3rd party service to determine if the user has "permission" to use the site, thus "Roles". I have seen many examples that show how to add roles to the identity but they are all on "per request" basis. I don't want to do that. I would like for the user to hit the site once, I determine if the user has the permission, and add the role to the identity. The identity (with the role) sticks around for the session. I also don't want to have to cache users and their permissions. Is this doable or am I missing something?
Thanks.
The solution is to write your own Authentication and put caching in the middle. It is really easy to do as I have two methods of doing it.
Pre ASP.NET MVC 5
http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet
ASP.NET MVC 5+ OWIN
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux
My posts describe the basics of writing your own authentication, but it is pretty easy to integrate a third party service once you understand the basics. Hope that helps :)
We've got an MVC website that is going to use DotNetOpenAuth for signing in users via OpenID and I've found this really helpful template and other more simple examples that will help me get started on that end. However, what I don't have fully figured out is how to provide my users with a way to create an account with us if they don't want to use OpenID.
I can see two options here, write some custom code that allows OpenID to piggy back on the standard membership provider. Or, have the end site only use OpenID via DotNetOpenAuth and build an Identity Provider for my users to sign up on. That way the site would only see OpenID users and wouldn't know a difference.
Are these my only options? I haven't been able to find anything on standing up my own Identity Provider, just the relying party templates. I think I can get by with just putting OpenID on top of the default membership provider, but that feels like I'm doing it wrong, since I should be able to just stand up an identity provider.
So, in my situation, what would be the best way to support membership via local account creation and OpenID via DotNetOpenAuth?
Setting up your own identity provider so that your site only speaks OAuth is certainly an option, but a non-trivial one. I wouldn't recommend setting up an identity provider unless you intend your customers to use it for logging into other sites.
Also keep in mind that most web sites don't use OAuth to authenticate (since it's not an authentication protocol anyway). OpenID is more popular.
The project template you linked to in your question demonstrates allowing users to log in via several OpenID Providers and includes support for linking user accounts.
As for supporting local user accounts as well, I suggest you take a look at the source code behind nerddinner.com. I would advise against using the ASP.NET Membership provider for the OpenID/OAuth accounts as the interface doesn't fit very well, but folks have made it work so you can too if you want.
We have started building an asp.net mvc application. Application will consist with one main database with users, projects, common tables etc... and many databases (all with the same structure) with a data relevant to a particular project. Use can have some global roles (stored in a main database) and some project specific roles (stored in a project database) and each user can be linked to many projects.
My goal is to build an authentication system that will support classical username/password authentication and also an OpenID authentication (we are using DotNetOpenAuth for this purpose) and authorization system that will support the roles system which I described above.
But I run into several question:
1.) I think that we should support both (username/password and Ppenid) authentication options for a single user, so that username/password users won't need to create additional account when they decide that they will use an OpenId and I think that we should support several OpenId's for a single user like SO does (if some provider is down).
2.) I think that the best database for this would be:
table Users (UserId (PK), LastActivityDate)
table UsernameLogins (UserId (PK,FK), Username, Password, IsApproved, IsLockedOut, LastLoginDate, LastLockedOutDate, etc...)
table OpenIdLogins(OpenIdUrl (PK), UserId(FK),LastLoginDate)
table Profiles(UserId(PK,FK), DisplayName(Unique), Email (Unique), FirstName, LastName, Address, Country, etc...)
table Roles(RoleName (PK), RoleType(1=GlobalRole,2=ProjectRole).
table UserRoles(UserId(FK,PK), RoleName(PK)).
3.) Should I create my own providers (MembershipProvider, ProfileProvider, RoleProvider)? Its seems that MembershipProvider is not so appropriate for an OpenId authentication (and of course I can only support just basic methods (GetUser,ValidateUser))? Should I implement MembershipProvider just for username/password logins? I think that ProfileProvider and RoleProvider wouldn't be that hard to implement? Should I just use FormsAuthentication and use my own "services"?
We are also using NHibernate and Spring for DI.
Any advice will be appreciated.
Thanks!
1.) I think that we should support both (username/password and Ppenid)
authentication options for a single
user, so that username/password users
won't need to create additional
account when they decide that they
will use an OpenId and I think that we
should support several OpenId's for a
single user like SO does (if some
provider is down).
That seems reasonable. I like how you're designing in for users to have multiple OpenIDs. StackOverflow limits users to just two, but users often have more than that and may want to bind them all. I think username/password is a fine option if your target audience demands it OpenID. StackOverflow is a great example of how simple login can be when its pure OpenID. It can make login less busy to not offer username/password. But again, providing both as options seems most customer-focused since it gives them choice. A future version of DNOA will offer an integrated version of the InfoCard Selector into its OpenID login system so that you can even accept InfoCards directly, but have it look and feel just like an OpenID so your system won't require any changes.
2.) I think that the best database for this would be: <snipped/>
That looks like a reasonable schema. As you've discovered, separating the credentials tables gives you the greatest flexibility.
3.) Should I create my own providers (MembershipProvider, ProfileProvider, RoleProvider)?
MembershipProvider certainly doesn't fit OpenID very well. If you were only supporting OpenID login I'd say throw it out and don't bother implementing your own. The RoleProvider works perfectly with OpenID so that's a keeper. I've heard from others that ProfileProvider needs a MembershipProvider in order to function. I don't know if that's true. But ProfileProvider requires that you use the ASP.NET Membership SQL database schema, which I think is poor if you can write your own db schema which you've done. And if you're writing your own db, storing additional data about your users should be trivial so you shouldn't need the profile provider.
If you go with both username+password and OpenID, then having a MembershipProvider that you implement yourself would likely be possible, but in my experience most MembershipProviders that include any OpenID code are kludgey and even have security holes. So I'd still avoid the MembershipProvider if OpenID has any place in your system.
I wonder...is support for multiple OpenIDs that important. It seems like this is more the role of the OpenID provider. For example, I use ClaimID and I get what essentially amounts to "identify forwarding" (in the sense of email forwarding) so that I can rebind it to different identities. Now I don't rebind providers frequently but a provider could do this (i.e. when you get redirected to their login page they could ask you which identity you'd ultimately like to present). So the question is...is this really the applications job to implement?