Page History

...

*

mitAuthorizationUserDetailService

*

bean:

acts

as

an

adapter

between

the

Spring

Security

security

system

and

the

authorization

classes

in

CSF.

*

authorizationService

*

bean:

CSF

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.

[

Panel

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 CSF, there is a single bean that is configured to get the user details, the mitAuthorizationUserDetailService.

Here is a sample configuration:

Code Block

    <!-- the Spring Security adapter for MIT authorizations retrieval -->
    <bean id="mitAuthorizationUserDetailService" class="edu.mit.csf.security.spring.userdetails.MitAuthorizationUserDetailsService">
        <property name="authorizationService" ref="authorizationService"/>
    </bean>

    <!-- MIT Roles database authorization -->
    <bean id="mitRolesAuthorizationService" class="edu.mit.csf.security.service.MitRolesAuthorizationService">
        <property name="applicationConfiguration" ref="applicationConfiguration" />
        <property name="uaSao" ref="uaSao" />
        <!-- all the academic services apps use this domain, same as category in MIT Roles -->
        <property name="domain" value="REG" />
        <!-- if you have this property value in your applicationConfiguration then
        getDomain be overridden with the value this property -->
        <property name="domainProperty" value="roles.function.category"/>
        <property name="functionProperty" value="roles.function.function"/>
    </bean>

The beans and property definitions in this example serve the following functions:

Code Block

}

Panel

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 Spring Security and the CSF. CSF provides facilities to make this easier.

IMPORTANT: when you are writing Java code that needs authorization information about the current user, use the methods on the CSF "SecurityContextService" interface rather than using Spring Security classes. This will insulate us from any future changes in the Spring Security framework classes.

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.

First, we need to configure the authorization service to capture whether the user is an instructor.

Code Block


 <bean id="mitAuthorizationUserDetailService" class="edu.mit.csf.security.spring.userdetails.MitAuthorizationUserDetailsService">
	<property name="authorizationService"  ref="authorizationService" />
 </bean>

 <bean id="authorizationService" class="edu.mit.common.security.authorization.InstructorAuthorizationsService">
        <property name="dao" ref="hibernateAuthorizedInstructorDao" />
 </bean>

In this example, the instructorAuthorizationsService and hibernateAuthorizedInstructorDao bean are Spring beans defined elsewhere. The InstructorAuthorizationService has a single method, getAuthorizationsByUser. This method uses the dao to fetch the user's instructor records as an AuthorizedInstructor object containing a collection of AuthorizedTeachingAssignment objects. This is wrapped in an InstructorRoleAuthorization object which is an adaptor for communicating with Spring Security. All of this is done merely by creating the configuration above.

A little later in the application processing, we will have a list of sections, and we want to filter the list to only include those that the instructor has taught. Probably first you would want to check that the user is in fact an instructor, that is, has at least taught some section at some time, and if not, perhaps show them a different page:

Code Block


boolean isInstructor = securityContextService.hasAnyRole(new String[] { InstructorRoleAuthorization.ROLE_INSTRUCTOR });

if ( isInstructor ) {

  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.

Panel

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 Spring Security 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.

There must be a role, usually in the MIT Roles database, associated with users allowed to do the impersonation.
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 )

Panel

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:

Code Block


	<bean id="filterSecurityInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
		<property name="authenticationManager" ref="authenticationManager"/>
		<property name="accessDecisionManager" ref="accessDecisionManager"/>
                <property name="securityMetadataSource">
                   <security:filter-security-metadata-source>
                         <security:intercept-url pattern="/advisor_reg_summary.htm" access="ROLE_OREG_REGISTRAR,ROLE_OREG_DEPT_ADMIN,ROLE_OREG_ADVISOR" />
                         <security:intercept-url pattern="/agreement.htm" access="ROLE_CURRENT_STUDENT" />
                   </security:filter-security-metadata-source>
                </property>
        </bean>

and the Spring Security framework would have invoked the access denied handler when a user who did not have this role tried to access the page. We could then write the access denied handler to show a page with a friendly message or perhaps redirect the user somewhere they are supposed to be instead.

...

panel

Child pages

Versions Compared

Old Version 25

New Version 26

Key

The Authorization Framework

Application access to a user's roles in the Security Context

Impersonation

Page level security