Spring security tutorial

Spring security pre-authentication scenario assumes that a valid authenticated user is available via  either Single Sign On (SSO) applications like Siteminder, Tivoli, etc or a X509 certification based authentication. The Spring security in this scenario will only be used for authorization.

The example shown below retrieves the user name via the HTTP headers.

Step 1:  The dependency jars that are required.

Step 2: Define the Spring security filter via the web.xml file.

Step 3: The servlet filter configured above will make use of a spring context file like  ssoContext.xml to define the authorization sequences. The ssoContext file can be imported via the applicationContext.xml file bootstrapped via the web.xml file.

Step 4: The ssoContext.xml is defined below showing how the user can be retrieved from HTTP header SM_USER for site minder and passed to your own implementation to retrieve the roles (aka authorities). All the classes configured below are Spring classes except for the UserDetailsServiceImpl, which is used to retrieve the authorities.

Step 5: Define the class UserDetailsServiceImpl class that needs to implement the Spring interface UserDetailsService and the required method   “public UserDetails loadUserByUsername(String username)”. The returned model object  “UserDetails” is a Spring class as well.

Start annotating your Java methods and the URLs that intercept the calls to verify the roles (or authorities) returned for a given user against the roles allowed for a method or URL.

Let’s will see how we can protect the controller and the service class methods by defining what roles are allowed.

Firstly, you can protect your controller as shown below.

Step 6: Define the URLs to be protected in the ssoContext.xml file something like

In the Spring MVC controller, you can use the annotation as shown below.

The service class methods can be protected by declaring the following in your spring context file where the methods reside.

Once declared, you can protect your service class methods as shown below.

Q. How will you access Spring security context details within a method that is annotated with @RolesAllowed?
A. The answer is to use the SecurityContextHolder class’s static method. It is a ThreadLocal class. Each thread has its own value of ThreadLocal  pointing to the same instance of SecurityContextHolder  class. Here is the sample code snippet. You can get the principal and the authorities as shown below.

Q. How do you map multiple authentication managers?
A. You can define multiple authentiaction managers based on URL patterns as shown below.

Here is a sample config for one of the http mappings:

Q. The roles are stored in the session, how will you make sure that the roles are read every time from the database?
A. It is generally a good practice to leave the roles in the session, and the session gets invalidated on logout. There are times you want the roles to be read from the database and not from the session. This can be accomplished by

Step 7: Writing a response filter to remove the roles from the Http Session. Here is the code snippet.

The SecurityHolder.getContext( ) has a clearContents method, but it will only remove it from  the current thread but not the session. 

Prepare to fast-track & go places

Answers are detailed to be useful beyond job interviews. A few Q&As each day will make a huge difference in 3 to 24 months depending on your experience.