Hi we are implementing ABAC over SpringSecurity (looks same as Axiomatics solution). So we would like to define custome expression and customize underlaying mechanisms. e.g. #PreAuthorize("myexpression").
At this point I'm trying understand how can I get information about the target method (the JoinPoint): name, class, parameters. I didn't find how to do it for SpringSecurity customization.
As I Inderstand, other solution may be implemention based direct on AOP e.g. #Around, however I would like to try first to find out if the Spring Security can provide me a way to get somehow JoinPoint it self, isn't it implemented over AOP ?
If anyone have an example, thanks.
I would recommend checking out the new support for #PreAuthorize in Spring Security 5.6 with #EnableMethodSecurity. See the reference docs for information on how to customize the interceptors. There are numerous places you can hook into this support based on your requirements using delegation or fully replacing components with your own implementation.
In your case, it seems the most likely place to start would be creating an #Bean to replace the AuthorizationManagerBeforeMethodInterceptor:
#Bean
#Role(BeanDefinition.ROLE_INFRASTRUCTURE)
Advisor preAuthorizeAuthorizationMethodInterceptor() {
PreAuthorizeAuthorizationManager authorizationManager = new PreAuthorizeAuthorizationManager();
authorizationManager.setExpressionHandler(...);
return AuthorizationManagerBeforeMethodInterceptor.preAuthorize(authorizationManager);
}
You will have to implement the MethodSecurityExpressionHandler, but you can use delegation to re-use the DefaultMethodSecurityExpressionHandler for anything you don't want to implement yourself.
Related
I'm currently using DataFetcher for GraphQL-Java in Springboot based on the tutorial here. This works well, but I'm looking for another way to get the endpoints without implementing DataFetchers, as it seems like extra work where I have to (1) implement the resolver method, then (2) create a separate method for the corresponding DataFetcher. Is there another way to consolidate this to expose my GraphQL API a la some form of Rest controller? I have looked around quite a bit but haven't found any workable solution. Preferably (not sure if it's related) there would be a better way of annotating the endpoint as well (currently provided in the linked example with RuntimeWiring, which I'm hoping to remove as well).
In short, I would like, in Springboot, to not need for RuntimeWiring and DataFetcher (primarily this so as to remove double code for the same method and improve maintainability), and instead have another way to configure the global REST controller for my GraphQL-Java code, while also having another way to annotate the endpoint (maybe some annotator on top of the implemented methods).
Thanks!
Managed to fix it by using graphql.kick.start.tools' SchemaParser and GraphQLResolver as follows:
return SchemaParser.newParser()
.files(schemaFiles)
.scalars(scalars)
.resolvers(resolvers)
.dictionary(typeDictionary)
.build()
.makeExecutableSchema();
where the resolvers were implemented using this amazing plugin as codegen.
In this blog post, the subject of creating a new Webflowconfigurer to extend the web flow is covered.
In the examples provided this is done through classes that extend the AbstractCasWebflowConfigurer and introducing new actions that are appended to the webflow through the included process.
Is extending already existing configurers like for instance AcceptableUsagePolicyWebflowConfigurer and overriding some of its methods feasible or is that outside the scope of CAS web flow? If its feasible, what is the correct way to do this?
p.s. currently on version 5.3.x
Is extending already existing configurers like for instance AcceptableUsagePolicyWebflowConfigurer and overriding some of its methods feasible or is that outside the scope of CAS web flow?
Yes, that is feasible.
If you examine this block, you will find that AcceptableUsagePolicyWebflowConfigurer is only created conditionally, if an existing bean is not already found in the context by the same name. So to provide your own, you just need to register a bean with the same name using your own #Configuration class. Something like this:
#Bean
#DependsOn("defaultWebflowConfigurer")
public CasWebflowConfigurer acceptableUsagePolicyWebflowConfigurer() {
return new MyAcceptableUsagePolicyWebflowConfigurer(...);
}
public class MyAcceptableUsagePolicyWebflowConfigurer extends
AcceptableUsagePolicyWebflowConfigurer {}
To learn about how #Configuration classes work in general, you can:
Review this post
or This post
or consult the documentation for Spring and/or Spring Boot.
Is there an example of extending the cas login webflow using Java for cas 6.x. I assume this can be done without having to modify the login-webflow.xml.
https://apereo.github.io/cas/6.1.x/webflow/Webflow-Customization-Extensions.html does not explain very well where these changes need to be made at.
I want to use AOP concept to time execution time of some methods that I mark with an annotation that I created. My problem however is that I refer to the annotated method internally, from within the same class. For example:
public void login(params) {
some logic ...
performLogin();
some logic ...
}
#Measured
public void performLogin() {
some logic ...
}
This is a known issue caused by the fact that Spring AOP is using proxy based approach that does not "see" the internal calls within the same class. Apparently I can solve this situation by using AspectJ instead of Spring AOP. If I understand correctly, it can be configured from within Spring itself. From what I found, it looks like I should include #EnableAspectJAutoProxy annotation to configure Spring to use AspectJ instead of its own AOP. Unfortunately, it did not help and after adding the annotation, the interception of the annotated method did not occur.
There is a lot of information on this topic in Spring reference documentation and I got a bit lost. Is there anything else I am supposed to do so that AspectJ will be used?
P.S. Please note that I cannot refactor the whole class and move the calling method outside.
P.P.S. I also verified my pointcut configuration. I annotated the calling method which is invoked externally and it worked fine.
Proxies can only achieve a sub-set of the full capabilities of the actual AspectJ system, basically advice that wraps methods. Due to their nature proxies have following limitations:
interception on external calls only (while breaching proxy boundary)
interception on public members only (private/protected can't be intercepted)
unawareness to local calls (or calls with this or super)
<aop:aspectj-autoproxy /> is not enough - it only wraps methods, you need something like this: <context:load-time-weaver/>
If you want to be able to advise fields for example, you would need to enable the use of Native AspectJ.
I am new to spring security framework.I was just compiling the various ways to add security features using spring security annotations or spring security framework.
Found the below so far.
Full Page Authorization
example: <intercept-url pattern="/user/**" access="hasRole('ROLE_USER')" />
In-Page Authorization
example : <security:authorize access="hasRole('ROLE_ADMIN')">
Method Level Authorization - #PreAuthorize,#PostAuthorize,#PreFilter,#PostFilter
I am not sure if this is an exhaustive list to secure the application. Need some help for the same. Thanks.
Also,I am looking for security features which can easily be implemented and configurable- where developers are less likely to make mistakes and at the same time achieve the required security goals.It looks like annotations are easy to use and less ambiguous. Are annotations used only for method level authorization? Does spring security provide annotations which can be used for securing other parts of the application and can these annotations be passed parameters to configure the permissions or privileges?
I hope my question is not too broad. Any edits or helpful comments would be appreciated.
Perhaps you need to start by identifying the requirements of your domain model, what is deemed sensitive data and what not and how this data is being accessed (HTML/JSP vs REST/JSON vs direct Java calls). Then use the authorization features as needed. Your list contains pretty much what most applications will ever need, but for finer and more advanced authorization mechanisms have a look at Spring's ACL:
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/domain-acls.html
Another important question you may want to answer to yourself is which application layer will be responsible for enforcing your security: MVC/REST vs Services (scattering this concern across multiple layers is usually bad idea). This will directly dictate the choices of SS features you are going to make.
You may wish to build your own annotations on top of SS annotations which reflect closely your particular domain. This way all complexity will be concentrated in a single place, leaving less room for error.
For example, you can create a custom annotation such as #AuthorizedFor where you can add various domain-specific parameters. You then annotate this annotation with one of SS annotations, say #Pre/PostAuthorize("hasAnyRole()") (here you can also play with the Spring's native EL to further customise the behaviour) and use custom implementation of Pre/PostInvocationAuthorizationAdvice where you make the authorization decisions based on your custom annotation parameters. The added advantage here is that you will be able to secure complete classes with your custom annotation instead of having to annotate all methods in that class. In your implementation you get the MethodInvocation instance from where you can interrogate the class containing the method and see if its annotated, then proceed as-if the method itself was annotated.
See this article for more in-depth discussion: http://blog.novoj.net/2012/03/27/combining-custom-annotations-for-securing-methods-with-spring-security/
There are basically 2 ways to implement spring security. through bean configuration in .xml files and other by using Annotations. Annotation based method is easy to use in long term as it is less ambiguous.
here is the reference to spring.io . Both ways are explained nicely.
http://spring.io/blog/2013/07/03/spring-security-java-config-preview-web-security/
Annotation is pure java based configuration and will most probably overtake xml configuration.
The three items in your list serve different purposes:
intercept-url : Adds security at the servlet layer. In other words, you control who can/cannot access any url in your application. For example you may add permission only to administrators to access the url /admin/some_critical_operation, but allow all authenticated users to access /some_informational_page. It is possible to secure your application with this type of authorisation only but it is very fragile design. Adding or changing urls can easily break security without notice.
In-Page Authorization: It is not real authorisation, just a convenience tag for hiding html content not intended for the current user. For example a non-admin user should not see the button create new user. As I said it is not real security measure since the user can type the url in the browser and gain access if none of the other authorisation types have been applied.
Method Level Authorization: Adds security to the service layer. This means you can apply restrictions on who can/cannot call a method of some service class. It is considered more secure and harder to compromise since it is applied deeper in the application layer stack. It can be applied both with annotations and with the security namespace.
Usually you start by securing your application in the service layer and then add some url control as well. Adding authorisation tags in pages is optional.
I can't comment yet, but regarding your question:
Are there annotations which are configurable? For example, I provided the method level security annotations where you provide the parameters - like the roles of users who have the privileges to access the method or to access the elements returned by the method
You are free to write your own annotations, which are in turn annotated with the native Spring Security annotations. This makes them essentially a domain-specific extension. That said, the standard SS annotations allow the use of SpEL which is rather flexible even tough is not bound to your particular domain. You can easily assert if user has certain roles (GrantedAuthority), etc ...
If you want to implement your own annotations, see the link in my other answer for a thorough discussion.
I can give you a concrete example from a recent project I worked on. We had authorization groups managed by external system and also built-in logic which defines access to certain resources. So, essentially we had 2 places to look for authorization parameters. We've created the concept of Authorization Groups (retrieved externally via LDAP) and Authorization Roles (built-in, business logic). The groups were simple - if user is a member of the group, they are granted access, else denied. With the roles, we had business rules which determine whether the user has a particular role or not (for example - signed T&C, accepted EULA, etc ...). All of these are determined at the authentication stage.
To make it easier to reason about our access control, we created two annotations #AuthorisedForGroups({group1, group2, ...}) and #AuthorisedForRoles({role1, role2,...}). Each of these was in turn annotated with Spring's native #PreAuthorize("hasAnyRole()"). Note the use of "hasAnyRole()" - this is simply to tell Spring "let everybody who is authenticated in" and that "we are going to make the authorization decisions ourselves". The authorization decisions are then made in a custom implementation of PreInvocationAuthorizationAdvice (in fact we just extended Spring's own implementation ExpressionBasedPreInvocationAdvice) and put the decision-making logic in #before() method:
#Override
public boolean before(Authentication authentication, MethodInvocation mi, PreInvocationAttribute attr) {
// 1) get AuthorisedForGroups & AuthorisedForRoles for the method
// 2) if either is missing from the method, check the enclosing class
// 3) if no annotations found - simply return super.before(...)
// 4) else, introspect the 'authentication' and see if it has the required groups/roles
// - here you may want to use 'ExpressionBasedAnnotationAttributeFactory' to
// create your own expressions which you then pass to super.before(...).
// This especially makes sense when your groups/roles
// are mapped to GrantedAuthority instances - as it was the case with our code.
}
Hope this helps.
I want to add validations to a Java Bean. For example, I want to do the following:
#MaxLength(50)
#RequiredField
public void setEmployeeName(String name){
.....
}
I know I can write code that gets the validations for a specific method by calling method.getDeclaredAnnotation after all the bean values have been set. I would like to avoid writing this code
Is there anything in Java6 that gives standard validations via annotations? Do I need aspectj to invoke these annotations?
thanks in advance.
You can use Bean Validation Framework. Here is short overview
http://relation.to/Bloggers/BeanValidationSneakPeekPartI
take a look at JSR 303. The RI (Reference Implementation) is here, with also a nice tutorial. And no, you don't need AspectJ.
The only way you'll be able to do this is through reflections and a custom validation utility/interceptor/proxy. JSR 303 and JSR 305 were proposed to introduce similar functionality, but nothing like this exists.
One of the problems you'll run into is that these annotations need to be handled at some sort of framework level, or at a minimum, intercepted before some sort of invoked action. The two most common sense, brute force ways of doing this would be done either by creating a utility, or by validating pre-invoke in an invocation handler (proxy).
The reality is that unless this is built into Spring, Struts, Guice, Java itself, etc., you're just creating unnecessary overhead and you're better off checking for validation bounds on demand.