Spring Security configuration

Through our last articles we could discover that Spring Security can be configured in two ways: the first one using standard Spring beans mechanism. The second one is specific for Spring Security because it uses its own XML schema definition (XSD). In this article we'll focus on the second method.

New ebook 🔥

Learn 84 ways to solve common data engineering problems with cloud services.

👉 I want my copy

At the begin we'll present a sample configuration based on Spring Security's XSD. We'll describe it shortly. After, we'll analyze each part separately, in more detailed way. Thanks to it we'll understand better how Spring knows which beans must be used for each of <http /> configuration or how it resolves the name of <user-service />.

Spring Security configuration based on XSD

To illustrate Spring Security configuration based on XML schema, we'll use the same sample application as in previous articles. Its configuration looks like:

<security:http authentication-manager-ref="frontend" auto-config="true" use-expressions="true"
  <security:intercept-url pattern="/logout" access="isAuthenticated()" />
  <security:csrf />
  <security:logout logout-url="/logout" logout-success-url="/login" 
    invalidate-session="true" delete-cookies="JSESSIONID" />
  <security:form-login login-page="/login" default-target-url="/secret/data"
    authentication-failure-url="/login?error=true" password-parameter="password"
    username-parameter="login" login-processing-url="/do-login" />
  <security:remember-me data-source-ref="dataSource" 
    key="secret_remember_me" user-service-ref="inMemoryUserService" />
  <security:session-management invalid-session-url="/invalid-session" 
      <security:concurrency-control expired-url="/expired-session" 
        max-sessions="1" error-if-maximum-exceeded="true" />
  <security:custom-filter ref="oneShootAuthFilter" after="CONCURRENT_SESSION_FILTER"/>

<security:authentication-manager id="frontend">
    user-service-ref="inMemoryUserService" />

<security:user-service id="inMemoryUserService">
  <security:user name="bartosz" password="bartosz" 
    authorities="ROLE_ADMIN,ROLE_USER" />
  <security:user name="admin" password="admin" 
    authorities="ROLE_ADMIN,ROLE_USER" />
  <security:user name="mod" password="mod" 
    authorities="ROLE_USER" />

<bean id="oneShootAuthFilter" class="com.waitingforcode.security.filter.OneShotActionFilter">
  <property name="authenticationManager" ref="frontend" />
  <property name="userDetailsService" ref="inMemoryUserService" />

You can observe there 3 main parts: http, authentication-manager and user-service. To define them quickly, we can consider the http element as the security context for one application area (for example: frontend, backend, site parts reserved to connected users). As to authentication-manager, it defines the way of handling users authentication. It uses user-service, which is the last component. As you can deduce, it provides the layer thanks to which we can check if one user can be authentified or not. The last bean, oneShootAuthFilter, is defined here only to understand better one of http's components, <custom-filter />.

Spring Security configuration builders

As we could see in this article, underlying process for Spring Security configuration based on namespace is based on BeanDefinitionParser instances. They analyze provided XML configuration and construct appropriate BeanDefinition objects. This process is made by configuration builders which are sometimes coupled, as user-service or authentication and http filters in <http /> tag. In additionally they can take different options which can trigger a lot of different actions. It makes the code more verbose to read and a little bit more complicated to understand. Even, if the main method is still the same as in the rest of Spring projects.

If you liked it, you should read:

The comments are moderated. I publish them when I answer, so don't worry if you don't see yours immediately :)

📚 Newsletter Get new posts, recommended reading and other exclusive information every week. SPAM free - no 3rd party ads, only the information about waitingforcode!