Spring Security architecture

Spring Security is implemented as a filter chain. Each request to a protected resource goes through the filter chain. Each filter in the chain can either ignore the request (by passing it to the next filter in the chain), or do something and then pass it to the next filter in the chain, or generate a response and terminate the chain.

Refer to the Spring Security documentation for a list of default filters provided by Spring.

Of the many components involved in Spring Security, the component shown in the diagram below is the most important for MicroStrategy Library authentication.

• The Security Context object contains information about the currently authenticated user. It is accessible to all the Java code handling the request via the thread-local object SecurityContextHolder.
• The Login Processing Filter is responsible for handling login requests. Normally, this filter is triggered based on URL patterns. If a request URL matches one of the patterns configured for the filter, it will try to authenticate the user based on information contained in the request; otherwise, it will simply pass the request to the next filter in the chain.
• The Filter Security Interceptor is the last line of defense in the security filter chain. It is responsible for making sure that no unauthenticated request reaches protected resources. If this filter determines that a request to a protected resource is not authenticated, it delegates to the Login Entry Point bean responsible for initiating the login dialog with the user.

The diagram below shows the generic workflow for an unauthenticated non-login request, such as the initial request to start an application.

This request passes untouched by the Login Processing Filter because its URL does not match any of the URL patterns configured for this filter. Eventually, this request reaches the Filter Security Interceptor, which passes it to the Login Entry Point. The Login Entry Point usually redirects the browser to a component that generates a GUI, such as a JSP page, a servlet, or an external SSO (single sign-on) site.

The diagram below shows the generic workflow for a login request—a request that contains user authentication information.

In the normal workflow, the URL of the login request matches one of the Login Processing Filter URL patterns. When a match is found, the Login Processing Filter handles the request by:

1. Extracting authentication information from the request
2. Authenticating the user
3. Storing the authentication information in the Security Context

After successful authentication, the browser is redirected to the original request.

The workflow described above works well when an application supports only one authentication mode. However, MicroStrategy allows customers to configure their applications to support multiple authentication modes. The diagram below shows the changes that have been made to the architecture to support multiple authentication modes.

The Login Processing Filter is replaced by a Multi-mode Login Filter containing a collection of Single-mode Login Filters. The Login Entry Point is replaced by a Multi-Mode Entry Point containing a collection of Single-mode Entry Points. When a request is processed, the Multi-mode Login Filter and the Multi-mode Entry Point delegate to the appropriate single-mode component depending on the current authentication mode.