I have gone through the Spring Security video on this page.
Around 36:30 he talks about securing methods using security annotations along with the method signature as shown below:
#Secured("ROLE_USER")
public String create();
Why do we need to keep the annotations along with the method? (since security annotations do not have anything to do with what the method does)
Can I get these annotations out into a separate file so that I can change them without modifying the actual code? (probably using something like Spring AOP features)
Yes, you can do it thanks to Spring AOP:
<global-method-security>
<protect-pointcut expression="execution(* com.domain.service.*.*(..))" access="ROLE_USER"/>
</global-method-security>
Ajust expression to your needs.
XML declarations are good from flexibility point of view. Consider following cases:
you want to reuse some service in two modules but you want to have different security rules.
you want apply some security restriction on per package basis
It is possible only with XML.
Annotations are good from readability point of view. When you see some method then you can view all security restrictions directly. No need to open some XML file each time and think about expressions (is it applied for this method?). So it's easy.
Do not mix both approaches. It's so confusing. Check your needs and choose the best one for you project.
Related
We have a medium sized business app and we use Spring Security roles and permissions (RBAC) heavily with a big kludge to turn roles on and off for certain instances plus rules hidden in SpEL within #PreAuthorize tags.
I think what we have actually implemented (without knowing it is ABAC). XACML looks very complicated and bloated so I'm not keen on the answer here:
How to change Spring Security roles by context?
Has anybody done a light weight ABAC implementation without XACML? I have hopes that would give us separation of concerns as the domain objects just do #PreAuthorize(WRITE) etc and our authorisation policy would be decoupled from it.
From what I've read the basic principal of ABAC is very simple. You have an Action (very like a Permission) and a mechanism to resolve if the current Principal has that permission on a given Subject.
I'm aware of AccessDecisionVoter which is roughly the right sort of interface but I don't think it was intended for voting on permissions. However implementing our authorisation policy with instances of something like those seems very attractive.
Sorry for the rambling question! Basically I'm interesting in ABAC but would like to avoid home brew but worried what XACML is a jumbo jet when we need a Cessna.
There seems to be two things you are aiming for:
externalized authorization, where you want to move access control policies out of the code (or at least into a central place in the code and not scattered across the Spring code)
attribute based authorization, where you want to use richer attributes than roles and permissions
I am not very sure of (2) since what you say you want to do, "action and a mechanism to resolve if the current Principal has that permission", is still, in my books, RBAC. Do you have other conditions on which access grant decisions will need to be based on? Location of the user, time of day, value of certain data in a database, properties of the resource being acted on etc.? If so, we stray into the ABAC world. Either way, I would say that RBAC is a subset of ABAC since a role is just one attribute.
Now, as for (1), the general pattern would be to first centralize the authorization engine and use the Spring annotations to call this authz. engine for access decisions. You have two choices here:
embedded authz. engine: where a library implements the engine and is called by the code just as a Java function. Could be a XACML engine or could be your own RBAC/ABAC implementation
as a network service: where a network based (micro) service answers access control decision questions. Could be a XACML engine or could be your own RBAC/ABAC implementation
In order to get the Spring based code to call this authz. engine, one approach would be to write your own Spring Security voter. Another way, which I found much easier, would be to write your own Spring Expression Language based expressions that you can then call with the existing #PreAuthorize, #PostAuthorize, #PreFilter and #PostFiler, sec:authorize tags and even from intercept-url conditions.
This is what I used when I worked on our Spring Security XACML PEP SDK. The approach should work equally well even if you decide not to use XACML for your access decision policies or the request/response communication.
A pretty nice approach without XACML can be found here. It's basically what you wanted. A lighweight approach on ABAC without implementing XACML.
https://dzone.com/articles/simple-attribute-based-access-control-with-spring
I know this question is rather old, but recently we had need for similar ABAC permissions implementation. At first I tried to find something existing which would fill our needs, but everything seemed to be over the top and very hard to use.
So I came up with very simple library called jaclp which can be found on GitHub. It supports classical RBAC approach and more complex ABAC which can be used for example on JPA entities acting as resources. The integration and setup should be fairly simple.
One of the disadvantages is that for now, definition of permissions is programmatically only. I plan to introduce configuration file from which permission rules would be loaded. Also jaclp library for now supports only static permission rules defined in code, this means that you cannot load permission rules dynamically for example from database.
Example Usage:
// Applying permissions on REST endpoints
#GetMapping("groups/{id}")
#PreAuthorize("hasPermission(#id, 'group', 'viewDetail')")
public GroupDetailDTO getGroupDetail(#PathVariable long id) {
return this.groupService.getGroupDetail(id);
}
// Defining role with both RBAC and ABAC approach
Role userRole = RoleBuilder.create("user")
.addAllowedRule("group",
(UserDetails user, GroupEntity group) -> group.isPublic(),
"viewDetail")
.addAllowedRule("group", "viewAll")
.build();
I am using Grails and as my project's requirement I want to connect to databases as per users requirement. So I have to take the DB credentials like username,password,URL from user. How can I connect to their databases by setting these values in datasource at run time. Is there any way that I can set these values dynamically?
I will explain the concept and leave the implementation up to you. Be aware, this isn't exactly simple and does require you to do some research into the details, but if you are willing to do so, you can accomplish this.
The basic concept here is that each data source in your application is defined as a Spring bean. This is the default behavior of any Grails application. As such, you can replace a bean with a newly defined one. In your case you will want to do this with your second data source. The bean name is determined by how you have it named in your DataSources.groovy.
Take a look at the Spring section of the Grails documentation where it shows some examples of configuring a data source. The same concept will apply in your case. Just be sure you use the correct bean name and that you also call the destroy/close method of the existing bean before you replace it.
Depending on how you implement the replacement (and if you use a GenericBeanDefinition or not) you may want to use grailsApplication.mainContext.registerBeanDefinition(beanName, beanDefinition).
As I stated, this can be done, but you are going to have to learn a bit about the internals of Spring and bean definitions, as well as the API to build and manipulate them at run time.
Hope this helps get you started.
JSF 2.0 comes up with annotation. However in JSF 1.2 we defined attributes in faces-config.xml file.
In JSF 2.0 we have two options, either make use of annotation or use faces-config.xml. What is better approach? Writhing the properties in faces-config.xml is easily manageable, whereas writing annotation in each file is somewhat not easily manageable.
Annotations are generally preferable because they keep information about a class with the code of the class, so you don't have to look in another place to understand it. It also reduces duplication of information because you don't have to write out the class name to specify what class the annotation belongs to.
Then again, for some things it can be valuable to have all information of a certain kind collected in one place (e.g. URL mappings). Fortunately, annotations and XML configuration are compatible, so you can put some things into XML and use annotations for everything else.
Well, this is absolutely depends on you, but annotations are the "modern" way of programming. Code is becoming more readable and maintainable with them. IMHO annotations are less vulnerable to errors because you don't have to maintain a huge file of XML entries, but you have just few lines of annotations per each file(also it's nice when you open a file and immediately see that this class is a managed bean). so code is becoming more self-commenting.
If I were you I would definitely go with annotations, IMHO it's far more easy to manage them.
Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
#Stateless
#RolesAllowed("javaee")
public class HelloEJB implements Hello {
#PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager OnExecute method; I pretend to use the TAction.Name property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.
One can use things annotations like:
#Secured(['ROLE_ADMIN'])
on an actions or on an entire class (seems to work fine), to apply the security control provided by spring security core. Is there a way to apply security to the hidden scaffolded actions, without applying the security constraint to the whole class? I want to use one security constraint for some actions, and a different one for the hidden scaffolded actions.
NOTE: if this isn't immediately do-able/answerable, please disregard, as I will generate the code and include it in that way. I searched and didn't see it, so I'm just wondering if someone knows how to do / if it exists.
If you're using annotations you can secure non-annotated urls with the grails.plugins.springsecurity.controllerAnnotations.staticRules config property - see section "5.1 Defining Secured Annotations" in the docs