Integrating Sakai and Shibboleth

Overview and conclusions

Graham Klyne, Research Technologies Service, Oxford University Computing Services

October 2006

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.

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:

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

3.1. Goals

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:

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:

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:

All of these are problematic, or are at least not readily available within the time frame of this project.

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".

4. 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:

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

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

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/ - 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/ - 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/ - 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 -, 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/ - 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/ - 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/ - 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-mapping> }}}

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.

5. Shibboleth

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:



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:

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):

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

The "N-tier authentication problem" for Shibboleth is discussed in the SPIE project (28) document "An Approach for Shibboleth and Grid Integration" (19).

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:

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

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

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

6. Experiences

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.

6.1. Sakai

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: section 3.1, and (16).

6.2. Shibboleth

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, (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.

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, 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:

  1. Return an HTTP "401 Unauthorized" response
  2. 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.

7.2. Shibboleth

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:

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:

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, 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.

8. Acknowledgements

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

9. References

(1) Sakai project home page -

(2) Shibboleth home page -

(3) Sakai VRE demonstrator project home page -

(4) Sakai VRE demonstrator project, Oxford component home page in OSS-Watch wiki -

(5) Sakai VRE demonstrator project, Oxford component, planning and progress index page -

(6) Sakai VRE demonstrator project, Oxford component, documents and links -

(7) Sakai VRE demonstrator project, Oxford component, summary of original project plan goals -

(8) Sakai VRE demonstrator project, Oxford component, derived project goals -

(9) SDSS Shibboleth federation -

(10) Shibboleth federation for the Sakai VRE demonstrator -

(11) Stanford WebAuth -

(12) JA-SIG Central Authentication Service (Yale CAS) -

(13) Shibboleth Installation Notes -

(14) Shibboleth Configuration Files - Shibboleth-configuration-diagram-Visio.vsd (VISIO format).

(15) Debian Linux Installation Notes (including some notes about Shibboleth installation) -

(16) Sakai Notes (general description and installation notes) -

(17) Sakai and Portals, Charles Severance, Portals and Portlets Workshop, July 2006 -

(18) WSRP4J, Apache Software Foundation incubator project -

(19) An Approach for Shibboleth and Grid Integration, Francisco Pinto and Christian Fernau, Research Technologies Service, Oxford University -

(20) JAAS Standard-based Shibboleth/PERMIS Integration, Christian Fernau, Francisco Queir´os Pinto, JISC Core Middleware SPIE Project, Research Technologies Service, Oxford University -

(21) JSR 168: Portlet Specification -

(22) Spring Framework -

(23) JavaServer Faces Technology -

(24) Cascading Style Sheets (CSS) -

(25) Security Assertion Markup Language (SAML), at the Security Services Technical Committee of OASIS - See in particular the Assertions and Protocols document (informally known as the "core" spec)

(26) Shibboleth Notes -

(27) Shibboleth and WebAuth integration - (Contains diagram of Shibboleth deployment and a list of levels of authorization.)

(28) SPIE project home page -

(29) Shibboleth & WSRP, Jasper Tredgold, Nikki Rogers, ILRT Bristol, 6 April 2006 - (See also and

(30) uPortal home page -

(31) ShibGrid Project: Integrating NGS into the academic framework -

(32) MyProxy Credential Management Service -

(33) Liberty Alliance ID-WSF 2.0 Draft Release 3 Specifications -, also 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.)

(34) The Internet is Too Secure Already, Eric Rescorla, RTFM, Inc. (Presented at USENIX Security 2003) -

(35) Guanxi vs Internet2 Service Provider module -

(36) SPIE Shibboleth JAAS Module Architecture -

(37) Integrating Shibboleth and Tomcat - (Section 4 discusses use of the SPIE JAAS module.)

(38) Shibbboleth and WebAuth integration -

(39) Debian GNU/Linux home page -

(40) Adapting Sakai Authentication and Authorization -

(41) Guanxi wiki web site -

(42) Sakai VRE demonstrator user requirements -

-- GrahamKlyne 2006-10-20 15:00:00

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.