...
The processing has two parts. One part is performed by Acegi, and the other part is performed by SAIS framework code.
Acegi
Acegi is a package that tries to abstract authentication and authorization processing in a manner that allows them to be customized for a particular set of requirements. For web applications, Acegi is "plugged in" as a servlet filter. If the Acegi servlet filter is configured in the web.xml then Acegi will be called on each request to the servlet.
...
The end result of running the filter chain is that access is either granted or denied to the url requested. Granted access creates an Acegi Security Context for the request, which an application may consult for roles and user information collected previously during the Acegi processing. Denied access should cause an access denied message to be returned to the user.
SAIS Framework
The SAIS framework provides a wrapper around Acegi, so that applications are not directly tied to a particular security framework implementation. It also provides services to the Acegi filter chain that handle the specifics of authentication and authorization as are customary or required at MIT. For example, it provides services for SSO authentication, and the following services to obtain roles either separately or in combination :
...
It also provides local development environments a way to test different roles and users with an application.
The Filter Chain Proxy and the Acegi filters
Complexity is the price of flexibility. There are several interacting system artifacts, the components and their configurations.
...
There are several other filters in the SAIS frameworkFramework.
The Authorization
...
Framework
As mentioned above, filters that authenticate users also get the "details" for the authenticated user, that is, the user's authorizations, to put into the security context. In the SAIS framework, there is a single bean that is configured to get the user details, the MitsisRolesUserDetailsService.
...
authorizationService bean: SAIS framework bean that implements the AuthorizationService interface. In this example, it is an implementation that delegates to a chain of other AuthorizationService implementations, one for determining if the user is a student, and another to obtain the roles the user may have in the MIT Roles database. The combine = false property means that roles from the two services will not be combined, that is, either the role student will be assigned to the user or the MIT roles, but not both. If combine = true the user would be assigned all roles found.
Application access to a user's roles in the Security Context
It is not uncommon for applications to need access to roles information that may be collected by Acegi and the SAIS framework. The SAIS framework attempts to provide facilities to make this easier. Lets take the example of an application that needs to display a list of sections for the user to choose, which will allow them to view the students assigned to the section, and there is a rule that the class lists are only to be shown to instructors of the section.
...
The mask method takes a collection of things that might be associated with a role and returns a set of things that actually are associated with the role. The things you can filter this way depends on the kind of role. For instructors, you can filter collections of subjects, sections, or teaching assignments. For MIT Roles Database roles that have qualifiers you can filter a collection of strings that would match the qualifier codes.
Impersonation
Impersonation that is a regular part of an application's feature set delivered to MIT administrators is accomplished with an additional filter on the Acegi filter chain called the switchProcessingUserFilter.This basically gives authorized users a "login" button or link that logs them in as another user. Once the switch is performed, the SecurityContext contains the credentials for a different user, but it also remembers the original user so impersonation may be exited and the original credentials restored.
There are a couple of things that are required to use this filter. First, there must be a role, usually in the MIT Roles database, associated with users allowed to do the impersonation. Second, the login url should be protected at the page level with this role. Third, the login url, and a logout url, should be implemented and configured on the filter. Fourth, the filter should be added to the filterChainProxy bean configuration, after the filterSecurityInterceptor, since we have to get the "can impersonate" role first. ( Example TBD )
Page level security
One may also configure a mapping of roles to page urls. In the example above where we were testing if a user had the instructor role before showing them a page to select sections to view, instead of writing code, we could have declared our protection like this:
...