Project index


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.


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.

  1. 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)
  2. 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.

  3. The user is redirected to the WebAuth login page, with username and password entry boxes for the local WebAuth system.

  4. The username and password are checked using the Kerberos standard (RFC 4120)
  5. 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) .

  6. If successful, WebAuth pass a success status and username back to the mod_auth. If unsuccessful the user never gets redirected back.

  7. mod_auth detects the presence of WebAuth cookies, checks their validity and forwards passes the request to the IdP, along with the username.

  8. (deleted)
  9. The IdP maps the WebAuth into a Shibbeloth name identifier (suitable for federation) and returns it to the SP.

  10. The SP then asks the IdP for attributes for the name identifier
  11. The IdP maps the name identifier back to the local username and gets attributes from LDAP
  12. Which returns institution attributes
  13. The IdP can also ask a local attribute store
  14. Which returns Shibboleth-specific properties
  15. The IdP returns these to the attributes to the SP
  16. 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.

  17. SAKAI passes the name identifier the component portlets, none of which need be aware of how it was derived or any authorisation aspects.
  18. The portlets return their content, personalised for the name identifier
  19. The SAKAI compiles the portal from the portlet results and passes the results back through the SP or maybe goes back directly?

  20. The SP passes the results back to the user.

3.1. Diagram TODO

4. Limitations of this approach

5. Levels of authorization control


In deploying federated authorization for the SakaiVRE demonstrator, there are several levels of authorization control that we might consider:

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

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.