Understanding the Spring Security Architecture

Developed since Ben Alex and team in 2003, Spring Security is a framework that helps provide authorization and authentication to Java applications. The official release date of stable Spring Security was April 2008. With 3.9k stars and 3.3k forks on Github, its popularity is amply self-explanatory.

However, before you dive deep into the intricacies of Spring Security framework, you need to understand the basics of the same. Since the main job of Spring Security is to secure web applications, that is what we’re going to focus on throughout this article. Also, we assume you are aware of Spring Boot before jumping to Spring Security as it provides for a default stage to work with. Nevertheless, all principles discussed herein will apply to applications not built using Spring Boot as well.

Runtime Environment for Spring Security

As per the existing Spring Security architecture, Java 5.0 or higher is needed to run Spring Security successfully. The great part about this is that one need not include any special files in their Java Runtime Environments. Spring is a very self-contained framework and hence you need not put the Spring Security folders in any specific classpath locations. While this sounds super cool, how does the fact that all your files will be contained in the application itself (EJB) sound? That’s right, while running an EJB container you need not conjure up special files or configuration files in a server classloader.

Copy your JAR, WAR, EAR directly from one computer to another and it will work perfectly fine, thanks to the incredible architecture of Spring Security.

Building Blocks of Spring Security

Spring Security is mainly built upon:

• SecurityContextHolder, an object that uses ThreadLocal to store the security context of a process. It provides access to SecurityContext.
• SecurityContext which holds the object Authentication. It requests for the metadata and security information of the object.
• Authentication represents the principle requesting for access.
• GrantedAuthority which holds information regarding what permission is granted to whom throughout the application.
• UserDetails which holds information to build up Authentication.
• UserDetailsServices. Pass a String to it and it will make a UserDetail which will, in turn, help generate an Authentication object.

Authentication and Authorization

A basic application security problem is primarily about who has the access to information and what is he allowed to do with it? The latter is the authentication problem while the former refers to the authorization problem. Spring Security is a great tool to separate both these problems and tackle them efficiently.

Authentication

Authentication has one main interface: AuthenticationManager which has just one method: authenticate. It can do three things: return a bool authentication value, throw an exception if there is an invalid value detected, as well as return a null when it encounters ambiguity.

Here’s what a standard authentication scenario looks like:

• A login screen is displayed asking for username and password.
• A system in place recognizes successfully if the password for the given username is correct.
• List of roles and permissions for the user is obtained.
• A security context is established.
• The user proceeds towards performing tasks once validated. Then comes the role of access specifiers and the system moves on to the process of authorization.

There are a number of classes, interfaces and instances that make this happen. The main ones are UserPasswordAuthenticationToken, AuthenticationManager, Authentication, and SecurityContextHolder. SecurityContextHolder.getContext().setAuthentication(…) is the method used for step number four.

Authorization

Sometimes, authorization is also known as access control. The ring leader here is AccessDecisionManager. The method ‘decide’ takes the object requesting access and assesses its metadata and decides whether or not a particular action can be performed by the object.

This is how a web app authorization process looks like:

• The user clicks on a link on the home page.
• Request is sent to the server who realizes the user is requesting for a protected piece of information/resource.
• The server sends back the message that you must authenticate. This means the server will probably redirect you to a webpage. If your browser authenticates you via cookies, it’s a different story.
• The browser will send back your authentication information to the server.
• The server will make sure that your credentials are right. If not, access will be denied.
• Now, you will be either allowed to access the resource or will be served with a “403: Forbidden” HTTP error code.

Note: The three main classes to carry out the above steps are ExecptionTranslationFilter, AuthenticationEntryPoint, and AuthenitcationManager.

Closing Thoughts

Spring Security is a comprehensive framework with a solid architecture that allows you to integrate Servlet APIs. It is a great choice for Java applications. To put it simply for millennials who began their careers with Python instead of Java, Spring Security does what Django does for your Python application and more. OAuth2, OpenSSL, Let’s Encrypt, and Auth0 are other frameworks out there in the market attempting to do what Spring Security does.

Companies like Monkey Exchange, Debut, Monbanquet, AfricanStock, ZapLabs, OfferPointer, Mubasher.info, Site, Insoft and so many more make use of Spring Security in their technology Stack. And thanks to its open source status, if you’re getting started with Spring Security you have over twenty thousand answered questions on Stackoverflow waiting to assist you.

Professionals of Java Development in India have shared this article to brief you about Understanding the Spring Security Architecture.