UKAMF Consultative Exercise :

University of Exeter's summary of UKAMF specifications

Introduction

In October, 2006, UKAMF requested opinions about its first six specifications detailing the responsibilities of each member of the federation. The University of Exeter, as an Identity Provider, will have to implement a Shibboleth IdP service which tightly integrates with its LDAP Directory Server and then develop new storage management techniques for attributes. The 86 pages of specifications are summarised here into three pages to extract key points for the attention of all Exeter staff currently implementing the Athens protocol. The UKAMF specifications and their local abbreviations used in this document are.

Rather than analyse each specification in turn, the collected opinions and recommendations from all documents are listed by topic with reference to their original content. The assessment exercise to measure Exeter's compliance with each item will be performed once the Exeter IAM project is formally introduced.

Should you not be familiar with IAM phraseology:

The Identity Provider is the University of Exeter Identity and Access Management System.
The Service Provider is an online publisher who currently uses Athens to make their content available for online browsing.

Summary

1. UKERNA - the federation provider

1.1 UKERNA reserves the right to introduce charges to the federation members for administering the Federation [MEMB 2.5].

2. Legal responsibilities of Exeter

2.1 Exeter has to ensure that all staff, associates and students abide by the multiple licences and agreements of Exeter, the service providers and the networks used to access them. If conflicting policies occur, they must adhere to the most restrictive. [MEMB 6.8]

2.2 Exeter has no liability to any other Federation member because of their membership. Therefore Exeter must make sure each of its user's waives any claim of whatever nature, within reason, against UKERNA and service providers [MEMB 7.2]

2.3 UKERNA has listed in some detail the precise limitation of liability [MEMB 7.3 to 7.6]. It is assumed these limitations follow Athens policy, but should be verified by legal counsel, especially as they state that neither Exeter nor UKERNA are responsible for loss of profits, savings, business, employee time, etc.

2.4 All user data processed at Exeter must conform to the eight data protection principles in Schedule 1, Part 1 of the 1988 Data Protection Act [PERS 2.2]

2.5 IdP service log file content can only be disclosed to UKERNA and service providers after the permissions of every user mentioned in the log file has been obtained [PERS 4.4]

3. IdP Service Operation at Exeter

3.1 Shibboleth is the recommended system for the communication of authentication, entitlement and attribute information, but any SAML-compliant software may be used. [TECHREC 2.1]

3.2 "SAML1.1 Browser/POST with Attribute Pull" is the recommended Shibboleth profile, which is the one used by Project SWISh. The "Browser/Artifact with Attribute Push" variant is not widely supported even though it removes the need for the browser to support JavaScript. [TECHREC 3.2.1-2]

3.3 SAML-2 has scope for many new profiles, but it is unclear what standards will emerge, particularly with the release of Shibboleth 2 in early 2007 [TECHREC 3.2.2]

3.4 Federation metadata consists of a set of XML data about every member of the federation. This reference file should be downloaded into the Exeter IdP service every night from a new UKERNA secure site. [TECHREC 4.3] Shibboleth-2 allows the inclusion of each service provider's required attributes in the metadata file. [TECHREC 4.5.2]

3.5 Exeter must generate and retain log files of all federation transactions that record the date, time, local user ID and Shibboleth SAML assertion subject. Log files must be kept for a minimum of three months and deleted after six months. [PERS 4.3]

3.6 The ac.uk domain has two versions of domain name for each UK university: for us it is ex.ac.uk and exeter.ac.uk. These can be used interchangeably when resolving hosts within DNS, but this is not the case in SAML attribute management. Exeter must choose which version it will use for all attribute values and not deviate from this value. SWISh chose exeter.ac.uk [TECHREC 7.1.1]

3.7 As Exeter will become a unique source of knowledge in providing secure Identity Management, a potential revenue source develops for Exeter in managing identities for schools, colleges and adult education institutions throughout Exeter, Devon or the south west. However, it will be staff-intensive and require the development of unique software from existing projects such as Grouper and Signet. [IDP 5]

4. Identity Management at Exeter

4.1 All user data kept on Exeter systems must be accurate and up-to-date, especially data that is released to service providers. [MEMB 3.1.1]

4.2 The process of issuing credentials to Exeter users must be fully documented. These procedures must be made available on request for auditing by service providers [MEMB 6.2] and UKERNA [MEMB 8.1]

4.3 When collecting personal data from users, Exeter must tell them what it will be used for and whether it may be disclosed to other federation members. [PERS 2.2.1]. Users must be told that logs about their online activity will be kept for six months. [PERS 4.3]

5. Attribute Management at Exeter

5.1 When designing the attribute schema, emphasis should be placed on ensuring that the attribute values do not reveal any more personal information than is absolutely necessary. For instance, do not user the year of commencement of study as part of the userID. [PERS 3.1]

5.2 UKERNA aims to reduce the potential exploitation of a huge choice of attributes [PERS 3 and TECHREC 7] by classifying them according to the definitions in Table 1. Notice the need to store multiple values for some attributes.

Table 1. Attribute definitions
Attribute class	Name	Typical value	Multiple values?
Standard	eduPersonScopedAffiliation	staff@exeter.ac.uk	Yes
Standard	eduPersonTargetedID	sjd772h47dh767wy@exeter.ac.uk	Yes
Exceptional	eduPersonPrincipalName	sarah.smith@exeter.ac.uk	No
Exceptional	eduPersonEntitlement	urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted	Yes
Subsidiary	None defined yet

5.3 The permitted values and definitions for the eduPersonScopedAffiliation attribute are show in Table 2 [TECHREC 7.1.2.1].

Table 2. Permitted values of ePSA attribute
Defined value	Authorised to access licensed material	User Notes
student	yes	Undergraduate or postgraduate
staff	yes	UK term for all staff
faculty	yes	US term to distinguish teaching staff
employee	yes	Other than staff/faculty [e.g., contractor]
member	yes	Comprises all the categories named above
affiliate	no	Relationship short of full member
alum	no	Alumnus [graduate]

5.4 The eduPersonTargetedID value should never be reassigned to another user . To protect against this, a copy of every value ever used should be stored and checked for potential conflict. [TECHREC 7.1.3.1] There are a variety of ways to generate this value and as its definition has altered in the latest release of the eduPerson Object Class specification, which should be studied to determine best practice.

5.5 Exeter has to create an Attribute Release Policy database that records which attributes can be released to which service provider. [PERS 3.3] Ultimately Exeter will have to offer each user the ability to change their personal settings in line with Data Protection Act principles. The potential scale of this database, stored in the IdP system as XML files is immense: 250 service providers X 15,000 users X 4 attributes. If each user is allowed to alter their settings (as the ShARPE ARP Editor offers), then each user must be told in clear language the consequences of their changes. [PERS 3.3]

5.6 Any new subsidiary attributes required by service providers should be derived from existing object class specifications: eduPerson, person , organizationalPerson and inetOrgPerson. These are already included in open source LDAP directory servers. [TECHREC 7.4].

5.7 The UK's MIAP has developed a Learner Registration Service which issues a 10 digit Unique Learner Number to UK users for life. UKERNA Are considering defining this number as a subsidiary attribute. [TECHREC 7.7.1]

6. X.509 Certificate Management at Exeter

6.1 Exeter must ensure that its high standards of security are used in the protection of all user information, using multiple services to protect against intrusion from unauthorised users, computers and networks [MEMB 3.1.3].

6.2 UKERNA only accepts certificate products from a limited range of providers: Globalsign, Thawte, Verisign.This rules out Exeter's use of free certificates from companies such as IPSCA and using wildcard certificates. [TECHREC 5.2]. UKERNA plans to offer low cost certificates from TERENA SCS in early 2007. [TECHREC 5.4.3 and FEDTECH 2]

6.3 An alternative mechanism of public key validation that does not require path validation to the CA will be possible in Shibboleth 2 XML metadata. This is called a "hybrid trust fabric" and uses public keys embedded in the UKERNA federation metadata that is distributed to every member of the federation every night. [TECHREC 5.4.6] This is a candidate design goal for UKAMF X.509 key management. [FEDTECH 2]

6.4 Project SWISh used a single X.509 certificate for its IdP Service, when technically it could have had one for the browser-facing sessions and a separate for the trust fabric information exchange. Obviously a separate certificate for each is more secure and easier to recover from should a certificate key compromise happen. [TECHREC 5.1]

6.5 Should a certificate key compromise occur, Exeter must immediately follow the expected procedure of contacting the Certificate Authority that issued the certificate and advising UKERNA. [TECHREC 5.3]

7. Service Providers

7.1 Every service provider should publish the attribute values needed to access their online resources.[PERS 3.3]

7.2 Only the least specific value of a user should be sent to a service provider, to provide the maximum anonymity of the user. [TECHREC 7.1.2.3] The eduPersonScopedAffiliation and eduPersonTargetedID attributes provide that anonymity so to keep within privacy laws, should be the preferred attributes for exchange. [TECHREC 7.2]

7.3 Custom attributes defined by a service provider are not forbidden by UKERNA, so there is always the capability for a provider to assert its uniqueness of product and to demand the adoption and inclusion of its attribute by any IdP requiring access. [TECHREC 7.5]

Nick Johnson
Version 1.0
1 November 2006