The following consist of brief recommendations for joining a Shibboleth Federation. There is currently no production Federation in the UK that higher and further education institutions can join. However, there is a JISC "blueprint" for a Federation structure (see section 2.7).
Currently it is desirable that there are as few Federations as possible in the UK. One overarching HE Federation, with a set of basic policies could be set up. From this subsets of institutions or departments should be able to federate, operating within given parameters relevant to that groups, and potentially requiring a slightly different set of attributes for authentication and authorisation allowing access to resources relevant to that group. In this way the Shibboleth Federation should become a "network of networks".
The goal of the Shibboleth Federation should be to equip educational institutions and online resource and service providers with a credible platform for exchanging information in a highly secure and privacy-preserving manner while at the same time reducing the administrative burdens associated with setting up multiple accounts and managing user access. Therefore, in the UK any higher or further education insitutions would be able to join the Shibboleth Federation if they could guarantee to fulfill the minimum requirements (see section 3.3).
The other participants would need to be the resource and service providers, which could be the higher and further education institutions themselves, but would also include JISC-negotiated services, publishers and others offering suitable resources and, again, meeting the minimum requirements for membership (see section 3.3).
The Federation could be run by an organisation (such as SwitchAAI or InCommon) or could be run as a consortium. In the former model each organisation that is a member of the Federation signs a bilateral agreement with the Federation Service. In the second scenario a consortium that is by definition an agreement, combination or group (as of companies) is formed to undertake an enterprise beyond the resources of any one member.
Whichever model is adopted for the Federation, it should be overseen by a steering committee who are elected from the membership. Committee members in existing Federations are commonly elected every two years and can be re-elected. In addition there are often sub-groups of the steering committee that work on relevant issues such as evaluation or communications. In the case of a Shibboleth Federation there would also need to be a technical sub-group.
The following are the indicated minimum requirements following the SDSS demonstrator model:
At their most simple, the Identity Provider requirements are:
the operation of an authentication system for local accounts
the operation of a user directory which supports, as a minimum, the manadatory attribute set (unique ID, surname, given name, home organisation type, affiliation).
In the UK it has been estimated by the SDSS project that some institutions would be nable to satisfy these requirements directly.
For the Service providers the requirements are
the resource owner must be either a Federation member (for institutions) or Partner (for commerical resources)
the resource owner must qualify to become a holder of a server certificate.
In more detail, the following requirements should be met:
Institutions must install the Shibboleth target software as described in the deployment guide at http://shibboleth.internet2.edu/guides/deploy-guide-target1.2.1.html;
An X.509 certificate from GlobalSign must be obtained; the same certificate may be used for both an identity provider and a service provider;
Compliance with UK Data Protection and EU directives regarding Data Protection must be ensured;
A schema should be adopted for transferring attribute data to the federation; identity providers must be able to populate at least the mandatory elements of the schema;
Identity Providers must take due care to ensure that personal data is correct and up to date before release to the Service Providers;
Identity Providers need to assign a unique identifier to each user; the eduPerson schema could be a useful model in this context:
eduPersonPrincipalName (EPPN) attribute should be used as the unique identifier of a user;
the domain part of the EPPN attribute should be the only domain of the identity provider;
Service Providers should be aware that one person may have more than one EPPN, either because they have two different roles or because they are members of two institutions. The User will have to assess which identity to use with which Service;
the EPPN of a user should not change unless for specific reasons (such as a family name change if the EPPN contains that field); Service Providers should be informed of such changes so that a User's profile is not lost
revoked EPPNs should not be reassigned unless the user has not used the EPPN for a period of more than 2 years; Service Provider's should ensure that the user profile is deleted if the user has not logged in to the service for a period of more than 2 years
Data Protection law states that logs of use of personal data should be kept for three years; both the Identity Provider and the Service Provider need to keep logs containing the user's Shibboleth use; Identity Providers also need to keep a log of the User's Unique Identifiers.
The Identity Provider should maintain a description of its identity management and collection procedures which can be provided to End Users, as well as other Identity and Service Providers.