Spring Security - Annotation Based Method level Security Handler

Introduction



Spring Security 3, apart from securing URL’s based on priviledge i.e. roles (The basic authorization process),
also provides the ample scope of implementing method level security with annotations at the business layer, and thus ensuring no unauthorized calls would be made at the methods at the corresponding layer. The implementation of method level security is being accomplished with the help of Spring managed AOP
approach to recognize, evaluate and secure method invocations. The basic flow can be described as follows:
• Spring AOP runtime intercept calls to the methods of interest by implemeting
aspects with the help of MethodSecurityInterceptor.

• The MethodSecurityInterceptor with the help of AccessDecisionManager, and the corresponding
AccessDecisionVoters of the AccessDecisionManager makes the authorization decision.

Generic Configuration Details



The AOP proxying is not invoked for all Spring Mannaged Beans by default.
Declaring in Spring Security Configuration will result in the
registration of BeanPostProcessor that will introspect AOP configuration to see if any AOP advisors indicate that proxying is required.
This workflow is a standard Spring AOP handling known as AOP auto proxying.
The AOP auto proxying functionality queries all registered PointcutAdvisors to see if
there are AOP pointcuts that resolve to method invocation that should have AOP advice applied and the pointcuts
are being identified by Annotations. (like @PreAuthorize,@PostAuthorize).
Depending on the number of Spring beans configured in your application,
and the number of secured method annotation,
adding method security proxying may increase the Application Context Intialization
duration, but once Spring Context is initialized there is negligible performance impact on indivudual proxied beans.
This is in short about underlying operation mechanism for implementing
method level security as provided by Spring Security 3.2. We are going to use this architecture to create a ecustom label which we can use in
our Annotation based method level security Handler. We know the labels currently supported by Spring Security Framework are like hasIpAddress, hasPermission etc.
Say the name of our label be isSichern and we are going to implement preAuthorize filter with it,
i.e. the expression evaluation will happen before method execution. If the expression evaluation result is positive then only the method
will be executed, otherwise an Access Denied exception will be thrown. The whole expression will look like:
“ @PreAuthorize("isSichern('<>','<>','<>')") ”
With the above annotation in action whenever methods annnoated with the above mentioned annotation will
be invoked then the registered PriviledgeEvaluator will perform the business security validations for the parameters passed along with
isSichern and authorization decisions are Taken Based on that. The basic Configuration Part consists of:

xmlns:security="http://www.springframework.org/schema/security
http://www.springframework.org/schema/security
    http://www.springframework.org/schema/security/spring-security-3.2.xsd

	<security:global-method-security
            				pre-post-annotations="enabled">
       	<security:expression-handler ref="defaultExpressionHandler"/>		     				
  </security:global-method-security>

  <bean id="defaultExpressionHandler" class="org.springSecurity.methodhandler.CustomMethodSecurityExpressionHandler">
  	<property name="permissionEvaluator">
<bean autowire="constructor" class="org.springSecurity.methodhandler.DefaultPermissionEvaluator"></bean>		
</property>
<property name="priviledgeEvaluator" ref="priviledgeEvaluator"></property>
  		
 </bean>

<bean id="priviledgeEvaluator" class="org.springSecurity.methodhandler.CustomPriviledgeEvaluator"></bean>

I will discuss the remaining custom configuration details along with the Code in my next post, Till then happy coding

Comments

Post a Comment

Popular posts from this blog

Use of @Configurable annotation.

Not, all types(beans) used in a Spring Based Application are Spring managed. Sometimes, we need to inject some dependency into some Types which are not Spring Managed. The most common example being, injection of Service or DAO layer within the Entity class. Now the instances of Entity classes are being created using the new operator, i.e. they are not Spring Managed. Now we want to inject the corresponding Service or DAO Type which is Spring Managed within these Entity Types, and these can be performed with the help of @Configurable . It is the Aspects, which performs all the underlying engineering and ,makes this thing possible. Let's see an example. @Configurable public class Person { @Autowired ResourceBundleThemeSource themeSource; private String firstName; private String lastName; private int age; private Address address; @CustomDateFormat Date birthDate; MultipartFile profile; public String getFirstName() { return firstName; } public voi...
Read more

Spring WS - Part 5

Spring WS provides an easy integration with various WS-Security features with the help of interceptors like Wss4jSecurityInterceptor, XwsjSecurityInterceptor. We are going to explore here very basic feature of WS-SECURITY i.e. implementing Security using with UserNameTokenAuthentication We are going to use Wss4jSecurityInterceptor as it is very easy to configure. We are going to use configure two interceptors: 1) One for the Server End. 2) Other for the Client End. For Server End The configuration for Wss4jSecurityInterceptor is as follows: @Bean public Wss4jSecurityInterceptor wss4jSecurityInterceptor() { /** * The SecurementActions for UsernameToken is commented, as the * UsernameToken is to be added by the client, the server-side * interceptor would only validate that. * */ Wss4jSecurityInterceptor wss4jSecurityInterceptor = new Wss4jSecurityInterceptor(); wss4jSecurityInterceptor.setValidationActions("UsernameToken"); ...
Read more

Spring WS - Part 4

Another interesting and essential feature is the attachment part. Now I found two things out here. The attachment can be inline within the SOAP message body (suitable as long as the attachment size is not too long) or we can enable MTOM feature within the marshaller and leverage the MTOM-XOP feature. For the attachment to be inline with the SOAP message body, no actual configuration are required, everything is being taken care by the Spring WS framework, except the following: &ltxs:element name="getCountryRequest"&gt &ltxs:complexType&gt &ltxs:sequence&gt &ltxs:element name="name" type="xs:string"/&gt &ltxs:element name="file" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream"&gt&lt/xs:element&gt &lt/xs:sequence&gt &lt/xs:complexType&gt &lt/xs:e...
Read more