...
basicAuthenticationProcessingFilter: If authentication has not already been established ( that is by either being present in the session or by SSO ), and the local.authentication property has been set in the application property file, performs HTTP Basic authentication. The user is prompted for a username and password, which must match what is configured in the application property file. This filter is intended as a solution to running the application with a security context in the absence of SSO, which is what is needed the situation on developer's local workstations. This filter checks that the user and password entered in the login prompt in the browser match the property values for Local Authentication Properties.
| Panel |
|---|
Local Authentication Properties: A set of standard properties that tell the security framework. The following properties are used for local authentication. local.authentication=true All of these properties must be present. The local authentication |
...
properties should never be set on SAIS servers. |
...
|
| Code Block |
|---|
exceptionTranslationFilter: catches all exceptions from the filters that follow. Applies configured exception handlers based on the exception type caught. For example, if an AuthenticationException is thrown, indicating that the request is not authenticated yet, then it calls the method to start the authentication process. If an AccessDeniedException is thrown, indicating that authentication has failed, then the AccessDeniedHandler is called. The default handler simply sends an access denies http response code in the response header.
...
mitsisRolesUserDetailsService: acts as an adapter between the Acegi security system and the authorization classes in the SAIS framework.
Basic Authentication: Acegi handles all the requirements of the Basic authentication protocol. It is a two step process. An unauthenticated request will result in a challenge response header sent to the browser that will result in 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 and processed by the basicAuthenticationProcessingFilterand the credentials are compared to the values from the application 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. Since the first request does not contain the credentials header, it always falls through the filter chain to the filterSecurityInterceptor, which will throw an exception ( if the requested resource should be secured ), which is caught by the exceptionTranslationFilter, which in turn results in the challenge response being issued. You also may wonder, if there is now a second request required, what happened to the first one which actually has the resource you want to view ? It is temporarily stored in the session and then resumed if authentication and authorization succeed. So Acegi does a lot of work here that you normally do not have to worry about.