This document is a brief description of the processing that occurs to authenticate and authorize an HTTP request using Acegi and the SAIS Framework.
The HTTP request is passed through a series of intercepted in a servlet filter, that delegates to a collection of Acegi filters, called the filter chain. Each filter performs a specific task in a particular order. The filter chain can be configured in the applicationContext-web.xml file, or in a separate The filter chain ensures the sequence of authorization and authentication processing, and manages authentication protocols and access to security information about users. Upon successful authentication and authorization it establishes a SecurityContext for use by the application.
The filter chain is configured in the Spring Context, the servlet filter in web.xml. SAIS applications will use either Spring Context configurations for security will be in either applicationContext-common-security.xml fileor applicationContext-web.xml, located in src/main/resources of the application. Upon successful authentication and authorization a SecurityContext is established that can be used by the application.
The configuration bean that holds for the filter configuration chain is called the filterChainProxy. As the name suggests, it acts as an interface to the filter chain. A servlet filter using this proxy class is defined in the web.xml so it gets used by the servlet.Here is a sample configuration:
| Code Block |
|---|
<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy"> <property name="filterInvocationDefinitionSource"> <value> PATTERN_TYPE_APACHE_ANT /css/**=#NONE# /dhtml/**=#NONE# /images/**=#NONE# /js/**=#NONE# /**=httpSessionContextIntegrationFilter,exceptionTranslationFilter,ssoAuthenticationProcessingFilter,mitBasicProcessingFilter,filterSecurityInterceptor,switchUserProcessingFilter </value> </property> </bean> |
...
ssoAuthenticationProcessingFilter: If authentication has not already been established in the SecurityContext ( that is was not present in the session ), checks to see if the user is already set in the servlet request, indicating that SSO has authenticated the user. If so, it sets up all the data structures needed by the security context, and sets them into the context. This includes the list of roles that the user is authorized for, based on the results of calling the configured authorization services ( see below ).
mitBasicProcessingFilter: If authentication has not already been established ( that is by either being present in the session of or by the ssoAuthenticationProcessingFilter SSO ), and the local authentication property has been set in the application property file, performs Basic authentication against the local credentials configured in the application property file. Basic authentication is a two step process that requires two requests. The first request that is unauthenticated will result in an AuthenticationException, which results in the start of the Basic authentication process, which sends a response with an authentication request in the header. Browsers interpret this to show the familiar ugly login box to the user. When the user submits the login credentials in what is now the second request, it contains a header with the credentials. The presence of this header is detected by the mitBasicProcessingFilter and the credentials are compared to the values from the property file. If there is a match the data structures for the security context are configured including the list of roles from the configured authorization services. However in this case the presence of role properties in the application property file will bypass the calls to the authorization services.
...