I want to make method level security for my spring application.
The security design is as follows: User > Roles > Permissions
Well when i use #PreAuthorize with hasRole it works fine.
But when i try to use it with hasPermission, it doesn't work.
I found that i should use Spring ACL for such approach, but it seems to be over-killing for the requirement.
So is there's any way to define role permissions in xml file, or any other workarounds or other ways to get method level security works with permissions instead of roles, and withour using ACL.
If there's no way but to use ACL, then please suggest me a good example
Please read the article on the following site:
http://springinpractice.com/2010/10/27/quick-tip-spring-security-role-based-authorization-and-permissions/
The main thing is you will need to implement the UserDetails interface. It says
"the UserDetails interface simply exposes the permissions (not the roles) via the getAuthorities() method"
Related
In my system, a microservice is responsible to return user's roles for all other microservices.In the other projects I'm using spring, so I can use Authentication Provider to get user's roles. Now I would like to create a project using QUARKUS, but I'm not finding how to get user's roles from my microservice, because in Quarkus' documentation there are only examples showing getting roles from database, JWT and etc..
So, I would like to know if is it possible to work with Quarkus and something like Authentication Provider from Spring. If yes, I would like to see one example.
Quarkus seems so nice, but if it is impossible, I won't be able to use it.
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.
My problem:
I would love to use the Spring Security plugin's access control/authorization mechanism with my Grails application without having to use the plugin's authentication mechanism. The various Grails Spring Security plugin examples (like this one) I've found combine these two functions. Is there an easy way to just do access control?
Background:
I would like to add roles-based access control to my existing app. I would love to either just annotate my controllers or use the Config.groovy map approach for setting up the access control.
My app already has a user domain class.
The user domain class already handles encrypting passwords using BCrypt.
The app does not have a "role" domain class.
I already have controller actions, views and business logic for handling logging in and logging out. I have no interest in replacing this with the plugin's implementation.
On the right track, but not quite helpful:
I know this is possible to do, as explained in this other question: BUT, that questions and its answers explains how to do it in a Java app using the raw Spring Security framework. I would love for someone to lay out how to do this in a way that is compatible with the latest version (1.2.7.3 as of this writing) of the Grails Spring Security plugin. I don't want to reinvent wheels that have already been taken care of by the plugin.
In addition, this example explains how to do some of this, but it appears to be outdated because it is based on an older version of the plugin that uses Spring Security 2.x. It also only uses custom authentication for one piece of the app, while it looks like it still uses the Spring Security plugin's domain classes elsewhere.
How to do it?
Can someone lay out an approach for me?
I assume I need to create my Role domain class.
After that I assume it will involve custom Authentication objects and the like. But how do I hook them into use the plugin's existing code?
You could go with a custom authentication provider and I have an updated version that I did as part of a recent talk. See this blog post which has a sample app and link to a video of the talk: http://burtbeckwith.com/blog/?p=1090
It would be simple to use a custom UserDetailsService - this is the most common customization done for the plugin and it so has its own chapter in the docs: http://grails-plugins.github.com/grails-spring-security-core/docs/manual/guide/11%20Custom%20UserDetailsService.html
Basically you need to create a Spring Security User instance and Spring Security (and the plugin) doesn't care how you get the data. So your custom UserDetailsService just needs to be a bridge between your current auth scheme and Spring Security.
I ended up creating my own access control/authorization mechanism rather than using the Spring Security plugin. I never could figure out how to separate the plugin's authentication mechanism from the authorization mechanism. Doing the work myself was very easy.
I did the following:
Created a new Role domain class.
Added a Set property and hasMany relationship to my User domain class.
Created a new AuthorizationFilters filter. This is where I put in my authorization rules. In this filter I can check to see if a user has the role necessary to access the given URL and redirect to a login page, redirect to a "not authorized page" or allow them to pass.
This doesn't have the nice syntactic sugar of the plugin and isn't quite as concise either, but it was very easy to implement and understand.
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.
I have been searching on google the list of available roles in spring security, but I haven't been able to get the complete list.
¿Could someone help me with this?
This is what I've found: ROLE_ADMIN, ROLE_USER, ROLE_VISITOR.
The list of roles is not dictated by Spring Security, but is entirely up to what is required in a particular application.
The list of roles could for example be stored in the application's database. See for an example Spring Security's JdbcUserDetailsManager class which can be readily used to manage users, roles and authorities (privileges) in the database.
As Markus said there are no fixed number of roles in spring security.
Have a look at the javadoc for org.springframework.security.core.GrantedAuthority.
Extending it allows you to override the getAuthority method from which you can return any role string you like.