Explore topic-wise InterviewSolutions in .

@RolesAllowed: It is a Java standard annotation (JSR250) (i.e., not only spring security). Because this annotation only supports role-based security, it is more limited than the @PreAuthorize annotation. To enable the @RolwesAllowed annotation in your code, add the following line to spring-security.xml and spring boot. 

@Secured: It is a Spring specific annotation. There is more to it than just role-based security. It secures methods implemented by beans (objects whose life-cycle is managed by the Spring IoC). HOWEVER, Spring Expression Language (SpEL) is not supported for defining security constraints. To enable the @Secured annotation in your code, add the following line to spring-security.xml and spring boot. 

Spring Security is ONE of the most popular, powerful, and highly customizable access-control frameworks (security framework) that provide authentication, authorization, and other security features for enterprise applications. In this article, we have compiled a comprehensive LIST of Spring Security Interview questions, which are typically asked during interviews. In addition to checking your existing Spring Security skills, these questions serve as a good resource for reviewing some important concepts before you appear for an interview. It is suitable for both freshers as well as EXPERIENCED developers and tech LEADS. 

Additional Useful Resources

Interview questions on Java

Interview questions on Spring Boot

Spring MVC vs Spring Boot

Spring vs Spring Boot

A variety of security options are available with SPRING Framework. This framework offers many useful tools or methods for securing applications. In order to PROVIDE method-level security, @Secured and @PreAuthorize are the most commonly used annotations. Compared to @Secured, @PreAuthorize is quite new but becoming well known very fast. There aren't many differences between @Secured and @PreAuthorize; they're nearly identical. However, @PreAuthorize is CONSIDERABLY more powerful than @Secured. 

• ROLE_USER: It has no relevance unless you assign it to your users as soon as they are AUTHENTICATED. You are responsible for loading the ROLES (AUTHORITIES) for each authenticated user.
• ROLE_ANONYMOUS: When a configuration uses Spring Security's "anonymous AUTHENTICATION" filter, ROLE_ANONYMOUS is the default role assigned to an anonymous (unauthenticated) user. ROLE_ANONYMOUS is ENABLED by default. However, it would be better if you used the expression isAnonymous() instead, which has the same meaning.

YES, ordering is crucial when we have multiple intercept-URL PATTERNS. Multiple intercept URLS should be WRITTEN from more specific to less specific. As intercept-URL patterns are processed in the order they appear in a SPRING security configuration file, the URL must match the right pattern.  

<Intercept-url&GT; is used to configure authorizations or access-controls in a Spring Security application. It is used to RESTRICT access to a particular URL. The majority of WEB applications using Spring Security usually have just a few intercept-URLs because their security needs are quite less.  

Example: Basic Spring security using intercept URL 

In this case, index.jsp and admin.jsp can be accessed without authentication. ANYTHING with admin in the URL requires ROLE_ADMIN access, and anything with trade in the URL requires ROLE_TRADER access. 

FilterChainProxy is ANOTHER servlet FILTER designed to invoke the APPROPRIATE filters based on the path of the INCOMING request. It contains INFORMATION about the security filters that make up the security filter chain. It is not directly executed, but it is started by the DelegatingFilterProxy. 

A servlet filter must be declared in the WEB.xml file so that it can be invoked before the REQUEST is passed on to the actual Servlet class. DelegatingFilterProxy is a servlet filter embedded in the spring context. It ACTS as a bridge between web.xml (web application) and the application context (Spring IoC Container). DelegatingFilterProxy is a proxy that delegates an INCOMING request to a group of filters (which are not managed as spring beans) provided by the Spring web framework. It provides full access to the Spring context's life cycle machinery and dependency injection.

Whenever a request reaches the web application, the proxy ensures that the request is delegated to Spring Security, and, if everything goes smoothly, it will ensure that the request is DIRECTED to the right resource within the web application. The following example demonstrates how to configure the DelegatingProxyFilter in web.xml: 

The principal is actually the CURRENTLY logged in user that is using the APPLICATION. Information/data about the principal (currently authenticated user) is stored in the SecurityContext of the application. As a helper class, SecurityContextHolder provides access to the security context. By default, it uses a THREADLOCAL object to store SecurityContext, so SecurityContext is always ACCESSIBLE to methods in the same thread of execution, EVEN if SecurityContext isn't passed around explicitly. 

FILTER chains in Spring Security are very complex and flexible. They use SERVICES such as UserDetailsService and AuthenticationManager to accomplish their tasks. It is also important to consider their orders since you might want to verify their AUTHENTICITY before authorizing them. A few of the important security filters from Spring's filter chain are listed below in the order they occur: 

• SecurityContextPersistenceFilter: Stores the SecurityContext contents between HTTP requests. It also clears SecurityContextHolder when a request is finished.
• ConcurrentSessionFilter: It is responsible for HANDLING concurrent sessions. Its PURPOSE is to refresh the last modified time of the request's session and to ensure the session hasn't expired.
• UsernamePasswordAuthenticationFilter: It's the most popular authentication filter and is the one that's most often customized.
• ExceptionTranslationFilter: This filter resides above FilterSecurityInterceptor in the security filter stack. Although it doesn't perform actual security enforcement, it handles exceptions thrown by the security interceptors and returns valid and suitable HTTP responses.
• FilterSecurityInterceptor: It is responsible for securing HTTP resources (web URIs), and raising or throwing authentication and authorization exceptions when access is denied.

Here's how filters work in a web application:   

• Step 1: The client first sends a REQUEST for a resource (MVC controller). The application container creates a filter chain for handling and processing incoming requests.
• Step 2: Each HttpServletRequest passes through the filter chain depending upon the request URI. (We can configure whether the filter CHAINS should be APPLIED to all requests or to the specific request URI).
• Step 3: For most web applications, filters perform the following functions:
  • Modify or Change the HttpServletRequest/HttpServletResponse before it reaches the SPRING MVC controller.
  • Can stop the processing of the request and send a response to the client, such as Servlets not allowing requests to specific URI's.

Spring Security executes most of its security features using the filter chain. Spring security is driven through SERVLET filters in web applications. A servlet filter intercepts requests before they REACH the PROTECTED resource (e.g., a Spring controller). As a result, every request for a protected resource will be processed through a spring security filter chain for completing authentication and AUTHORIZATION PURPOSES.

JWT (JSON Web Tokens) are tokens that are generated by a server upon user authentication in a web application and are then sent to the CLIENT (normally a browser). As a result, these tokens are sent on every HTTP request, allowing the server to verify or authenticate the user's identity. This method is used for authorizing transactions or requests between client and server. The use of JWT does not intend to hide data, but rather ensure its authenticity. JWTs are signed and encoded, INSTEAD of encrypted. A cryptographic algorithm is used to digitally sign JWTs in order to ensure that they cannot be altered after they are issued. INFORMATION contained in the token is signed by the server's private key in order to ensure integrity. 

• Login credentials are sent by the user. When successful, JWT tokens (signed by private key/secret key) are sent back by the server to the client.
• The client takes JWT and inserts it in the Authorization header to make data requests for the user.
• Upon receiving the token from the client, the server simply needs to compare the SIGNATURE sent by the client to the one it generated with its private key/secret key. The token will be valid once the signatures match.

Three parts make up JSON Web Tokens, separated by a dot (.). The first two (the header and the PAYLOAD) contain Base64-URL encoded JSON, while the third is a cryptographic signature. 

For example: 

Take a look at each of the sections:

The default implementation of AuthenticationManager is PROVIDERMANAGER. It does not HANDLE the AUTHENTICATION request itself, rather delegates the authentication process to a list of configured AuthenticationProviders. Each authenticationprovider in turn is queried to SEE if it can handle the authentication request. 

A Spring Security component called AuthenticationManager tells "How authentication will happen". Because the how part of this question depends on which authentication provider we are using for our application, an AuthenticationManager contains references to all the AuthenticationProviders. AuthenticationManager is the strategy INTERFACE for authentication, which has only one METHOD: 

AuthenticationManagers can PERFORM one of three actions in their authenticate() method: 

• If it can verify that the input represents a valid principal, it will RETURN an Authentication (normally authenticated=true).
• If the input is believed to represent an invalid principal, it will throw an AuthenticationException.
• If it is unable to decide, it will return null.

Some SECURITY ANNOTATIONS that are allowed to use SpEL include: 

• @PreAuthorize 
• @PreFilter 
• @PostAuthorize 
• @PostFilter  

These PROVIDE expression-based ACCESS control. In Spring Security, @PreAuthorize is one of the most POWERFUL annotations that allows you to use SpEL. But the old @Secured annotation cannot use it, for example you cannot write @Secured("hasRole('ROLEADMIN')"), but you can do @PreAuthorize("hasRole('ROLEADMIN')"). 

Spring Framework 3.0 introduced Expression LANGUAGE/ SpEL. In Spring Expression Language (SpEL), QUERIES and manipulations of object graphs are possible at runtime. You can use it with XML and annotation-based Spring configurations. JSP EL, OGNL, MVEL and JBoss EL are some of the expression languages available, but SpEL provides additional features INCLUDING string template functionality and method invocation. 

Example: 

Output: