Integrating Sakai and Shibboleth
Overview and conclusions
Graham Klyne, Research Technologies Service, Oxford University Computing Services
Working copy - I anticipate that the final version of this document will be published at a non-editable location on the Web
This document provides an overview of and conclusions from work undertaken by Research Technologies Service, Oxford University Computing Services, as part of the multi-centre JISC-funded project to deploy a Virtual Research Environment (VRE) demonstrator based on the Sakai collaborative software platform (1).
At the time of writing (September 2006), the project is not yet complete, so this is a snapshot of progress to date, and a speculative look to the remaining project activity, rather than a definitive statement of final outcomes.
- Executive summary
- Project activity organization and recording
Sakai/Shibboleth integration activity
- What we achieved
- What we still plan to do
- Goals we feel are not yet achievable
- Conclusions and other thoughts
1. Executive summary
A Virtual Research Environment (VRE) is considered here to be a software system designed to support academic staff in the conduct of research activities.
The primary goal of the project activity reported here has been to explore the use of Shibboleth federated authentication with Sakai used as a VRE, and in particular the extent to which portal single-sign-on credentials can be used when accessing back-end services via portlets.
Sakai and Shibboleth are mature software systems with active user and developer communities. Both are still being actively developed. Both are complex systems that require considerable effort and expertise to install and deploy.
Some basic levels of integration between Sakai and Shibboleth are quite easily achieved, but deeper integration (such as using Shibboleth attributes to provide fine-grained access control of Sakai hosted resources) still requires some further work; notably:
- The authorization model exposed through Sakai's documented provider interfaces does not match that provided by Shibboleth. But there are some undocumented interfaces in Sakai that appear to offer the necessary hooks for using Shibboleth-provided credentials, but we have not yet been able to explore these in any detail.
- WSRP, the mechanism proposed for passing Shibboleth credentials to portlets, is not ready for serious deployment. WSRP4J, the WSRP reference implementation, is currently very flaky and its development project appears to be moribund. Sakai does not currently have the WSRP consumer support that would be required to access portlets using WSRP.
Alternative integration strategies for Sakai with Shibboleth deployment might simplify deployment. An example of such an alternative approach is Guanxi, which gathers the relatively complex Shibboleth logic into free-standing components that could, in principle, be implemented as third-party service. The remaining site-specific configuration would then focus mainly on the selection of Sakai tools and worksites, and visual styling of the portal.
Conceived as an institutional portal, Sakai is likely to require extensive customization effort for any deployment. One can question whether this approach is generally viable for VREs, which in many cases may be focused on support for a specific research project with a limited lifetime. There may be some value in determining whether one of a few common Sakai configurations could be created to satisfy common requirements of a range of individual research projects, possibly coupled with virtualization techniques to further simplify deployment. For such systems, the value of Shibboleth integration is less obvious, and easier Shibboleth deployment approaches like Guanxi may be particularly appropriate.
There is a concern that Shibboleth may be viewed as a complete security solution. It is not. Shibboleth does not add security; rather, it provides mechanisms for more flexible deployment of existing sound security practices. There is a particular Achilles' heel: Shibboleth in its current form is highly dependent on browser redirects, which potentially leave the overall system exposed to credential harvesting ("phishing") attacks by misdirecting the browser when collecting user credentials. This is not specifically a Shibboleth problem, but it is a tricky problem needing some particular attention when deploying Shibboleth-based authentication.
At the time of writing, the use of Shibboleth in an "N-tier" authentication framework remains problematic. This is a particular problem for using user credentials for accessing remote portlets. Current solutions require serious compromising of the Shibboleth trust model. Version 2 or 2.1 of Shibboleth is claimed to provide a solution, based on the Liberty Alliance Identity Web Services Framework (ID-WSF), but supporting software is not expected to be available until some time in 2007. Other projects, notably related to grid services, are using approaches based on X.509 certificates that do not depend on direct web-based interaction with a user for gathering credentials.
Finally, a question is raised concerning the suitability of a portal environment (like Sakai) as a virtual research environment. The Web has been a powerful tool for conducting research activity because, beyond some simple technical requirements, it does not impose constraints on access to information. Portals tend to provide access to only those facilities that have been specifically adapted for such use. In evolving portal systems for use as VREs, I argue that greater attention should be paid to interaction with the web at large. Portals should make it easier to draw arbitrary web-based content into the information space of a particular research project (with zero programming effort), and also make it easy to export documents and data to the web at large. Easy interworking with ad-hoc data analysis programs or stand-alone data handling tools (Excel is widely used) would be most valuable in support of some research activities. Lessons might be learned here from the popularity of wiki web systems with researchers; I speculate that the ease of use, adaptability to evolving work patterns, and the ease with which they relate to other web-based resources are all important factors.
2. Project activity organization and recording
Since about March 2006, information generated by the Oxford elements of the Sakai VRE Demonstrator project has been recorded in the OSS-Watch wiki at (4), including project planning and progress notes (5), (this being a project to demonstrate open-source software systems). There is also page of links to related documents and web pages (6).
The present document is a synthesis of details that were recorded in the OSS-Watch wiki at the time of conducting the work, and aims to provide an overview of that information.
3. Sakai/Shibboleth integration activity
Referring to the original project plan goals (summarized at (7)), we determined a number of subsidiary activities (8) that would form the basis of our work to add federated authentication and access control to a Sakai-based VRE. The salient goals are summarized here:
- Install Shibboleth, and document the requirements and procedure to create a basic demonstration installation
- Install Sakai, and document the requirements and procedure to create a basic demonstration installation
- Shibboleth-enable the Sakai portal (as opposed to the portlets - see below)
- Integration of Shibboleth attribute based access control into the Sakai framework
- Document technical and architectural issues with Shibboleth-enabling Sakai VREs
- Roll-out of multi-site Sakai+Shibboleth demonstration:
- Analysis of infrastructure needed to roll out a Shibboleth federation across partner sites
- Implementation of Shibboleth federation across partner sites
- Shibboleth-enabled portlets (based on SPIE project work)
- Transfer of Shibboleth authentications via WSRP/JSR-168 to Shibboleth-aware portlet (as of release 2.1, Sakai does not contain in-built JSR-168/WSRP support)
- Expose Shibboleth properties via portlet session properties
- Grid integration of Shibboleth-enabled Sakai environments
- Evaluation of tools
- Implement suitable tools within Sakai
- Integrate PERMIS authorization and access control tools with Shibboleth-enabled Sakai deployment
- Evaluate PERMIS management tools
- Implement suitable PERMIS management tools within Sakai demonstrator
3.2. What we achieved
3.2.1. Create and document a Shibboleth installation
We have installed and tested a Shibboleth Identity Provider (IdP), Attribute Authority (AA) and Service Provider (SP) module on a host running Scientific Linux (a clone of Redhat Enterprise Linux). The steps we took to create this installation are documented in the project wiki (13).
At the time of writing this (October 2006), we are in the process of transferring this installation to a host running Debian Linux; unfortunately, there seem to be some problems installing Shibboleth on this platform, and this task is stalled, due in part to problems with our Shibboleth and Sakai hosting environment. There are some notes about the problems we have encountered (13).
Here is a diagram of Shibboleth deployment (using WebAuth):
Diagram by Stuart Yeates
3.2.2. Create and document a Sakai installation
We have installed and tested a basic out-of-the-box Sakai installation (but have not yet tested any of the supplied tools). The steps we took to create this installation are documented in the project wiki (16).
Customization of this installation with a specific set of tools is a separate phase of this project.
3.2.3. Shibboleth-enable a Sakai installation
We have achieved basic Shibboleth-enabling of the installed Sakai portal. For more details, see section "Using Shibboleth with Sakai", later in this document.
3.2.4. Document issues for Shibboleth-enabling Sakai
We have made various notes concerning issues for using Shibboleth with Sakai, which are somewhat spread about in the wiki. The salient concerns are drawn together in the section "Using Shibboleth with Sakai", later in this document.
3.3. What we still plan to do
3.3.1. Multi-site Sakai/Shibboleth integration
The key demonstrable goal here for a user to access a Sakai system operated by one of the project partner institutes using credentials managed by another. Specifically, we aim to allow cross-authentication between the Oxford-based Sakai system and that run by CCLRC, Daresbury, since these sites both have established Shibboleth deployments that are or can be joined to a common federation (SDSS (9)).
At the time of writing this (October 2006), we have not completed this cross-site authentication, due in part to problems with our Shibboleth and Sakai hosting environment. But we have had enough individual pieces working that do believe that all the substantial technical problems have been identified and resolved. Of course, the final proof of the pudding is in the eating, so we hope to have a more comprehensive report soon.
In terms infrastructure, what is required at each site is:
- A running Sakai system (of course).
A means of authenticating web-based access requests from members of the host institution (e.g., at Oxford we use Stanford WebAuth (11), which is a web front-end to Kerberos. JA-SIG Central Authentication Service (Yale CAS) (12) appears top be another common choice).
- A Shibboleth Identity Provider (IdP) and Attribute Authority (AA) system that can serve values from a local user database as Shibboleth attributes (e.g. we are using an Oxford LDAP server to provide Shibboleth attribute values).
- A Shibboleth Service Provider (SP) module that intercepts selected requests to the Sakai portal (specifically, login requests) and obtains authentication and attribute information via the Shibboleth IdP/AA components.
We have created some notes about partner site environments in preparation for Shibboleth-based cross-site authentication (10). We have prepared more detailed notes for installing Shibboleth in our environment (13), and a diagram that attempts to highlight interactions between the various software component configuration data (14)
3.4. Goals we feel are not yet achievable
At the time of writing (October 2006), the Sakai VRE demonstrator project is not yet complete, so this section represents a speculative look to the remaining project activity, rather than a definitive statement of final outcomes.
3.4.1. Shibboleth attribute based access control in Sakai
We had originally planned to use Shibboleth attributes as a basis for making access control decisions in Sakai, thus providing a basic access control capability based on institutional status or attributes. This has turned out to be not easy with currently available software, due to a mismatch between the information access model assumed by Sakai and that provided by Shibboleth. See section "Using Shibboleth with Sakai", later in this document, for more information.
One near-term possibility that might achieve this capability is Guanxi (41), a project that is developing a pure Java implementation of Shibboleth. This project is also developing an "attribute pod management module" (my description, not theirs) that will capture Shibboleth attributes and subsequently make them available to Sakai access control queries. This is a somewhat awkward solution, but probably as good as can be achieved given the mismatch between Sakai and Shibboleth.
Since the work reported here, we have learned a little more about Sakai authorization mechanisms which might make it easier to integrate with Shibboleth - see below, section "Other possibilities for using Shibboleth attributes".
3.4.2. Shibboleth-enabled portlets
The plan for Shibboleth-enabling of portlets (that is, providing information to Sakai portlets (or tools) to make access control decisions on the basis of Shibboleth attributes) was predicated on a number of developments:
- Use of JSR-168 interface for portlets in Sakai
- Use of WSRP to transfer Shibboleth authentication details and attributes to remote portlets
- Exposing Shibboleth properties via portlet session properties
All of these are problematic, or are at least not readily available within the time frame of this project.
- Sakai's native interface to portlets (or "tools", as Sakai calls them) is based on Spring and a "Tool Portability Profile". Sakai tools subsume JSR-168 portlet functionality, but may also provide controller and model functionality as well as a presentation layer interface.
Some work to JSR-enable Sakai has been conducted, but not as part of the main Sakai project. While there is work in progress for Sakai as a JSR-168 producer (see next point), we do not have detailed knowledge of developments to allow Sakai as a JSR-168 consumer. Apparently, as of July 2006, CCLRC Daresbury have an "alpha quality" consumer based on WSRP (cf. http://www.nesc.ac.uk/talks/686/10-15_2006_06_17_severance_portlet_wkshop.ppt, slide 5) (17), but our earlier experiences with WSRP underscore that "alpha" software is not an effective basis for a public demonstrator.
The Sakai project has conducted some work that allows Sakai to be run as a JSR-168 portlet (that is, Sakai as a producer), but at the time of writing this (September 2006), this is is in need of updating (cf. http://bugs.sakaiproject.org/jira/browse/SAK-6115).
Prior to starting work on the Shibboleth authentication phase of this project, we spent some time trying to install and test WSRP software, specifically the Apache implementation WSRP4J (18). We have found this software to be very fragile, and the WSRP4J project appears to be moribund (judging by its mailing list traffic and JIRA bug tracking database status). In particular, the software seemed to be excruciatingly sensitive to versions of related software with which it is used. The last time we tried, the WSRP4J software would not build and run in a project-defined configuration without considerable adjustment to the configuration files. We feel, therefore, that WSRP4J currently far too fragile for deployment in a public demonstrator.
Despite this, there have been some developments that use WSRP with Sakai. At the time of writing, we have not had time to explore these alternative code bases. We understand that CCLRC Daresbury Laboratory has some WSRP code running in Sakai, but even they say that "WSRP implementation is still at an early stage, further development is clearly needed" (cf. http://epubs.cclrc.ac.uk/bitstream/1083/talk06A.pdf, slide 15, January 2006).
- We have found that exposing Shibboleth properties to Sakai is problematic, due to different models for provision of authentication information. This is discussed further in the sections "Other possibilities for using Shibboleth attributes" and "Using Shibboleth with Sakai", below.
3.4.3. Grid integration of Shibboleth-enabled Sakai environments
Grid integration of Shibboleth-enabled Sakai environments depends on (a) having a suitable mechanism for linking Grid services into Sakai as portlets or Sakai tools, (b) being able to pass detailed Shibboleth information to back-end grid service providers, and (c) having the grid service providers able to use the provided credentials to access resources and perform actions on behalf of the requesting user.
Of these, (a) is itself dependent on "Shibboleth-enabled portlets", which is discussed above; (b) depends on passing Shibboleth information to Sakai, discussed below in section "Using Shibboleth with Sakai"; and (c) depends on a solution to the so-called "N-tier authentication problem" for Shibboleth, which is discussed later in section "Grid integration and "N-tier" authentication".
The upshot here is that we have not uncovered solutions for any of these problems appropriate for deployment in a public demonstrator in the available time frame.
3.4.4. Integrate PERMIS with Shibboleth-enabled Sakai
An evaluation of the PERMIS tool set would be a useful exercise, but one which we have been unable to conduct to date for lack of time. It may be that this can be addressed in the time remaining to this project. Such an assessment should pay particular information to mechanisms for conveying Shibboleth-derived information to PERMIS, and subsequent conveyance of authorization decisions to Sakai.
Some evaluation of PERMIS has been conducted as part of the related SPIE project (20), a proposed approach that depends somewhat on using the JAAS authentication and authorization interface within the context of an HTTP request. Deployment of PERMIS with Shibboleth-enabled Sakai is clearly dependent on having a suitable Shibboleth-enabled deployment of Sakai. The problems of accessing HTTP request context information are discussed later in section "Using Shibboleth with Sakai".
We have studied the Sakai system (1), its architecture and have created an "out of the box" Sakai deployment. Our findings and experiences from this are described in some detail in the project wiki (16).
Sakai is not a portal container in the same sense as JSR-168 portals like uPortal, in two key respects:
The relationship between Sakai and its tools (the Sakai analogue of portlets) is not focused entirely on composition of presentation, but also allows for interactions that take place below the presentation layer 1.
The interface between Sakai and its tools is not a single fixed API, but a loose collection if mostly independent tool APIs that are collectively known as the "Tool Portability Profile", or TPP. The various components are knitted together with a design pattern "dependency injection", implemented by the Spring framework (22)
1 Some correspondents have challenged me that JSR-168 is not entirely about composition of presentation. I beg to disagree, citing as my authority the specification itself (21). In section PLT.2.2, it says:
- A portlet is a Java technology based web component, managed by a portlet container, that processes requests and generates dynamic content. Portlets are used by portals as pluggable user interface components that provide a presentation layer to Information Systems.
- The content generated by a portlet is also called a fragment. A fragment is a piece of markup (e.g. HTML, XHTML, WML) adhering to certain rules and can be aggregated with other fragments to form a complete document.
- Other parts of the JSR 168 specification reinforce this view.
Sakai has its roots, and its main user base, as a Virtual Learning Environment (VLE) with an institutional focus. As such, its design is optimized to providing a number of worksites (roughly, corresponding to courses), which are primarily controlled by a small number of instructors and used by a larger number of students. It also has a strong emphasis on providing visual branding for a collection of tools in a common containing environment, for which it makes extensive use of JavaServer Faces Technology (23) and Cascading Style Sheets (CSS) (24).
A Sakai deployment can implement a number of "worksites", which in a learning environment would correspond roughly to an online course. For a given user, access rights to each worksite are determined independently (e.g. an instructor on one course might be a student on another).
4.1. Sakai authorization and access control
Sakai's access control model is oriented towards using membership in relation to a particular course or worksite. As a learning environment, Sakai expects to track the progress of each student, so there is a general presumption that Sakai will maintain a list of users (e.g. instructors and students) for each worksite. Access control decisions can be made by user-supplied modules called providers. There are 3 main kinds of provider:
/user/user-api/api/src/java/org/sakaiproject /user/api/UserDirectoryProvider.java - returns information about an identified user or users. Sakai extracts the current user from any incoming request and subsequently queries the provider with an explicit user id (eid), without any direct reference to a context with information about the current user. The primary purpose of this module is to link to externally determined authentication, but it can also be used to obtain externally stored attributes about a user (via its "directory" related functionality).
/authz/authz-api/api/src/java/org/sakaiproject /authz/api/GroupProvider.java - returns information about the roles that a designated user has in a designated group (or worksite). A "group" is sometimes referred to as a "realm".
/authz/authz-api/api/src/java/org/sakaiproject /authz/api/AuthzGroupService.java - service used at login (and other times?) to set up information for access control decisions.
More information about what we have learned about Sakai authorization is in the wiki (40), though since that page was written we have discovered a little more about Sakai user management and access control, which is described below in section "Other possibilities for using Shibboleth attributes".
4.2. Other possibilities for using Shibboleth attributes
Talking to some developers more familiar with Sakai (particularly Ian Boston from CARET - http://www.caret.cam.ac.uk/), it appears there are some Sakai interfaces that don't appear in the high level documentation, which can be used to overcome the problems of allowing Sakai to use Shibboleth attributes.
/tool/tool-api/api/src/java/org/sakaiproject /tool/api/SessionManager.java - Can be used to obtain a reference to the current session. Used in conjunction with the SPIE JAAS module (36) (37) this could be used by a Sakai UserDirectoryProvider and/or RealmProvider to access information from Shibboleth attributes lodged in the current servlet session and make them available to Sakai provider modules. For this to work, an appropriate module must be injected into the request handling path (see RequestFilter below) to capture relevant information from the incoming request into a Sakai session context value.
/tool/tool-util/servlet/src/java/org/sakaiproject /util/RequestFilter.java - Sakai allows incoming requests to be filtered, hence for information to be extracted that can be used later in the request processing. RequestFilter filters all requests to Sakai tools. It is responsible for keeping the Sakai session, by storing a cookie containing the user's session ID on the end user's browser.
/util/util-api/api/src/java/org/sakaiproject /thread_local/api/ThreadLocalManager.java - Provides registration and discovery of objects bound to the "current" request processing or thread. Clients who have objects to bind can set/get them at will - the Sakai Framework assures that the entire set of objects bound to current are cleared when the request processing is complete. For example, this is used by the Sakai RequestFilter mechanism. Unlike the standard Java thread-local manager, the Sakai version cleans up resources when a request is complete.
The appropriate RequestFilter, and maybe other intercept code, is injected into the Sakai request handling using the tool's web.xml file. For example, here is an extract from the web.xml file for the rwiki tool:
The Sakai Request Handler --> <filter>
<!-- Mapped onto the RWiki Handler --> <filter-mapping>
<filter-name>sakai.request</filter-name> <servlet-name>sakai.rwiki</servlet-name> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher>
Using these capabilities depends, to a lesser or greater extent, on creating some new code that interacts quite closely with Sakai at a number of points. Availability of the interfaces concerned is not obvious from reading the Sakai documentation. As such, any of these approaches would require software development with some degree of familiarity with Sakai's internal structure.
Shibboleth (2) is a tool set for deploying a system of federated authentication; i.e. to allow access to a network resource provided by one administrative domain using credentials supplied by another (trusted) domain. Shibboleth does not itself provide the authentication mechanisms -- each domain must choose and provide its own system for that -- but it does provide the mechanisms that allow the access control decisions to be based on remotely-derived user authentication. Shibboleth is based largely on the OASIS Security Assertion Markup Language (SAML) (25).
In its current incarnation, Shibboleth is designed to be used in controlling access to resources accessed using a Web browser, and its version 1.3 implementation is heavily dependent on certain interactive Web browser capabilities (page redirection, interactive entry of authentication tokens). Further, the nature and current use of SAML (version 2.0) assertions is such that only the party to whom an assertion is issued is able to use that assertion to gain access to a resource. Taken together, these facts mean that back-end services (such as grid services) cannot be part of an end-to-end security solution based on Shibboleth; this limitation can affect portal software, as portlets connected via WSRP or some other network connection effectively become back-end services. This topic is discussed further below.
Shibboleth software components are neatly summarized in Shibboleth & WSRP by Jasper Tredgold and Nikki Rogers (29), thus:
- Identity Provider (IdP)
- The IdP is typically provided by the institution to which the member belongs. This component has the responsibility of issuing authentication assertions about its registered users, effectively handing out tokens, once the user is authenticated, confirming that the user is who they say they are in the context of that particular institution.
- Service Provider (SP)
- An SP is a resource or service that users require authorisation to use. When visited it will ask a user to prove their identity by way of their IdP, redirecting their browser to that IdP (perhaps via an intermediary service know as a WAYF) if necessary. When a user can present a authentication token to the SP, from an IdP that the SP trusts, the SP can then query the user’s attributes to determine their entitlement to use that service. For this, the SP talks to the user’s Attribute Authority.
- Attribute Authority (AA)
- The AA is part of the IdP and manages the release of attributes specific to the IdP’s registered users. These attributes, released in response to the presentation of a user handle from a trusted SP, will allow a remote SP to make decisions about the access rights of that particular user.
A federation allows the trust relationships to be managed between a group of IdPs and SPs. These IdPs and SPs, rather than each entering into a bipolar trust relationship with each other, instead each join in a single federation, which provides assurances about the integrity of its members. Once in a federation the IdP or SP both trusts and is trusted by all other members of that federation.
More notes about Shibboleth are contained in the our wiki (26).
5.1. Federated authentication and access control
When considering the use of federated authentication, such as provided by Shibboleth, we need to distinguish between authentication and access control:
- Authentication is a process of determining that a party making a request has a recognized identity or other attribute. In its simplest form, it is a confirmation of a personal identity, but in some circumstances it may be confirmation that the requesting part is a member of some recognized group (e.g. students at Oxford University). Authentication is generally performed under the auspices of an administrative domain with which the requesting party has a direct personal connection.
- Authorization is a process of determining whether or not a party making a request is to be granted access to some resource or facility. Authorization is generally performed under the auspices of an administrative domain that controls the resource being accessed (e.g. the administrative body that maintains a supercomputing facility).
The role of Shibboleth in this environment is to convey an irrefutable assertion of authenticity (of identity, group membership, and/or other attributes) of a requesting party from an authenticating domain to an authorizing domain (i.e. whose resource is being accessed). This presumes that there is some kind of trust relationship between the authenticating domain and the authorizing domain. For Shibboleth, this trust relationship is crystalized as membership of a Shibboleth federation, in which members may choose trust authentication assertions made by other members of the federation, supported by trusted X.509 certificates. For each federation, there is also a membership administration, who is trusted to accept new members only if they satisfy some defined criteria, and to distribute relevant information about each member in the form of federation metadata.
(At the time or writing, the extent to which the federation membership administrator must be trusted is not clear. On one hand, each member is ultimately authenticated by their certifying authority, which all members can verify, so there is no question of falsely claimed authentication of a federation member. On the other hand, it is not obvious that there is any solid protection against distributing doctored federation metadata that includes members who have not satisfied criteria for federation membership, but who do have a certificate issued by a CA acceptable to the federation.)
Sometimes, particularly when using Shibboleth, the roles of authentication and authorization can become blurred, as the decision to permit access to a resource can be directly related to possession of particular Shibboleth attribute. Thus, it may appear that the authenticating domain's assertion of an attribute is tantamount to authority to access a resource. In such a scenario, it is important to recognize that it is the resource provider that determines access control, and may choose to recognize certain Shibboleth attributes for this purpose. In more complex deployments, access control policy decisions may be distributed between the IdP and SP components, but ultimate policy enforcement must be performed by the SP component or by the resource provider itself.
5.2. Levels of authorization control
In considering how Shibboleth information can be used by a application environment, such as Sakai, we have identified 4 possible levels of authorization control (27):
Level 0: authenticated use only. Any access to the application 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 application software by deploying Shibboleth authentication in an Apache httpd front-end, across all URIs that are served by the application. This would probably require a secondary login to activate any personalization features of the application.
Level 1: restricted anonymous access permitted. Some application 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 application login page, and by adapting the application to use identity information provided by Shibboleth as a basis for personalization. (This does not of itself address how personalization details are passed within the application.)
Level 2: per-feature access control. Some application features may be accessed anonymously, and access to application 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 application environment to determine which other users or groups of users are permitted to access those resources.
In the first instance, we have focused on deploying 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 application software itself.
5.3. Grid integration and "N-tier" authentication
As noted previously, current Shibboleth software can be used to provide authentication information only to applications that directly use a web browser interface, and does not directly support use for controlling access control in back-end services such as grid services and applications accessed via portlets. It is possible to implement systems that use Shibboleth-mediated information to drive access control decisions for such applications, but these require that Shibboleth's trust model be extended, and hence create possibilities for unexpected security failures. That said, if deployed carefully and properly reviewed, these approaches might well provide acceptably secure solutions. Examples of such developments are:
The SPIE project (28) has created Shibboleth and WSRP demonstrator software (29) that extends the Shibboleth service provider trust boundary to include services invoked in a uPortal (30) environment. A module in the portal requests Shibboleth attributes using the provided credentials, and passes them via WSRP (as portlet attributes) to the actual services. For locally deployed services within the same administrative control, and with adequately secured communications between the portal and portlets, this may be acceptable. But for services deployed in different administrative domains, this could lead to uncontrolled leakage of confidential attribute information. The authors themselves acknowledge this: "... although this technically provides the desired functionality, it does so in a non-scalable way, requiring the management of trust between each service and each of its client applications" (29).
The ShibGrid project (31) uses MyProxy (32) supplied Shibboleth credentials as authority to issue X.509 certificates that can be used to access grid services. In this environment, the Shibboleth SP trust domain is extend to include the MyProxy server (in that signed attribute assertions obtained from Shibboleth are handed over to it), and the MyProxy server can then serve as a "gateway" between the Shibboleth trust environment applied to browser-facing programs, and the grid environment in which trust is conveyed using X.509 certificates. In this environment, the MyProxy server represents a potential point of vulnerability, but one that can probably be well managed to minimize any risk of compromised security. (A pioneer of Internet protocol development once observed to me, not entirely cynically, that the function of a gateway is to lose information.)
Looking beyond these uses of hybrid trust models, future developments of Shibboleth, backed up by some minor re-drafting of the SAML specification, are expected to extend the scope of Shibboleth to handle N-tier authentication. Essentially, a security assertion will be permitted to specify subject verification mechanisms that allow a primary service provider (e.g. a portal) to allow a separate service (e.g. the producer in a portlet) to act as its agent for designated purposes. The authority to access Shibboleth resources remains that granted to the specified Service Provider, but that authority may be selectively exercised 2 by some other software system. It is anticipated that Shibboleth software releases may be available in 2007 that support this extended functionality, hence allow N-tier authentication within a common Shibboleth trust model. Such a development will be particularly apposite for portals and portlets, since portlets are web-browser-facing components in all but the detail that their interactions are mediated by a portal.
2 This issue of exercising rather than delegating an authority seems to be important, though it is not entirely clear to me why. In a private email, Scott Cantor was quite emphatic that a previously used term, "constrained delegation", was not appropriate for the proposed mechanism. In human endeavours, when one acts as an agent for another, the agent is not responsible for the performance of the one for whom he acts, and is not generally authorized to designate another party to perform his duties. It may be that, in this case, a similar distinction is intended: an entity other than the original service provider designated to perform some service does not have authority to sub-designate performance to any other entity.
5.4. Alternative deployment patterns
The deployment pattern for Internet2 Shibboleth Service Providers (SP) assumes an SP module for each application (or application server) that is serving protected pages. This means that the security afforded by Shibboleth is extended all the way to the application server in question, a widely approved pattern for security deployment. A Shibboleth SP module is a moderately complex piece of software, and (in its current incarnation) depends on having an Apache HTTPD server to front-end a Java servlet based application. The procedure for setting up a Shibboleth SP is non-trivial, and can be sensitive to details of software versions.
At least one other deployment pattern is possible, in which a Shibboleth SP module may be shared between a number of servers, and a simpler enforcement layer deployed on the servers themselves, and a secured channel based on a bi-lateral trust relationship between the server and the Shibboleth SP system. This is essentially the deployment pattern used by Guanxi (41). Although this has the disadvantage of requiring an additional trust relationship, it has the potential advantage of much easier deployment.
Guanxi includes a Shibboleth SP solution for pure java applications, uses a simple "guard" module (written in Java) that sends requests over a secure channel to a separate SP module. In this way, a single Shibboleth SP module (with a single federation subscription) can serve several application servers. This may be particularly useful when applications are being operated by groups that lack the skills or effort to run a full Shibboleth deployment.
Although this alternative deployment is arguably less secure than a full Shibboleth SP deployment, making it easier to deploy may actually result in greater overall security (34).
This topic is explored at slightly greater length in the wiki (35).
This section summarizes our experiences with Sakai and Shibboleth, and links to more detailed noted from our project meetings for this phase of the work.
As of version 2.1, the software appears to be stable and well-supported, though it's performance is sometimes less than sparkling, and the documentation seems to be a bit patchy. We initially experienced problems installing an earlier version (1.x) of Sakai, but these were all resolved when we moved to version 2.1.
See: http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060424 section 3.1, http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060508 and http://wiki.oss-watch.ac.uk/SakaiNotes#installation (16).
We have worked throughout with Shibboleth version 1.3, with WebAuth (11) being the primary authentication mechanism. Integration of the Shibboleth IdP with WebAuth was quickly achieved http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060605, http://wiki.oss-watch.ac.uk/SakaiVre/ShibbolethWebAuthIntegration (38).
We had continuing problems with Shibboleth IdP installation, and went back to a virgin Tomcat installation. Further problems encountered related to getting all configuration files and security tokens in the right places, and Tomcat security configuration all correct, but in the end an apparently working IdP installation was achieved. The SP module was successfully installed, but this too proved more difficult than the installation notes would suggest, mainly in getting the configuration right. We discovered that a problem with getting an attribute assertion issued was due to earlier problems configuring port 8443 access, compounded by SELinux enforcement of prohibition of port listening by Apache server. With the Apache server permitted to listen on port 8443, we progressed with configuration of LDAP attribute authority and have this working. We succeeded in getting attributes released from one of the University LDAP servers into the Shibboleth SAML assertion, by editing the LDAP-to-shibboleth mapping file, attribute release policy and attribute acceptance policy configurations. http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060619.
Later, when we attempted to move the installation to a machine running Debian Linux (39), we ran into a range of problems which, at the time of writing, are not fully resolved. But we don't expect any insurmountable obstacles to deployment on Debian Linux. There appear to be some problems getting the Shibboleth SP module to install on Debian, but we expect these to be surmountable, eventually. See http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060823, http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress/20060918 for more details.
Thus, it seems that Shibboleth is quite complex and moderately difficult to install and get running for users or administrators who are not familiar with it.
6.3. Using Shibboleth with Sakai
In considering how Shibboleth information can be used by Sakai, with reference to the "Levels of Access Control" section above and (27), we find that "Level 0" and "Level 1" are easily achieved without any special modifications for Sakai. Level 0 depends simply on request filtering by Apache, and level 1 requires only that Sakai can receive and use a "REMOTE_USER" identity from the HTTP request servicing code. It is necessary (or at least highly desirable) to ensure that Sakai is configured to save its user configuration in a persistent store (otherwise user information is lost when Sakai is shut down).
Levels 2 and 3, however, are not possible using Sakai out of the box. New code is required to field Shibboleth attributes from incoming Web service requests, and then to use that information when Sakai calls a UserDirectoryProvider or GroupProvider instance, which requires some depth of understanding of the Sakai code, and an uncertain amount of development effort. At the time of writing, the best possibility seems to be to use a combination of RequestFilter and SessionManager to make Shibboleth attributes available to provider code.
6.3.1. Cross-linking between Sakai sites
There is an additional use-case that was raised late in the project that we have not yet considered: cross-linking between Sakai sites in a federated authentication framework. What follows is a cursory description and analysis of this use-case, and should not be considered definitive.
Suppose a user is authenticated by a federation member, and has accessed a Sakai site within the federation. That site may contain a link to another Sakai site operated by another federation member. Ideally, the authenticated user should be able to follow that link without further authentication.
The current strategy for "level 1" and "Level 2" authentication assumes that Shibboleth authentication assertions are processed when accessing the Sakai login page, and used to populate a local Sakai user list. Whether or not this strategy works for the cross-link use case depends rather on how Sakai responds to HTTP requests for pages that require a Sakai login in order to be accessed. In normal use, a Sakai system seems to restrict the options displayed by the portal to those that the current user is authorized to access. From this, it is not clear how Sakai handles attempts at "deep linking", accessing a resource by specifying its URI directly. There are two likely responses:
- Return an HTTP "401 Unauthorized" response
- Redirect the request to the Sakai login page, to fulfil the original request if and when a successful login is completed.
In the first case, the cross-linking will not work as desired.
In the second case, the login page access should be intercepted by Shibboleth, and an appropriate local user entry created in the target Sakai site, so the request might be expected to complete as desired.
This topic requires some further investigation to understand how Sakai deals with such requests.
7. Conclusions and other thoughts
7.1. Sakai system
As of version 2, Sakai appears to be a mature software system that installs easily straight from its source distribution. It is, however, very resource intensive and, in particular, startup can take a long time. (Resource usage and startup time can be trimmed somewhat by being selective about what tools are installed - by default, most available tools appear to be installed.)
Sakai has its own built-in authentication and access control mechanisms, but also has some capability to link to external authentication systems. It also uses a provider framework that, in principle, allows any external authentication and access control mechanism to be used.
We have not spent a lot of time actually using our Sakai installation, so have little to say about its functionality and utility at this stage.
Shibboleth appears to be a well-considered approach to a particular requirement for single sign-on across multiple institutions, which tries to be as non-invasive as possible with regard to applications to which access may be controlled. Only so much can be achieved without having some cooperation from the application itself: a web page or set of web pages may be served or may be refused. More than this requires some level of awareness and cooperation from the controlled application.
The Internet2 Shibboleth software itself is quite complicated to install, and I doubt whether smaller educational institutions and research groups will have the expertise and available effort to successfully install a secure Shibboleth installation. There are many small details that have to be just right if the installation is to behave as expected.
Complex as it is, Shibboleth can be seen as only part of a federated access control system; also needed are institutional authentication mechanisms, access control decision mechanisms, either at an institutional or federation level, or in individual applications. Each of these adds to the overall management complexity and difficulty of installing and maintaining a running system.
Other approaches to Shibboleth deployment bear some examination. In particular, the Guanxi model allows a single Shibboleth deployment to serve different applications, possibly run by multiple institutions, creating the possibility that the hard part of Shibboleth deployment could be operated as a central service, and used by a number of clients for whom installing and operating Shibboleth might be an over-bearing burden. This is achieved at a cost of extending (and possibly weakening) the Shibboleth trust model, but it is also arguable that despite this the opportunities for compromised security are reduced by not requiring all sites to manage the complexities of Shibboleth deployment.
7.2.1. Other security concerns
One security concern that is not specific to Shibboleth, yet should probably be addressed by any widely deployed web-based single sign-on system, is the problem of "phishing" using spoofed authentication pages. A single sign-on system that allows a user to connect from any browser has a glaring potential weakness: do users check that they are submitting their credentials to the correct authentication server? Can they tell, even if they always try?
It is not hard to create a fake web site that appears to be (say) an institutional WebAuth login screen, which will collect credentials for subsequent nefarious activity.
7.3. Shibboleth-enabling Sakai
We have been able to achieve "Level 1" (27) Shibboleth based access control for Sakai, using basic Shibboleth mechanisms for controlling HTTP access to designated URIs, coupled with Sakai's own internal access control mechanisms.
As noted previously, Sakai can, in principle, use any external authentication and access control mechanism. In its basic form, the provider framework assumes that all relevant information can be accessed directly using just an "external identifier" (EID) that is maintained by Sakai for this purpose. This does not, however, sit comfortably with the Shibboleth approach of providing authentication information in relevant HTTP requests, as Sakai does not provide a documented way to access information from the HTTP request or session contexts. This has, so far, restricted our ability to use Shibboleth attributes to make access control decisions.
The Guanxi developers at UHI are developing a system that overcomes this problem, but (based on discussions to date) in a way that appears to be quite cumbersome, and requires an awkward by-passing of Sakai control flows.
With knowledge of undocumented Sakai internals, it appears that there are mechanisms that can be used by Sakai providers to access incoming request and session context information, so it may be possible to develop software that overcomes these problems, but we have not so far had time to pursue this possibility.
7.4. Software complexity
Both Sakai and Shibboleth are software systems of considerable complexity. To deploy them even individually involves a steep learning curve, and to deploy them together requires also learning about their interactions.
The complexities create problems in several areas:
- Configuration complexity: both Shibboleth and Sakai have several complex configuration files that need to be edited to get a running installation. Shibboleth is particularly hard work in this respect, as the default configuration has to be tuned extensively to match the local environment; also, the configuration files that need to be edited are distributed over several locations. Sakai requires relatively little configuration tuning to get it up and running, but there are very many options, and very extensive configuration changes are likely to be required to create a Sakai installation that meets the requirements of a particular institution.
- Fragility: software complexity leads pretty much inevitably to fragility, particular when integrating different software systems, as small differences between the expected and actual software environment can lead to abject failure of the system. To some extent, Sakai mitigates this by its use of the Spring framework, which helps to loosen the coupling between different software modules though dependency injection and AOP (but this in turn contributes to configuration complexity, as the module interdependencies still need to be captured somewhere). Fragility has been particularly noticeable with Shibboleth; a particular example of this has been the problems we have encountered trying to move our Shibboleth installation from Redhat Linux to a Debian-based system.
- Fault diagnosis: in a complex environment, there are many possible failure modes, and diagnostics (log file and error messages) often fail to indicate precisely where the error lies, since they often describe a secondary problem rather than the root cause.
- Source code extension: if all required functionality can be achieved using out-of-the-box software distributions, then this need not be a concern. When one needs to add additional functionality, especially when clearly documented interface hooks are not available, it is necessary to understand the system source code in some detail, which requires a considerable investment in time and/or training when dealing with complex systems. This problem is exacerbated with modern open source systems, for which available documentation tends to lag the source code base. A consequence of this is that one tends to see a fairly close community of dedicated (and often over-stretched) developers who understand the source code well enough to modify it, and a surrounding community of users who are trying to understand how their particular requirements can be satisfied.
7.5. Portals and VREs
Coming to this project from working with software to support life-science researchers in the Zoology department at Oxford, and also reviewing early requirements from other VRE projects at Oxford (42), I find there are differing views about what is needed for a VRE (considered broadly as a software system designed to support academic staff in the conduct of research activities). In particular, I find it quite clear that there is no general VRE system that will satisfy all researchers' requirements, which I speculate may be different from the circumstances that led to the development of Virtual Learning Environments (VLEs).
Requirements for VREs that have been articulated range from tools to discover research source materials, tools to analyze research observation data, tools to support administration of research activities and tools to facilitate collaboration, among many others. In particular, it seems that for some purposes, lightweight tools are required that will do some specific job and otherwise stay out of the way, while others want tools that work together in an organizing framework that guides the conduct of some research activity.
What, then, is the role of a portal framework in satisfying VRE requirements? Possible drivers for the adoption of portal technology in this role include:
- Researchers; e.g. bioinformatic research information workflow management; grant application writing support; finding and working with collaborators.
- Institutions; e.g. institutional resource access; branding.
- Technology; e.g. Sakai is successful as a VLE, can it be adapted as a VRE?
These thoughts pose a number of open questions and, particularly if one believes that there is no one-size-fits-all VRE solution, ones that cannot be answered without a clearer view of the community who VREs aim to serve. Other VRE projects in Oxford are focused on specific research communities, and it would be most helpful to review their findings with respect to VRE requirements, with a view to understanding which of these are appropriately addressed by portal systems.
A particular concern is that a portal system is a complex beast, and must provide sufficient benefit to its users and other stake holders to justify its cost of deployment. I argue that there is a role for easily-deployed, lightweight web and web-service based tools to address some researchers' needs, and that portal-based solutions would be more widely useful if they can work well with existing web applications as well as those which have been specifically adapted as portlets or tools in in a portal environment.
An approach to mitigate the cost to smaller groups of deploying portal systems might be virtualization. That is, to create a pre-built system, along the lines of a VMware virtual appliance http://www.vmware.com/vmtn/appliances/, that is pre-built with a particular set of functions for a target community. Such an approach would probably work best a Guanxi-like deployment of Shibboleth.
Some material for this document and many useful comments were provided by Stuart Yeates and Christian Fernau of Oxford University Computing Services.
This work has been funded by the JISC Virtual Research Environments programme http://www.jisc.ac.uk/whatwedo/programmes/programme_vre.aspx.
(5) Sakai VRE demonstrator project, Oxford component, planning and progress index page - http://wiki.oss-watch.ac.uk/SakaiVre/PlanningProgress.
(6) Sakai VRE demonstrator project, Oxford component, documents and links - http://wiki.oss-watch.ac.uk/SakaiVre/DocsAndPresentations.
(7) Sakai VRE demonstrator project, Oxford component, summary of original project plan goals - http://wiki.oss-watch.ac.uk/SakaiVre/OriginalProjectPlan.
(10) Shibboleth federation for the Sakai VRE demonstrator - http://wiki.oss-watch.ac.uk/SakaiVre/ShibbolethFederation.
(13) Shibboleth Installation Notes - http://wiki.oss-watch.ac.uk/ShibbolethInstallNotes
(17) Sakai and Portals, Charles Severance, Portals and Portlets Workshop, July 2006 - http://www.nesc.ac.uk/talks/686/10-15_2006_06_17_severance_portlet_wkshop.ppt.
(19) An Approach for Shibboleth and Grid Integration, Francisco Pinto and Christian Fernau, Research Technologies Service, Oxford University - http://spie.oucs.ox.ac.uk/attach/Presentations/PosterProposalAHM2005.pdf.
(20) JAAS Standard-based Shibboleth/PERMIS Integration, Christian Fernau, Francisco Queir´os Pinto, JISC Core Middleware SPIE Project, Research Technologies Service, Oxford University - http://spie.oucs.ox.ac.uk/attach/Presentations/spieDemoAHM2005.pdf.
(25) Security Assertion Markup Language (SAML), at the Security Services Technical Committee of OASIS - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. See in particular the Assertions and Protocols document (informally known as the "core" spec) http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
(27) Shibboleth and WebAuth integration - http://wiki.oss-watch.ac.uk/SakaiVre/ShibbolethWebAuthIntegration. (Contains diagram of Shibboleth deployment and a list of levels of authorization.)
(28) SPIE project home page - http://www.oucs.ox.ac.uk/rts/spie/index.xml.ID=Project%20Information.
(29) Shibboleth & WSRP, Jasper Tredgold, Nikki Rogers, ILRT Bristol, 6 April 2006 - http://spie.oucs.ox.ac.uk/attach/ILRTFinalReport/SPIE39-ShibWSRP.pdf. (See also http://spie.oucs.ox.ac.uk/Wiki.jsp?page=WSRP and http://spie.oucs.ox.ac.uk/Wiki.jsp?page=ILRTFinalReport.)
(31) ShibGrid Project: Integrating NGS into the academic framework - http://www.oesc.ox.ac.uk/activities/projects/index.xml?ID=ShibGrid.
(33) Liberty Alliance ID-WSF 2.0 Draft Release 3 Specifications - http://www.projectliberty.org/liberty/resource_center/specifications/liberty_alliance_id_wsf_2_0_draft_release_3_specifications, also http://tinyurl.com/luk79. Liberty alliance specifications for Identity Web Services Framework for describing security mechanisms for authentication and authorization; see in particular draft-liberty-idwsf-security-mechanisms-saml-profile-v2.0-14.pdf, which describes mechanisms for using SAML to convey an authenticated requesting identity for services accessed using a proxy. (I think this is the specification that a future Shibboleth implementation will use.)
(35) Guanxi vs Internet2 Service Provider module - http://wiki.oss-watch.ac.uk/SakaiVre/GuanxiVsInternet2.
(36) SPIE Shibboleth JAAS Module Architecture - http://spie.oucs.ox.ac.uk/Wiki.jsp?page=JAASmoduleArch.
(37) Integrating Shibboleth and Tomcat - http://wiki.oss-watch.ac.uk/ShibbolethTomcatIntegration. (Section 4 discusses use of the SPIE JAAS module.)
(38) Shibbboleth and WebAuth integration - http://wiki.oss-watch.ac.uk/SakaiVre/ShibbolethWebAuthIntegration.
(40) Adapting Sakai Authentication and Authorization - http://wiki.oss-watch.ac.uk/SakaiVre/SakaiUserDirectoryProvider.
(41) Guanxi wiki web site - http://www.guanxi.uhi.ac.uk/index.php/Guanxi:About.
(42) Sakai VRE demonstrator user requirements - http://wiki.oss-watch.ac.uk/SakaiVre/UserRequirements.
-- GrahamKlyne 2006-10-20 15:00:00