• SakaiVre
• ShibbolethFederation

Shibboleth deployment for Sakai VRE demonstrator

A page for collecting and recording issues relating to a Shibboleth federation and deployment to provide access control across the Sakai VRE Demonstrator partner sites.

Contents:

1. Summary of requirements at each site

In terms infrastructure, we require at each site:

• A running Sakai system (of course).

• A means of authenticating web-based access requests from mmembers of the host institution (e.g., at Oxford we use Stanford WebAuth, which is a web front-end to Kerberos. JA-SIG Central Authentication Service (Yale CAS) 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.

[[[Shibboleth component diagram]]]]

2. Partner portal sites

3. Local authentication mechanisms

What local authentication are the various sites using?

(*) based on comments from David Spence at RAL - we are assuming that Daresbury will use the same system. "Yes, it is all one system Daresbury/RAL/CCLRC are all using the same domain, i.e. our IdP should work for people at Daresbury."

The Active Directory is compatible with Kerberos (ie the AD is effectively a KDC and so can be used by UNIX domain apps e.g. we use if with Apache+mod_auth_kerb to provide the authentication for Shibboleth). The AD also has a LDAP interface for discovering information about principles which we use to generate Shibboleth attributes.

4. Local attribute authorities

What attribute sources are the various sites using?

(*) based on comments from David Spence at RAL - we are assuming that daresbury will user the same system. (See also comments in previous section.)

5. Avaliable Shibboleth IdP Deployments

This section summarizes what we know about existing Shibboleth IdP deployments at each site, that are available to be used with the Sakai VRE demonstrator. Each VRE system deployment will need a corresponding Shibboleth SP deployment.

• InQueue is the Shibboleth/Internet2 test federation.

• SDSS is a test federation for UK higher education.

6. Sakai VRE host platforms

What local hosts and platform software (e.g. Apache, IIS, etc.) are the various sites using to serve their Sakai VRE environment?

7. Core attributes

What core attributes (groups membership, user information, etc.) need to be available project-wide (hence across the Shibboleth federation) to provide basic operational controls?

Other attributes suggested are:

• "givenName", e.g. "David"
• "uid", e.g. "drs65"

• "scoped-uid", e.g. "drs65@cclrc.ac.uk"

• "[eScience]Org", e.g. "CCLRC"

See also SakaiVre/AttributeMappingsTable for related information.

The attributes should probably also be related to the EDUCAUSE eduPerson attributes. Details of these can be found here:

• http://www.educause.edu/eduperson/

• http://lab.ac.uab.edu/vnet/documents/ldif/eduperson.schema

8. Sakai login and personalization mechansism

• What mechanisms are most appropriate for getting authenticated attributes and options into Sakai that can be used for access control and personalization decisions?
• Ask for other partners experience with Sakai login mechanisms; e.g. can Sakai login/personalization setup use JAAS modules or arbitrary HTTP header fields?

• https://source.sakaiproject.org/svn/trunk/sakai/common/authentication/ - Sakai source code dealing with low-level authentciation functions. All I can find is very primitive username/password or external username provision. As yet, I don't see where it's actually invoked, hence how to hook in an arbitrary external authentication / attribute source.

9. Choice of Shibboleth federation

Currently, we are recommending SDSS http://www.sdss.ac.uk/ as the federation for Shibboleth access control across this project.

Alternatives might be:

• roll our own

• use InQueue (Internet2 test federation)

• some other existing federation

10. References

• ShibbolethNotes - notes about Shibboleth

• ShibbolethInstallNotes - notes about installing Shibboleth

• SakaiVre/AttributeMappingsTable - more detailed survey of LDAP and Shibboleth attribute and values

• http://sakaiproject.org/ - Sakai project

• https://source.sakaiproject.org/svn/trunk/sakai/ - Sakai source code SVN repository

• http://java.sun.com/products/jaas/

• http://www.sdss.ac.uk/

• http://webauth.stanford.edu/ - Stanford WebAuth

• http://www.ja-sig.org/products/cas/ - JA-SIG Central Authentication Service (Yale CAS)

• http://www.educause.edu/eduperson/ - EDUCAUSE EduPerson home page

• http://lab.ac.uab.edu/vnet/documents/ldif/eduperson.schema - LDAP/LDIF schema for !eduPerson attributes

---

-- GrahamKlyne 2006-06-19 13:25:59

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.