Versions Compared

Old Version 28

changes.mady.by.user David E Tanner

Saved on

compared with

New Version Current

changes.mady.by.user Stephen Turner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Info

Help is available by sending an email to csf-support@mit.edu
Have any suggestion on how improve this wiki?  Please give us your feedback at csf-support@mit.edu

Panel

About this document

This document is a brief description of the processing that occurs to authenticate and authorize an HTTP request using Spring Security and the CSF, highlighting features that are useful for application developers to know about.

The processing has two parts. One part is performed by Spring Security, and the other part is performed by CSF code.

Panel

Quick Links to:

Table of Contents
minLevel3
Panel

Spring Security

Spring Security is part of the Spring Framework and it abstracts authentication and authorization processing in a manner that allows them to be customized for a particular set of requirements. For web applications, Spring Security is "plugged in" as a servlet filter. If the Spring Security servlet filter is configured in the web.xml then Spring Security will be called on each request to the servlet.

Spring Security processing is composed of parts that are assembled into what is called a "filter chain". Those parts are themselves customized by injection of service beans. The filters in an Spring Security filter chain are not the same as servlet filters, although the general concept is the same. The filter chain determines the sequence of authorization and authentication processing, and the inclusion of authentication protocols.

The end result of running the filter chain is that access is either granted or denied to the resource requested. Granted access creates an Spring Security Security Context for the request, which an application may consult for roles and user information collected previously during the Spring Security processing.  Denied access should cause an access denied message to be returned to the user.

Panel

CSF

The CSF provides a wrapper around Spring Security, so that applications are not directly tied to a particular security framework implementation. It also provides services to the Spring Security 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 :

  • MIT Roles database
  • Student role
  • Instructor role
  • STV_ROLES
  • STVACC roles

With potentially many more possibilities.

It also provides an impersonation function that is useful during testing and problem diagnosis.

It also provides local development environments a way to test different roles and users with an application.

...

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.

The "pattern" attributes specify which URL(s) are to be restricted. Patterns can specify a specific page, as in the above examples, or can specify a range of URLs via wildcards. For example, the following pattern would restrict all pages under the "admin" folder to users with the "ADMIN" role:

Code Block

    <security:intercept-url pattern="/admin/*" access="ROLE_ADMIN" />

Overlapping patterns can also be specified: the latter-defined patterns will override the earlier patterns. An example of this usage would be a section of a web site generally restricted to DINING users, but with certain pages also open to REGISTRAR users. We would define a general pattern to implement the DINING users restriction, and a second more specific pattern giving the REGISTRAR users access to particular pages:

Code Block

    <security:intercept-url pattern="/dining/*" access="ROLE_DINING" />
    <security:intercept-url pattern="/dining/some_shared_page.htm" access="ROLE_DINING,ROLE_REGISTRAR" />