ShibbolethWebAuthIntegration
This page discusses how we plan to integrate Shibboleth and WebAuth within the project. It is not the only way to do the integration, but it is the way that looks like it makes sense to us in our situation.
Contents:
Contents
1. Environment
OUCS at Oxford has an existing WebAuth service and is actively promoting it as the way to do authentication within the institution. Part of the promotion is the availability of local experts to help service providers set up and install the system. They also provide an LDAP service with user attributes.
The Sakai VRE demonstrator project is funded to build a Shibboleth federation and good practice says that user information should be stored in as few places a possible. Thus we're planning on using WebAuth as the local source of authentication for Shibboleth.
2. Approach
We're planning on setting up a WebAuth protected Shibboleth (identity provider) IdP to provide authentication of locally registered uses to the federation. Because WebAuth provides only a username and not the full set of attributes that Shibboleth works with, we need to provide a means of harvesting extra information about the user once they have authenticated. In a production service this information would likely come from one (or more) LDAP or other directory services, and/or a local directory store for Shibboleth-specific attributes.
3. Diagram
Dashed arrows indicate use of HTTP, solid arrows indicate other protocols. The shaded areas are areas outside the control of the project.
This diagram does not show any federation, in particalar the WAYF (Where Are You From) service is absent.
- The User uses their browser to access a page in the Portal. The Shibboleth service provider (Shib SP) detects whether this action requires authentication or authorisation and checks whether the user can perform the action. If the user is already authenticated and has authorisation, or if the atcion requires no authentication, steps 2 to 15 are ignored and step 16 is taken. If authentication is required and the user is not authenticated, the Shib SP takes step 2. If the user is authenticated but not authorised, an error message is generated. (The optional WAYF step sits here)
The Shib SP generates a browser redirect sending the user to the Shibboleth identity provider (IdP). This redirect is intercepted by a mod_auth (or similar) wrapper around the IdP which checks to see whether the user is logged into to WebAuth. If the user is logged into WebAuth (as determined by the contents of cookies), the request is passed through to the IdP along with the users WebAuth username (step 7). If the user is not logged in to WebAuth, step 3 is taken.
The user is redirected to the WebAuth login page, with username and password entry boxes for the local WebAuth system.
- The username and password are checked using the Kerberos standard (RFC 4120)
The the information returned from Kerberos is whether or not authentication succeded, a username and some kerberos tickets wrapped in cookies. These cookies allow for the input of a username and password to be skipped while they are present and valid (usually 12 hours). This means that subsequent WebAuth authentication can be handled invisibly to the user (or can display a click though login screen, depending on local configuration) .
If successful, WebAuth pass a success status and username back to the mod_auth. If unsuccessful the user never gets redirected back.
mod_auth detects the presence of WebAuth cookies, checks their validity and forwards passes the request to the IdP, along with the username.
- (deleted)
The IdP maps the WebAuth into a Shibbeloth name identifier (suitable for federation) and returns it to the SP.
- The SP then asks the IdP for attributes for the name identifier
- The IdP maps the name identifier back to the local username and gets attributes from LDAP
- Which returns institution attributes
- The IdP can also ask a local attribute store
- Which returns Shibboleth-specific properties
- The IdP returns these to the attributes to the SP
The SP makes the decision whether to permit the user to perform the SAKAI action. The decision is based on whether anon access is permitted and/or the user attributes. We need to understand this better, in particular the situation when a user is already authenticated.
- SAKAI passes the name identifier the component portlets, none of which need be aware of how it was derived or any authorisation aspects.
- The portlets return their content, personalised for the name identifier
The SAKAI compiles the portal from the portlet results and passes the results back through the SP or maybe goes back directly?
- The SP passes the results back to the user.
3.1. Diagram TODO
- Note which protocol each arrow uses
- Note which arrows need to be secure (and how they are secured)
- normalise numbers
- use colours for domains
4. Limitations of this approach
The WebAuth model assumes that users hit a deadend if they fail to log in (and doesn't appear to allow for redirection to anonymous login), whereas the Sakai / Shibboleth allow "lazy sessions" in which users as anonymous by default adn then redirected to a login page once they need to access a resource that requires authentication.
- Requires the application to be directly web browser facing. There is no provision (yet) for passing authentication tokens to back-end services (cf. Shibboleth 2).
The WebAuth model grants privilidges based on the possession of a valid ticket. This means that there are strict policy constraints on test accounts.
5. Levels of authorization control
In deploying federated authorization for the SakaiVRE demonstrator, there are several levels of authorization control that we might consider:
Level 0: authenticated use only. Any access to the VRE requires the user to be authenticated, and once authenticated a user has access to all facilities. This is easily achieved without any changes to the VRE software by deploying Shibboleth authentication in an Apache httpd front-end, across all URIs that are served by the VRE. This would probably require a secondary login to activate the personalization features of the VRE, which is not what we want to see.
Level 1: restricted anonymous access permitted. Some VRE features may be accessed anonymously, but a properly authenticated login will be required to gain access to all features. This would be achieved by using Shibboleth to control access to the VRE login page, and by adapting Sakai to use identity information provided by Shibboleth as a basis for personalization. (This does not of itself address how personalization details are shared across the VRE federation.) This would require that the Sakai login is modified to use information from the Shibboleth-mediated authentication to replace information currently gathered by an interactive login.
Level 2: per-feature access control. Some VRE features may be accessed anonymously, and access to VRE features would depend on attributes obtained from Shibboleth, thus allowing different levels of access to different users or groups of users.
Level 3: user-controlled access. This extends level 2 access by allowing the creators of resources within the VRE environment to determine which other users or groups of users are permitted to access those resources.
In the first instance, we propose to deploy Sakai with level 1 access control, since the higher levels would usefully use features that are expected to be available in Shibboleth 2.0 or 2.1, and also seem likely to require more invasive changes to the portal software itself. (The latest word I hear is that work on such facilities may start in early 2007.)
6. References
