Core Spring 4.2 Study Guide answers (part 5: Security)

What is the delegating filter proxy?

Delegating filter proxy is a servlet filter registered with the web container that delegates the requests to a Filter implementation on the Spring context side. That is there a 2 places servlet filters are attached to:

1. Web container 
2. Spring context

As of Spring Security all requests pass through delegating filter proxy that is registered with the container and then go to FilterChainProxy (another filter but this time on the Spring context side).

Delegating filter proxy may be declared in 2 ways:

1. In web.xml (from WEB-INF folder)
2. By extending AbstractSecurityWebApplicationInitializer

Delegating filter proxy will pass requests to the filter whose name is springSecurityFilterChain.

What is the security filter chain?

Spring uses a chain of filters that is customizable by pulling in and taking out some filters as well as customizing them. This chain of filters is called security filter chain (bean from the Spring context is called springSecurityFilterChain). Filters that build the chain are created when you enable web security.

In the notes several predefined filters were shown. Do you recall what they did and what order they occurred in?

1. ChannelProcessingFilter, because it might need to redirect to a different protocol
2. SecurityContextPersistenceFilter, so a SecurityContext can be set up in the SecurityContextHolder at the beginning of a web request, and any changes to the SecurityContext can be copied to the HttpSession when the web request ends (ready for use with the next web request)
3. ConcurrentSessionFilter, because it uses the SecurityContextHolder functionality and needs to update the SessionRegistry to reflect ongoing requests from the principal
4. Authentication processing mechanisms – UsernamePasswordAuthenticationFilter, CasAuthenticationFilter, BasicAuthenticationFilter etc – so that the SecurityContextHolder can be modified to contain a valid Authentication request token
5. The SecurityContextHolderAwareRequestFilter, if you are using it to install a Spring Security aware HttpServletRequestWrapper into your servlet container
6. The JaasApiIntegrationFilter, if a JaasAuthenticationToken is in the SecurityContextHolder this will process the FilterChain as the Subject in the JaasAuthenticationToken
7. RememberMeAuthenticationFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, and the request presents a cookie that enables remember-me services to take place, a suitable remembered Authentication object will be put there
8. AnonymousAuthenticationFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, an anonymous Authentication object will be put there
9. ExceptionTranslationFilter, to catch any Spring Security exceptions so that either an HTTP error response can be returned or an appropriate AuthenticationEntryPoint can be launched
10. FilterSecurityInterceptor, to protect web URIs and raise exceptions when access is denied

Are you able to add and/or replace individual filters?

Yes you can do that in both XML and Java ways and moreover you can choose to place that filter before/instead or after some predefined filter.

For XML in <custom-filter/> with attributes:

1. before
2. position
3. after

In Java in the class that extends WebSecurityConfigurerAdapter you have to override the method with following signature: protected void configure(HttpSecurity http) and do as follows:

@Configuration
public class CustomWebSecurityConfiguration
  extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.addFilterAfter( // <==== PAY ATTENTION TO THIS
          new OurCustomFilter(), UsernamePasswordAuthenticationFilter.class);
    }
}

Is it enough to hide sections of my output (e.g. JSP-Page)?

Spring Security has a special tag library (http://www.springframework.org/security/tags) that can be used for hiding/not generating parts of JSP depending on access level but this may be not enough. You may wish to verify if user has access to the URL at all and only then allow for accessing the view. In this case for <xxxxx:authorize/> tag you have to use the url attribute instead of access. Url attribute must match the one from some security rule. If user is not allowed to access that resource he will get a 403 error page.

Why do you need the intercept-url?

<intercept-url/> from <http/> is used to define the URL for the requests that we want to have some security constraints. This tag has a pattern attribute that accepts either ant style paths or regex for matching the required resources. Access attribute accepts comma-separated roles that will be allowed to access the resource (any match will grant the access).

Why do you need method security? What type of object is typically secured at the method level (think of its purpose not its Java type).

If we secure only the web layer there may be a way to access service layer in case we expose some REST endpoints. That’s why usually services are secured at method level.

Is security a cross cutting concern? How is it implemented internally?

Yes security is a cross-cutting concern. Spring Security internally is implemented using AOP – the same way as Transactions management.

What do @Secured and @RolesAllowed do? What is the difference between them?

There annotations are used to declare some methods as secured. The difference between them is that @Secured is a Spring annotation while @RolesAllowed is a JSR250 annotation. For enabling @Secured annotation you have to set the securedEnabled attribute of @EnagleGlobalMethodSecurity to true:

@Configuration 
@EnableWebSecurity
@EnableGlobalMethodSecurity(securedEnabled=true) // for JSR-250 use jsr250enabled="true" 
public class SecurityConfig {
.....
}

or, in case of XML:

<beans>
...
<global-method-security secured-annotations="enabled"/> // for JSR-250 use the jsr250-annotations="enabled" attribute
...
</beans>

What is a security context?

Context that holds security information about the current thread of execution. This information includes details about the principal. Context is held in the SecurityContextHolder.

In which order do you have to write multiple intercept-url’s?

Most specific patterns must come first and most general last.

How is a Principal defined?

A principal is a user, device or system that can perform some actions in the application. The principal is established during the authentication process. An implementation of AuthenticationManager called ProviderManager sends an Authentication to a list of AuthernticationProviders and those return an Authentication with all the credentials.

This authentication is held in the SecurityContext.

So for obtaining current principal we have to do something like:

Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();

this returned object type (it can be just the username as a String or a UserDetails object ) depends on the implementation of the AuthenticationProvider. 

What is authentication and authorization? Which must come first?

Authentication is the process of identifying whether this user exists.

Authorization is the process of determining what it may or may not do.

In which security annotation are you allowed to use SpEL?

1. @PreAuthorize
2. @PostAuthorize
3. @PreFilter
4. @PostFilter

For them to be accessible you have to enable the pre-post-attribute to “enabled” in the <global-method-security/> element.

Does Spring Security support password hashing? What is salting?

Spring Security uses PasswordEncoder for encoding passwords. This interface has a Md5PasswordEncoder that allows for obtaining hashes of the password – that will be persisted. The problem is that there are “dictionaries” of hashes available on the internet and some hacker may just match the hash with a record from those dictionaries and gain unauthorized (from system’s point of view authorized) access. To avoid that you can add some “salt” to the pass before it is hashed. Perfectly that salt (which is some appended string) is some random value – a simpler implementation is to use the user id. 

There is a implementation of PasswordEncoder – BCryptPasswordEncoder that generates the salt automatically and thus you don’t have to bother about this.