Attribute identification & storage

Table of Contents

Attributes for Shibboleth
About Attributes
What are attributes?
Why does Shibboleth need attributes?
Identifying useful attributes
Technical issues
Management issues
Attribute standards
What is eduPerson?
Which attributes should I choose?
Which attributes does the federation need?
Storing and retrieving attributes
Aggregation of attributes
Release of attributes - who can?...

Attributes for Shibboleth

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.

About Attributes

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.

What are attributes?

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.

Why does Shibboleth need attributes?

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.