Table of Contents
Once an identity provider (IdP) is set up and working the next stage of a Shibboleth project is to identify which attributes you want to use to make authorisation decisions. The use of attributes to make authorisation decisions is a recent development; names and values for attributes will evolve as service providers are set up and start to require them. The Internet2 eduPerson schema has been developed for this purpose.
An institution (or Identity Provider) is responsible for providing attributes about each of its members (e.g. staff in department x, student from department y, or the type of role of student or staff, as well as specific entitlement to restricted resources). The institution is also responsible for supplying an Attribute Release Policy so that administrators can choose which attributes should be released to which online resources (or Service Providers). Administrators may also become involved in deciding which attributes should be released to federations. Individual users also have the facility to override and institutional policy for the release of their own attributes so have control over their own privacy.
Attributes are pieces of descriptive information about a user. They can theoretically be any piece of information about a user, however in the context of Shibboleth attributes are likely to be information which can be used to make access decisions, e.g. "user is member of staff" or "user is allowed to see medical content". Information, particularly personal information, such as "user is 137cm tall" is unlikely to be of use in terms of Shibboleth. Some attributes will describe a user's relationship to his home institution.
Attributes are the key to the way Shibboleth authorises user access to resources. Shibboleth uses information about a user to determine whether they will be granted access privileges. To illustrate this, currently the most common access decisions in use with Shibboleth would read:
"User A is a member of university X and can access journal Q because access university X bought access to journal Q.
User B is a member of university Y and can't access journal Q because access university Y hasn't bought access journal Q."
It is easy to envisage Shibboleth being used to facilitate much more complicated access decisions; i.e. a case in which only medical students taking the pathology course, who are enrolled for more than 2 years, can access autopsy photographs.
However, the Shibboleth Identity Provider software does not store or manage user attributes. To use the software effectively, an attribute store such as an LDAP directory or database needs to be set up. User data should be available on installation, or there should be some means of populating the data store set up.