An AuthenticationManager implementation stores GrantedAuthorities into an Authentication object in the SecurityContext. These GrantedAuthorities are read by the AccessDecisionManager in an attempt to match them against accesses' requirements.

The AccessDecisionManager implementations can be native or external and this explains why the infrastructure forces the authorities to be rendered as Strings.

If a getAuthority() method is not able to represent the GrantedAuthority as a String, then it should return null, indicating to the AuthenticationManager that it has to support this type of Authority.

This mechanism constraints the different getAuthority() implementations into limited responsibilities.

We have mentioned the Configuration attributes when we were introducing the GrantedAuthority objects (Authenticating over a BASIC scheme recipe).

Configuration attributes play a key role in SecurityInterceptor and indirectly in AccessDecisionManager implementations, since SecurityInterceptor delegates to AccessDecisionManager. Configuration attributes implement the one-method ConfigAttribute interface:

public interface ConfigAttribute extends Serializable {
  String getAttribute();
}

We have defined the following instruction in our security-config.xml file as a way to tell Spring Security to expect the configuration attributes ROLE_BASIC on web requests matching the /basic.html pattern:

<security:intercept-url pattern="/basic.html" access="hasRole('BASIC')"/>

With the default AccessDecisionManager implementation, any user having a matching GrantedAuthority will be granted the access.

For a voter-based AccessDecisionManager implementation, a configuration attribute beginning with ROLE_ the prefix will be considered as a role and should be examined by a RoleVoter. We will see more about AccessDecisionManager in the next sections.

SecurityInterceptor protecting Secure objects are objects or actions that require a security examination. There are two types of secure objects that are handled by the Framework:

A security interceptor (method or HTTP request) intercepts asynchronously (event-based) every single secure object invocations before they actually reach the resource. Spring Security always applies a simple pattern when handling those invocations. This pattern comes from the use of AbstractSecurityInterceptor subclasses.

The AbstractSecurityInterceptor examinations impose a consistent workflow to Secure Objects:

This workflow can be summarized with the following diagram:

The original graph for this picture comes from the Spring Security reference. It is interesting because it highlights the different elements that SecurityInterceptor can use when examining a secure object.

A RunAsManager dependency can optionally be added to SecurityInterceptor on rare occasions where the SecurityContext Authentication object may need to be altered (step 3 of the workflow). The interface is defined as follows:

public interface RunAsManager {
  Authentication buildRunAs(Authentication authentication, Object object, Collection<ConfigAttribute> attributes);
  boolean supports(ConfigAttribute attribute);
  boolean supports(Class<?> clazz);
}

If no dependency is set for RunAsManager, the SecurityInterceptor will run a NullRunAsManager implementation. An AfterInvocationManager interface may optionally be configured and used to alter the statusToken object returned by the invocation (step 5 of the workflow).

An AccessDecisionManager decides whether an access must be allowed or not.

public interface AccessDecisionManager {
  void decide(Authentication authentication, Object object, 				Collection<ConfigAttribute> configAttributes) throws AccessDeniedException, InsufficientAuthenticationException;
  boolean supports(ConfigAttribute attribute);
  boolean supports(Class<?> clazz);
}

public interface AccessDecisionVoter<S> {
  boolean supports(ConfigAttribute attribute);
  boolean supports(Class<?> clazz);
  int vote(Authentication authentication, S object,
  Collection<ConfigAttribute> attributes);
}

There is only one AfterInvocationManager implementation in Spring Security: AfterInvocationProviderManager. This class aligns all the eligible AfterInvocationProvider implementations to give them the opportunity to alter the SecurityInterceptor result.

Similar to the AccessDecisionManager interface, the AfterInvocationProvider interface looks like this:

public interface AfterInvocationProvider {
  Object decide(Authentication authentication, Object object, Collection<ConfigAttribute> attributes, Object returnedObject) throws AccessDeniedException;
  boolean supports(ConfigAttribute attribute);
  boolean supports(Class<?> clazz);
}

Since Spring Security 3, it is now possible to use Spring Expression Language (EL) in order to define the Web security and methods security.

The base class for expression root objects is SecurityExpressionRoot. This abstract class gives access to the following methods and properties which represent the common built-in expressions:

<security:global-method-security pre-post-annotations"="enabled"">

@PreAuthorize("hasRole('ADMIN')")
public class MonitoringController extends CloudstreetApiWCI{
  ...
}

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(Contact contact, Sid recipient, Permission permission);

@PreAuthorize("hasRole('USER')")
@PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')")
public List<Contact> getAll();

<security:global-method-security...>
  <security:expression-handler ref="expressionHandler"/>
</security:global-method-security>
<bean id="expressionHandler" class="org.sfw.security.access.expression.method.DefaultMethod SecurityExpressionHandler">
  <property name="permissionEvaluator" ref="myPermissionEvaluator"/>
</bean>

public interface PermissionEvaluator extends AopInfrastructureBean {
  boolean hasPermission(Authentication authentication, Object targetDomainObject, Object permission);
  boolean hasPermission(Authentication authentication, Serializable targetId, String targetType, Object permission);
}

JSR-250 is a Java specification request that has been released in 2006. It specifies a set of annotations to address common semantic patterns. Among these annotations, some relate to security:

Spring Security supports these annotations but this support has to be activated:

<security:global-method-security jsr250-annotations"="enabled""…/>

Spring Security also supports its legacy @Secured annotations, if enabled:

<security:global-method-security secured-annotations"="enabled""…/>

Some more complex applications may require authorization decisions to be taken, depending upon the actual domain object that is subject to method invocation:

http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#domain-acls

You might need to find extra information about the Spring EL:

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html

The Spring and Security reference and the Spring JavaDoc have been the main source of information for this recipe. We hope you have enjoyed our information selection, analysis, and point of view.

http://docs.spring.io/spring-security/site/docs/current/apidocs/

http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle