...
The InstructorAuthorizationService has a single method, getAuthorizationsByUser. This method uses the dao to fetch the user's instructor records from MITSIS. These instructor records are as an AuthorizedInstructor object containing a collection of AuthorizedTeachingAssignment objects. This is wrapped in an InstructorRoleAuthorization object which is an adaptor for communicating with Acegi. All of this is done merely by creating the configuration above.
...
| Code Block |
|---|
boolean isInstructor = securityContextService.hasAnyRole(new String[] { InstructorRoleAuthorizarionInstructorRoleAuthorization.ROLE_INSTRUCTOR });
if ( isInstructor ) {
|
Impersonation
Set allowedSections = securityContextService.getMaskedQualifiersForRole(InstructorRoleAuthorization.ROLE_INSTRUCTOR, allSections);
// put allowedSections in model map ...
} else {
// not so fast buster !
|
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 userswitchProcessingUserFilter: This is an optional filter that the allows a user to invoke a URL that lets them impersonate another user. Since access to this feature usually requires that the request be authorized for the URL resource that performs the switch, it follows the filterSecurityInterceptor in the chain. 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 ( see below ). Third, the login url, and a logout url, should be implemented and configured on the filter.
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 simple declared our protection like this:
...