Use cases for using Shibboleth with Sakai
This page is to build and document use cases for integrating Shibboleth attributes into Sakai login.
Shibboleth is an authentication and authorisation federation system from the Internet2 people http://shibboleth.internet2.edu/. Sakai is a portal and learning envirnment for higher education http://sakaiproject.org/.
1. Multi-centre collaborative research
Background: Researchers from different institutions are collaborating on one or more projects. One or more of the institutes hosts a Sakai environment for collaborative facilities. All of the institutes are members of a common Shibboleth federation (e.g., in UK, SDSS http://sdss.ac.uk/), and use Shibboleth to distribute authentication and role information. In the UK, and maybe elsewhere, this is likely to become increasing common with recent trends in funding council research funding http://www.e-framework.org/about.
Use case: a collaborating researcher accesses a Sakai environment hosted by another institute. Their Sakai login is fronted by a Shibboleth-federated Single Sign On (SSO), which connects the user's browser to their home institute's authentication facility, which in turn constructs a signed authentication and role assertion that is passed back by the Shibboleth service provider at the Sakai portal site. This in turn is used to validate and determine a level of that will be allowed by the Sakai portal.
2. Formation of ad hoc groups
Background: Many research groups, projects, wikis, conferences and other sets of people are both intrinsically inter-institutional and formed by individuals on an essentially opt-in-basis: people become part of the group by turning up.
Use case: A user finds a Sakai website they are interested in. When they access a Shibboleth protected resource (i.e. one that requires them to login), it redirects them to a Shibboleth login before they complete the SAKAI login. At this point the Sakai login page is processed; the user has already been authenticated and a (possibly trivial) set of attributes have been released about that person. If enough attributes are known, Sakai at this point should be able to automatically create the local user (one of the attributes is a persistent and true opaque user identifier for those users wishing to use the Sakai install anonymously), login the user in and simply redirect them back to the page from which they clicked the "login" link. If fewer attributes are known, Sakai may use a relatively standard login page, with some attributes aleadys completed.
3. Dynamic update of attributes
Background: Personal information changes, and distributed information systems need to reflect that change.
Use case: A user changes personal details (the email address, their name, etc) in the institutional attribute repository (LDAP, ActiveDirectory, etc) and accesses a Shibboleth protected resource within the Sakai install. The users attributes are determined as part of the Shibboleth authentication and authorisation process and are subsequently passed to Sakai. Sakai may have recorded some of these details as part of the Sakai account creation process and can compare one against the other. The change in details (or absence of details, for example when a user goes ex-directory) could be made automatically or the user could be queried.
4. Controlled release of attributes
Background: Some user information is personal information about them and may be covered by legislation concerning who may or may not have access to it and under what conditions.
Use case: A Shibboleth local attribute authority (the entity within Shibboleth responsibility for storage and retrieval of attributes as well as deciding which service providers are permitted access to which attributes) applies an attribute release policy that is specific to the user and service concerned, allowing controlled release of user attributes to any given service.
Use case: A user accesses a Shibboleth instance in a foreign country covered by different data protection, privacy and confidentiality laws. The users' home attribute authority seeks explicit consent from the user for the international transfer of their personal attribute data.
5. Project-level delegation of authorization
Background: A Sakai instance functioning as a VRE (Virtual Research Environment) will require fine-grained, local control of authorities. Elements of role assignment or permissions that are used to control access to project-specific resources should be determined and controlled by a suitably authenticated and authorized person within the project. This implies that roles themselves may be scoped in terms of projects to which they apply, and administrators who are allowed to grant and/or revoke them. It also implies a level of dynamism in the assignment of roles or permissions to authenticated users.
Use case: A VRE Principal Investigator (PI) controls access to individual resources based either on local roles ("grad students on the project" or "staff members on the project") or generic federation wide role ("science grad student", "academic staff member" or "student").
Use case: A VRE PI wishes to delegate administration of authorities to a member of the project team, by means of a delegation of authority granting authority.
(In our present project, we have a work item to use PERMIS for this purpose http://sec.cs.kent.ac.uk/permis/. The XACML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml open standard is designed for conveying authority as Shibboleth uses SAML for conveying identity information.)
6. Chained Account Providers
Background: Some users may want to tie Sakai directly into their core business systems and are unlikely to want to create local accounts in those systems for every user who logins in via Shibboleth federation. Thus multiple (or chained) providers are required.
User case: A user accesses a Shibboleth protected resource in a Sakai instance. User logs into Shibboleth and Sakai uses local attribute information (if the user is local) or Shibboleth attribute information (if the user is from the federation).
Sakai checks "Shib-Identity-Povider" attribute. If the Shibboleth login reveals the user to be a local user then the local account in the core business systems is used. If the user is non-local, secondary account management is used. OR
Sakai first a local (LDAP?) UserDirectoryProvider (UDP) for the existance of the user. If the UDP returns any attributes, they are used. If no attributes are used the Shibboleth UDP is asked for attributes.
7. Attribute Standards
Shibboleth attributes are typically encoded primarily using the EduPerson http://www.educause.edu/eduperson/ schema, which is already widely used for interoperability, primarily in LDAP, but also in ActiveDirectory.
-- StuartYeates 2006-07-17 13:43:14