How does spring security support dynamic role & permission? For example, the role can be generated at runtime by end users. Each role can include multiple permissions which can be created/updated at runtime. Each permission is base on criteria like delete topic if no activity for 3 months. The ACL of spring security can't support it since records of acl_entry are static instead of dynamic. How to customize spring security to support such requirement?
Spring Security 3 supports expression based authorization: it allows you to express secuirty constraints as arbitrary expressions in Spring Expression Language. By default you can use methods of SecurityExpressionRoot in these expressions.
However, you can add your own methods by customizing MethodSecurityExpressionHandler.createEvaluationContext(), so that you can define arbitrary criteria and use them in these expressions. Also see What's the difference between #Secured and #PreAuthorize in spring secu 3 ?.
Related
I have a Spring Boot application that has got method level security with #RollsAllowed('NAME_OF_THE_ROLE') The situation I have got is that when the application goes from dev to higher environment and from there to production the names of the security groups change. Any ideas on how I can inject name of the security in #RollsAllowed() based on what environment I am deploy the application to?
Solution 1: Multiple tolerance
If the name of your role does not change in time and there is no name conflict between environments, you can use the #Secured annotation with the different groups depending on the environment.
For example #Secured({ "DEV_VIEWER", "ALPHA_VIEWER", "PRD_VIEWER"})
Solution 2 : Hand made
Otherwise, if you want something, you can switch to the #PreAuthorize annotation with a Custom PermissionEvaluator.
Baeldung made a rather complete guide on the subject https://www.baeldung.com/spring-security-create-new-custom-security-expression
I have multiple closely related problems in Spring Security. I am developing using Spring Boot and am using Spring Data REST for creating REST endpoints directly from my repositories.
I have multiple entities and the requirement is to have all these entities as REST endpoints. I am letting spring-data-rest handle the creation of these endpoints and I am securing these endpoints by adding #PreAuthorize and #PostAuthorize to the entity repository methods as and where required. This works great when I am calling an endpoint like /entity/id.
But I am facing issues from here. Let's say I have 2 entities, Entity1 and Entity2 and they have a One to One relationship. Spring data rest allows me to fetch the related Entity2 data from Entity1 like /entity1/id/entity2. But I have different access rights over Entity1 and Entity2 and calling the above endpoint only checks the access rights as set up in the repository for Entity1 only. So, if a user has access to Entity1 table and no access to Entity2 table, he can still see some Entity2 data via the foreign key relationship of Entity1. Is this a correct design?
Moreover we have some custom API endpoints wherein we have to aggregate data from multiple entity repositories. Also, these endpoints themselves have to secured. So, I am using a #PreAuthorize over an endpoint method. This works as expected and the endpoint method is called only when the expression is valid. But, when a repository method is called (via a service class of course), the #PreAuthorize over that repository method is also evaluated. I would like to have the check done with at the beginning. Is it possible to do so?
Any suggestions to improving the design is also welcome.
There is no simple solution without massively modifying/overriding lots of default Spring DataRest features. I'm working such a package for years now and it's working quite well for me.
Although switching to this package might be a bit overkill for you, it could worth the trouble in the long run because it also a fixes a lot of problem you will meet only months later.
you can set up permisison rules via annotation directly in the domain objects.
it checks the permisisons in the DB side, so the traffic between the API and DB is heavily decreased (Only those objects are fetched form the DB which the current user has permission to)
you can set READ/UPDATE/DELETE/CREATE permissions separately for roles and/or certain users
you can use pagination on permission filtered collection
you can use pagination on property-collections too
(+ some extra features like flexible search on multiple properties)
here is the package (It's an extension of Spring Data JPA / Data Rest)
Spring Security has this basic idea of a Principal and GrantedAuthority. I've implemented Spring Security and read this stackoverflow and understand at a basic level that a "ROLE" is nothing more than a GrantedAuthority prefixed with "ROLE_".
What I don't understand is why have this convention in the first place? Why have #PreAuthorize("hasRole('XYZ')") be equivilant to #PreAuthorize("hasAuthority('ROLE_XYZ')")?
What's so special about segregating Granted Authorities like this? What's the purpose?
Additionally, what is the best convention for applying these "ROLES" to specific instances of a Domain Model. Take for example a system that keeps track of projects and you want to explicitly give users access to view and edit certain projects. I could create ROLE_EDIT_PROJECT and ROLE_VIEW_PROJECT but that's application-wide. Where would you make the relationship of a ROLE to a specific project? A join table? Would you even involve Spring Security into this or build this type of security from scratch within your application?
I unfortunately don't know why this convention is used, probably just legacy code I would guess.
For the second part of your question, I would suggest using "hasPermission(project, 'view')" and define your own PermissionEvaluator.
more information can be found here
I'm coming from the PHP world. The framework I used most is Symfony which is heavily based on ideas from Spring. One if its bundles called JMSSecurityExtraBundle supports a role ROLE_IDDQD that you can activate via configuration. Authenticating with that role would effectively bypass all the security checks — be those Web security constraints or constraints directly on methods of classes in the domain layer.
Since security related tests needed a user with a particular role to be authenticated, I would authenticate a user programmatically creating an authentication object and passing it to the security context. That way I could test security constraints directly on the domain code without involing any UI.
Since a lot of domain methods would be secured, it would prevent me from setting up fixtures for some of the tests because the currently authenticated user wouldn't have enough permissions to do that. This is where I started using ROLE_IDDQD — I created a method that would take a function that could do anything in the domain layer bypassing any security constraints:
$user = $this->iddqd(function () {
return $this->userManager->save($this->aUser());
});
That method would remember the current authentication, reauthenticate with ROLE_IDDQD, execute the function passed in and then restore the remembered authentication.
I'm migrating the app to Spring and looking for a way to do the same with Spring. I couldn't find any mention of ROLE_IDDQD, so I guess that part wasn't based on Spring Security. Are there any other means to replicate this functionality?
Spring security has a concept of Anonymous user with automatically assigned role "ROLE_ANONYMOUS". You can look for more information here
I solved the problem a long time ago. Here's how I did it.
In my architectures, I usually have a repository layer that abstracts away database access and a manager layer above the repository layer that enforces domain logic.
The problem was in my approach to testing. I tried to use managers to set up test data. I now do it directly using repositories and there's no need for hacks like IDDQD roles and such.
So, basically, I use repositories to populate databases with test data, and then I hit managers to test domain logic in them.
What security features does Spring provide that are not already provided by the Java EE specs?
In the Java EE specs we have:
A range of sevlet security options in the web.xml. Most people will configure basic or form based authentication. They link their Java EE application to an LDAP server - which stores users / groups. Request will be encrypted and come in over HTTPS.
Possibility to annotate any EJB and only allow certain roles execute certain methods
Ability to check user principle at runtime programmatically
So what security extras does Spring 3.0 give me?
Even if you just need some fairly simple authentication, Spring Security provides support for lots of simple but useful features (think of redirecting after logout, redirecting to login page on all URLs, remember-me). With Java EE you'll end up writing this yourself and - possibly - screwing up so you'll have an insecure app.
Spring Security works well with many standards/protocols/etc. out of the box (LDAP, JAAS, X.509). There's also more advanced stuff like SSO or ACLs. And if the standard functionality doesn't suit you, you can customize this fairly easily, often requiring just a little code.
What I also like is that it's fairly non-intrusive, your controller/action/… classes typically don't have to be involved.
That said, if you use it for the first time, it takes some time to set Spring Security up and get used to it.
(Finally, here's their own feature list: http://static.springsource.org/spring-security/site/features.html)
One killer Feature are ACLs!
#See: Spring Security Reference Chapter 17. Domain Object Security (ACLs)
And I have the feeling that Spring Security is much easier to customize. For example if you need a User Management where the User can self register and get some of this privileges limitedly and some others after this email address has been confirmed.