Spring security gurus,
I am new to spring security so please bear with me if my questions are not clear.
I am trying to implement role based access control using spring security 3.x. Individual users are stored in Windows AD without groups so we cannot simply map groups to authorities as some samples demonstrated.
So my plan is to use Windows AD for authentication purpose only, but the user <-> roles relationship to be maintained by Spring security itself.
However, mapping individual user to roles would be very tedious so my question is if possible to configure users <-> groups <-> roles in spring security but the authentication part has to be done by Windows AD?
As spring security is highly flexible I believe my requirements are achievable. Can someone give some pointers on where I should look at please?
The more details the better for newbies like me :=)
Thank you in advance.
Aaron Li
EDIT 1: To add onto my question in particular, can I utilize the Spring database tables authorities, groups, group_authorities, group_members to implement a simple role based authroization logic? But I can't use "users" table as ealier explained the user details will have to be stored in Windows AD so the authentication of the users need to be done using Windows AD.
Any advices?
Thanks
Aaron
First some clarification on the terminology: Authorities, usually consisting of roles in Spring Security, are application-wide permissions. ACLs (Access Control Lists) on the other hand, specify permissions on specific domain objects. Just as you understand the difference. AD usually contains authorities/roles, but not ACLs.
If you don't want to use the authorities from AD, you can do your own implementation of UserDetailsContextMapper and inject it in your instance of ActiveDirectoryLdapAuthenticationProvider. See the Spring Security reference documentation how to specify a custom authentication-provider.
If you want to use the tables (authorities etc) of reference schema, you can use JdbcDaoImpl to load the user details. You then have to insert the users in the users table but not any passwords since authentication is done through AD. If you want to get rid of the users table however, you must customize the implementation.
Related
I'am looking at the capabilities of WIF in terms of SSO. Actually we have a "legacy" users & rights management database under SQLServer and we like to build a brand new SSO system on top of this exsting database.
In many tutorials I found they talk about using existing STS like ADFSv2 for Active Directory authorization, but It did not fit my needs because my users/rights are not exposed through AD but in a custom a specific business oriented SQL Server database.
So, I thing I need a custom Security Token Service in order to be able to emit my own custom tokens, but I don't know how to do this.
I need some little help or an example about how to achieve this.
Thank you
You can find STS example in WIF SDK. It contain an example with custom token. Look here
More detail information about SSO I seen in a book 'Programming Windows Identity Foundation'
You can build your own Custom Security Token Service leveraging the underneath SQL Server database. You will have to define your scopes and Claims that needs to be shared after user does a Single Sign On. Here are some links to some articles below that has helped me build mine. I am pretty sure by following the below links you will be able to build a custom STS catering to your needs.
WIF : http://chris.59north.com/post/Building-a-simple-custom-STS-using-VS2012-ASPNET-MVC
http://www.primaryobjects.com/2013/08/08/using-single-sign-on-with-windows-identity-foundation-in-mvc-net/
Care to explain why #paullem's answer was deleted?
It is in fact the correct answer!
The question is about an STS that authenticates using a SQL DB. That is EXACTLY what IdentityServer does.
Since it's open source, you can customize it any way you want or else use it as a guide.
So to repeat the answer - "Take a look at Thinktecture.IdentityServer........".
Update
You want a custom STS that supports SAML protocol and authenticates against a SQL DB?
WIF won't do this for you.
You need to look at something like Shibboleth or simpleSAMLphp but they are not .NET based.
Or take IdentityServer and add a SAML stack to it.
Refer: SAML : SAML connectivity / toolkit.
Be warned: This is not a trivial exercise!
I am using Spring security core & Spring security UI in my project. I have a requirement in which i need to create 2 different type of users: Sellers and Buyers. When user goto home page he can select what type of account he wants to create either buyer or seller.
What i have to do it make it work with spring security UI plugin. Do i have to create different Registration pages for different type of users. But then how i can assign roles at the time of registration.
I checked various questions posted before posting this question and could not find the right answer. I am new to Grails and will appreciate if Grails experts can help me with this issue.
I hope I have understood your question, I was a bit confused about mixing login with registration in your question.
Once you have created your user create UserRole based on the selected role, either ROLE_BUYER or ROLE_SELLER. This can be done in UserController create method.
As for login you don't need to have two different logins, you can always create a filter, interceptor, or any aspect oriented technique to intercept the request and redirect user to the proper section of your site. This way you're authorization is loosely coupled. Imho, there is no need to use Spring Security UI for authorization specific goals. Spring Security Core does much better job wrt url mapping/annotations.
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
There is so much information and terms here I find it hard to start think about users. What options would I have for creating a user-based ASP.net MVC 3 web app? I've read of membership, providers, authorization, authentication, session, cookies, roles and profiles, but I can't seem to get a grasp on the big picture of how user-things are handled.
What are the pros/cons of using a built-in microsoft solution here? What is it even called?
Can I use my own database only (I want to work database first)?
In my mind I think like so: I have users and roles in a database. Users have roles. I want to deny access to some actions depending on if the user is logged in and has a specific role. Am I over-simplifying the issue? Where should I start?
At the moment I'm thinking of doing a 100% home brew system like when I was developing using PHP but since there's so much info I feel like that would not be a good approach here.
You want users and roles, i.e. you want to authenticate users and authorize them with privileges using roles. I would highly recommend not rolling your own, as you would in PHP. Instead, I recommend using the .NET "Provider" services -- specifically, the MembershipProvider (for authentication) and the RoleProvider (for authorization).
You can still use the Providers with your own db, they are not exclusive to or exclusive with code first. However, I would recommend NOT storing application-specific user information in the Provider's user or member tables. Instead, you can have your own code-first User, and link it to the membership system through the user's username.
The reason I recommend this is because it reduces the amount of work you have to do. You need not worry about encrypting or hashing passwords -- the provider does it for you. You have full API to control your users and roles through the System.Web.Security namespace.
As for Profiles, this is a separate Provider service that you do not need to use. It allows you to store information about users whether or not they have registered for a user account in your system. Technically you can have "anonymous users", but anyone who has created a password-based login is instead referred to as a "member".
Regarding cookies, authentication of a user in .NET is done through the FormsAuthentication class. After you have authenticated a user using System.Web.Security.Membership, you can call FormsAuthentication.SetAuthCookie to write their authentication cookie. This fully integrates both the User and their Roles into the Controller.User property, which implements the IPrincipal interface. You can use this object to get the user's name, and find out which roles they are in.
Reply to comments
I answered a very similar question here. Basically, it's up to you whether or not to have the membership in a completely separate db than your application, but I consider it good practice, because I have done this quite a bit and I have no complaints. Especially if you are using code first, since you can lose your entire db if you use the DropCreateDatabaseIfModelChanges or DropCreateDatabaseAlways initializers.
There is also a new membership provider. I think the NuGet package is called "ASP.NET Universal Providers", and they are in the System.Web.Providers namespace instead of the old System.Web.Security namespace. I haven't had a chance to work with them yet, but from what I gather, they are more compatible with code first. For one thing, the tables aren't named like aspnet_Foo, and there are no views or stored procedures created in the db. The table names are just normal dbo.Users, dbo.Roles, etc.
As for linking the provider users with your app (content) User entities, see the answer I linked to above. The easiest way to do this is to just have a field in your content db for UserName, and link that to the provider db's UserName. No foreign keys necessary, since you integrate them at the app-level, not the db level.
I think you should first start with built-in solutions, they're easy to extend if someday you'll need something more (even if to write a good providers for authentication isn't really trivial. Start reading this article, it's a good start point).
I don't think to write everything here is a good idea, it's a big topic and I should simplify everything too much so I'll post some links I found useful.
Just to start, with text from MSDN:
Authorization determines whether an identity should be granted access to a specific resource.
Authentication is the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority.
Imagine users and roles as Windows users and groups. For example a web-site for forums may have a user named AUser with following roles: User, Editor, Moderator. In that web-site they may grant a set of allowed actions: User may enter new posts, Editor may change posts of other people and Moderator may close or delete posts or topics. In this way single web pages don't need to know users but just roles (the DeletePost method of PostController may be decorated with [Authorize(Roles = "Administrator, Moderator")]).
Start reading this very introductory article, it provides additional useful links.
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?