I have a concern when it comes to GrantedAuthority objects in a Spring Security application. I'm looking for a good way to handle things. First of all I'm trying to describe my concern, if there are any factual errors do not hesitate to point them out, I'll only be greatful.
Spring Security uses GrantedAuthority instances to act as tokens of authorization in different parts of the application.
By default a GrantedAuthority may present itself as a String. When methods are secured using #Secured("ROLE_NAME"), or URL's are secured using the Spring XML configuration or when the HttpServletRequest request is checked programmatically as in if(request.isUserInRole("ROLE_NAME")) {..} it's always the String that you are using to specify the authority which is checked for.
I'm wondering about the implications of using static strings in several places of the application. If a role name is changed the developer has to hunt down all the old strings and update them. There will be no compile time error if a String is missed, only a problem at runtime.
What is the best way according to you when it comes to handling GrantedAuthority objects in a Spring Security application? What pros and cons does your solution have?
First off, if possible, only do your checks at a particular place in the application (e.g. an HTTP interceptor at the beginning of the request), and using only one of the mentioned approaches. This is a good practice since you will be able to know authoritatively when a user becomes authorized.
If this is not possible, use enums for the role names and only compare on the enums. Therefore, if you wanted to locate all usages in the application it's a simple search.
I do not see a big problem here. It is very unlikely for GrantedAuthority to change the key. Just do not name your roles ROLE_A.
Also, I personally prefer XML security configuration over annotations. In general to keep any related configurations in one place looks like a good idea.
In Spring and other frameworks (especially for dynamic languages) "Convention over Configuration" is used. If you were free to define the role names yourself, you easily find out that much more lines of code are needed.
So stick to the convention. Always use the 3 following roles, ROLE_ANONYMOUS, ROLE_ADMIN, and ROLE_USER. If you need another one, name it accordingly and use it in all occasions. Documentations is important.
Also unit testing is imported. It helps you in the cases that an error isn't caught by the compiler.
Related
I am trying to configure two UserDetailsServices for the authentication of two different user groups and I came across this post. However, it is using xml configuration, how would I accomplish the same using Java configuration?
As far as I know, the http element is configured by overriding the configure(HttpSecurity http) method, but how do I configure multiple http elements?
I do know that in many scenarios, it would be sufficient to have one UserDetailsManager which manages two user database tables, but I am curious how the other solution would look like in case I decide for it.
I do not see any reason for you to be using 2 UserDetails implementations, as you are saying you need to authenticate two different user groups. Would suggest to look at http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#authorization and think would give you a lot of pointers where you should go from there.
What you are in need is upon authentication in system to know what the logged in user Role is and define it. Two ways are indeed one via xml second is Annotation based in a #Configuration java class with the specifics laid out there. Read up the above link I posted for you and you should be able to see what Spring offers and what you are in need to do actually.
Would take a lot of space First to put it down and Second it is a very broad question you are asking as the post link you are referring to is incorrect in the way it handles Spring Security.
I wanted to use the OSGi User Admin service for security but I could not get enough resource about it.
I want to authenticate certain bundles that will be installed in the system and represent them by User-Objects after authentication. So that I can later use these User-Object for authorization.
I have 2 questions:
Since I have more than one user, how can I know which bundle is calling a secured method? (I don't want to pass the user object as a parameter to every method I want to control).
How can I relate the bundles with the User-Object representing them?
I want to have one bundle as an entry point that will authenticate all these other bundles and have control over them. But I couldn't even find anyone mentioning using User Admin service. Is there another option for OSGi security besides CPA? I would like to use this to secure my console as well.
That's quite a few questions rolled into one. Let me try to answer them all.
First of all, the UserAdmin service is specified in the OSGi compendium. There, it explains how users, roles, etc are defined and how you can use the service to answer questions like "does this user have role X"? What that does not tell you is how to use this service as part of a security solution. That's up to you.
Regarding question 1, which is not an OSGi related problem (but rather a generic one in Java applications), there traditionally have been a few methods of passing on a "context" to a method:
Making it an argument to each method (which you do not want to do).
Storing it in the ThreadLocal context (which is fairly popular in JavaEE, but has its downsides if your application delegates work to threadpools that might or might not pass on such a context correctly).
If this is all about security for services that you implement yourself (and not third-party ones) you could use the ServiceFactory pattern in OSGi to give each client bundle it's own context (and embed the User object in there; for examples look at the LogService implementation in Felix, which uses that mechanism to add a bundle.id to each log message).
Sometimes it also makes sense to embed the context not in an extra parameter to your methods, but as part of some existing object (so effectively you are then associating the context with specific objects, which might or might not make sense depending on your domain).
Another option would be to use the Apache Felix Dependency Manager to intercept the services you want to secure (with an aspect) and, in the aspect, figure out what bundle is calling, and do the proper security checks (probably requires a more detailed answer if you want to give that a go).
Regarding question 2, bundles have a symbolic name that identifies them. You could use that to associate a bundle with a User. There are other options, but this is the most obvious one.
Regarding your question about options for OSGi security, I would say ConditionalPermissionAdmin (and the older PermissionAdmin) is the only solution to address security within the OSGi framework itself, if you want to specify what specific bundles can and cannot do in terms of importing packages, using services, accessing the filesystem, etc. You would have to write your own custom permissions if you want to integrate this with UserAdmin.
Finally, the secure console is yet another thing you need to address yourself. You might be able to find some building blocks as I know there have been people implementing some role based access (David Bosschaert comes to mind). However, the console is a complex and powerful thing, so answering this question alone takes more than a simple SO question because it depends what and how fine grained you want to implement this.
I'm quite new to the Spring Security framework, and especially ACLs. After a few hours of reading I think I grasped most of what I need to do to start securing my application.
However something bothers me: while it's very easy to find usage descriptions on how to read the ACL permissions (via #PreAuthorize for example), it starts getting confusing when you want to create and persist them.
The Spring Security manual tells us they don't want to bother with any standard but we are encouraged to use AOP. Many tutorials and answers here rather use the AclService directly inside their business code, destroying the "separation of concerns" principle in the process.
So what should I do ? How do the pros do ? Should I try defining pointcuts on custom annotations for creation/deletion of ACL entries ? Or should I "pollute" my code with ACL concerns ?
Alright so I now understand much better, after one week of work, how these things work.
First, one shall try to stick with the simple, naive way of using ACLs using the AclService directly inside each service layer method. Building an abstraction helps a lot (basically a grantAccess(username, object, permission,...) method in a #Service bean).
Once everything is secured with ACLs writes and #PreAuthorize/#PostAuthorize/#Secured el tests, then you can start thinking about AOP to clean up your code from all the security concerns. You make up a list of service method using ACL writes and you add Advices to them to have one central place where all the security is handled.
Spring Security ACL is extremely easy to set up and understand, even on an existing project with existing users (you'll have to build a migration script).
I asked a similar question earlier, and this is an extension to it. Basically, we need to have auditable logs for legal reasons of permission/user management and authentication attempts. Our permissions and users are stored in an LDAP service, and I was wondering what auditing libraries were available for usage? Are there any? Is it better to use an auditing library that is a little higher level? Are there any good resources on what auditing should be and how it is traditionally done?
For me, what you are looking for, is particular for each Directory server. Because 'Authentication' is more defined as an interface than a feature, and 'Permissions' are just non standard.
Authentication is normalized via "simple bind" or "SASL", but the behaviour of the server (log) are not a standard as far as I know.
Permissions, I mean Access Control List (ACLs) are a non standard feature. The way permissions are implemented in Active directory, is different from the way they are implemented in Sun e-Directory (special attributes). For example in OpenLDAP permissions are implented in a kind of access filter.
So my advice is to start from you Directory Server and have a look on what exists.
LDAP keeps its own audit logs, at least OpenLDAP does, or can be made to.
I'm designing the security subsystem for a new product. The system requires the following:
Complex user/group/permission model, both service-level and domain-level (ACL)
Administration UI for the above
Rules performed upon user actions (account disable on failed login, password complexity requirements, etc).
Before going ahead and implementing most of the features that Spring Security (2.x) lacks, I was wondering if anyone is familiar with and can recommend a package that may already implement / support these requirements? ideally JAR + WAR that can be dropped into the project and support everything off-the-shelf.
Thanks
Not exactly what you are looking for, but you might be interested in checking out jSecurity. It is a well thought out security framework that handles authentication, authorization, and fine-grained permissions. But from what I can gather, much like Spring Security, they try not to make assumptions about how this data is stored and organized. (I haven't found, for example, a reference implementation for User, Roles, Permissions, etc. in a database.)
Note that the JSecurity project has permanently moved to the Apache Software Foundation and is now known as the Apache Shiro project.
Interesting you asked, I also have a very similar requirement and have been searching this for a while. I gave up and started doing it myself and have some decent progress in the last 2 weeks. Currently I have support for domain ids that are not necessarily Long, it could be anything such as a wild-card string to denote a group of things that could be granted to an authority (ROLE, GROUP, USER) or a String id or even a long. Multiple permission types each with their or sets of permissions can be defined and these permission types could be assigned as supported to a secured entity and the instances be protected by them, so you don't have the limitation of a maximum of 32 possible permissions across the system. Also you could use any actual or virtual entities in the ACL configuration. All this is based on the new (3.0.0.R1) of Spring security with method expression support and it works fairly well. The whole thing uses hibernate so you can take advantage of the transparent persistence and distributed caching. There are lots of rough edges, but being a proof of concept its expected. Anyways let me know if you are interested and we could collaborate to make this useful to us and probably others too.