UCTrust

University of California Identity Management Federation

Service Description and Polices

March 15, 2005

1. INTRODUCTION

UCTrust is the basis for a unified identity and access management infrastructure for the University of California system. UCTrust enables authorized campus individuals to use their local campus electronic credential to gain access, as appropriate, to participating services throughout the UC system. UCTrust is based on industry standard technologies and a common set of identity attributes and identity management practices.

2. BENEFITS of UCTrust

• UCTrust enables cost-effective, privacy-preserving collaboration among participating UC campuses. It makes sharing protected online resources easier and eliminates the need for resource providers to maintain multiple, password-protected accounts.

• UCTrust supports individual access to protected resources by allowing campuses to make decisions about granting access to resources based on authoritative information offered by the individual’s campus regarding that individual’s status or local privileges. Authoritative information can be maintained in one place rather than being duplicated and possibly out of date.

• UCTrust offers a high level of security by utilizing strong authorization controls over secure access channels. This high level of security also provides a secure mechanism for ensuring privacy in the exchange of identity and authorization attributes. In addition, the method of authenticating individuals can be identified to the participating service provider, which in turn can use that in its access decision.

• UCTrust can reduce account management overhead. As a UCTrust participant, individual services can make their resources available to campuses who own responsibility for managing user authenticating electronic credentials.

3. PARTICIPATION IN UCTrust

A fundamental principle of UCTrust is that participating campuses provide authoritative and accurate attribute assertions, that is, the identity information provided by the campus about individuals in their campus community. This implies adherence to uniform business practices in establishing electronic credentials and maintaining individual identity information. Equally important is the principle that providers receiving an attribute assertion protect it and respect the privacy constraints defined by the participating campus.

The local campus may use a “single sign-on” mechanism, or any method that supports local web-based applications. The individual’s campus will then send only the required information about that individual to the requesting service provider application. The service provider’s application will make an access decision based, at least in part, on the information it receives. The service provider application retains complete control of access management.

The current version of UCTrust is based on participation in Internet2’s InCommon federation, using Shibboleth® technology. Shibboleth makes use of whatever local authentication system the campus supports, and handles the exchange of identity information among identity management systems and participating applications. More information on InCommon may be found at http://www.incommonfederation.org/index.cfm

4. GOVERNANCE

The University of California IT Leadership Council (ITLC) acts as the governing body of UCTrust by providing oversight and conflict resolution of the UCTrust Task Force. The UCTrust Task Force manages operational policies and procedures. It is composed of representatives of UC campuses Identity Managers, Service Providers, UCTrust System Administrator, and IR&C Immediate office, as approved by the ITLC.

The UCTrust Task Force approves applications from Identity Providers and Service Providers for participation in UCTrust as referred by the UCTrust Federation Administrator.

5. UCTrust FEDERATION ADMINISTRATION

Administration of UCTrust is conducted by an operational unit in IR&C. Duties include:

• Facilitate membership in UCTrust

  • Review and document Identity Provider compliance with UCTrust requirements.

  • Review and document Service Provider compliance with UCTrust requirements, including contact information

  • Validate that best practices have been incorporated into design implementation

  • Periodic review and documentation of Identity Provider and Service Provider qualifications.

  • Submit request for participation to UCTrust Task Force.

• Maintain information repository

  • UCTrust service description requirements

  • metadata describing Service Providers

  • descriptions of UCTrust-specific attributes

  • technical support contact information for all Identity Providers and Service Providers in a form accessible to each

• Assist problem resolution between Identity Providers and Service Providers.

6. RESPONSIBILITIES

Responsibility for participation in and administration of UCTrust consist of the following:

1. Identity Provider

Identity Providers are the campus organizations that manage electronic identity information and provide identity information and authentication services for their campuses/sites. (These may be referred to as the Shibboleth origin.)

Identity providers are responsible for a campus's enterprise directory, that is, the campus's repository of information about the members of its community. Identity Providers are also responsible for the identification, registration, and authentication processes that bind specific Community Members to the information about those members in the enterprise directory. In particular, Identity Providers are responsible for:

• accuracy and timeliness of information in the enterprise directory.

• privacy of information in the enterprise directory. This requires a registration process by which services are authorized to utilize identity information.

• availability of the network-based services that provide access to information in the enterprise directory.

• accuracy of the binding of Community Members to information in the enterprise directory. This includes:

• the identification and registration processes, which result in the issuance of electronic credentials (e.g., user ID and password) to Community Members.

• the authentication process, which verifies possession of credentials within each session.

• tools and procedures for community members to update their identity information, such as passwords.

• audit logs that enable investigation of security incidents and misrepresentation of identity.

• standards and best practices that guide the behavior of Service Providers and Community Members in the use and protection of identity information. In order to facilitate use of services by members of multiple campus's communities, the UCTrust Task Force establishes minimum requirements and service levels for all Identity Providers within UC.

• help desk function for community members to resolve issues.

• technical support contact for Service Providers and UCTrust Federation Administration

As part of the membership requirements for UCTrust, Identity Providers will provide documentation (i.e., service level descriptions) describing their compliance with these responsibilities.

2. Service Providers

Service Providers are the organizational units that manage electronic information resources that have been registered with UCTrust. These services are generally network-based, but may not necessarily be so. (These may be referred to as the Shibboleth target.)

Service Providers are responsible for the secure operation of their services. With respect to their use of identity information, they are responsible for:

• awareness of Identity Providers’ service levels. When multiple levels are available (or negotiable), selection of appropriate service levels to meet the service's needs. When a sufficient service level is not available from the Identity Provider, the Service Provider may need to implement its own identity management services in order to meet its service's security requirements.

• audit logs that enable investigation into security incidents related to information provided by Identity Providers.

• compliance with Identity Providers standards and best practices for use and protection of identity information.

• technical support contact for Identity Providers and UCTrust Federation Administration.

Service Providers are also responsible for standards and best practices that guide the use of their services, as well as appropriate audit logs and descriptions of their service levels. Those responsibilities, however, are outside the scope of this document.

3. Community Members

Community Members are the individuals who have officially established an affiliation with a campus. They are the individuals who use the Service Providers' services and whose electronic identity is managed by Identity Providers.

Community Members are responsible for protection of the electronic credentials provided to them by their Identity Provider. In particular, they are each individually responsible for:

• assurance that their credentials are not held by other people.

• compliance with Identity Providers’ standards and best practices for use and protection of identity information.

Community Members are also responsible for conformance with Service Providers' standards and best practices. Those responsibilities, however, are outside the scope of this document.

7. MINIMUM REQUIREMENTS AND SERVICE LEVELS

Participating campuses must join InCommon. InCommon maintains a table of Common Identity Attributes, which are recommended for participation in InCommon. Campuses may extend this attribute set in collaboration with UC Systemwide or other campuses.

UCTrust maintains an additional set of common identity attributes that are required for participation in UCTrust, such as UCnetID. This list contains a description of each attribute assertion of identity information to be used in UCTrust, including data format and the URN that uniquely names the attribute. It also contains rules for governing release and use of all attributes.

1. Specific Requirements for Identity Providers

   1. Authentication, attribute, and other application services provided by the Identity Provider must be operated according to the requirements in Business and Finance Bulletin IS-3 for restricted and essential information resources.

   2. The identity of employees must be verified by official University hiring procedure.

   3. The identity of students must be verified by official University admissions procedure.

   4. Guests or other affiliates must be verified by an established campus authority.

   5. If campus identities exist that have not been verified according to current UCTrust requirements, those identities must be re-verified prior to those individuals’ use of UCTrust.

   6. If shared secrets, such as passwords, are transmitted during authentication, appropriate encryption must be used to protect the privacy of that exchange. Such encryption must meet or exceed the protection provided by 128-bit SSL.

   7. In order to provide interoperability with Service Providers, Identity Providers must implement thef specific attributes identified in UCTrust: Common Identity Attributes (separate document)

   8. The registration process for issuing credentials may be either in-person or remote:

• In-Person

  • A government or University issued ID with a picture must be presented to and verified by campus authority as belonging to the registrant.

• Remote

  • The registrant must be prompted for at least two identifying attributes that are verified as belonging to the registrant. The attributes should be chosen to be relatively accessible to the registrant, but not to others. Examples include employee or student ID, birth day and month, Social Security Number, date of hire, etc.

  • The process should include a step to confirm existing records of the registrant’s electronic mail address, telephone number, or postal address, for example, a confirming email or a letter sent to registrant’s postal address. This step should either precede issuing credentials or be capable of revoking already-issued credentials in a timely manner.

1. The registration process must include checks to avoid the use of easily-guessed passwords.

2. If a single sign-on system is utilized, session timeouts must be utilized to mitigate the risk presented by unattended workstations being used by unauthorized people.

3. Identity Providers must publish in a format accessible to participating Service Providers:

• description of each attribute assertion of identity information that is available to UCTrust, including data format and the URN that uniquely names the attribute

• rules for governing release and use of all attributes

• description of the identification process that the campus uses to manage the repository of identity information for the campus community, linking the individual with the electronic identity and electronic credential, e.g., password, etc.

• description of the registration process used to issue electronic credentials

• description of authentication technology, e.g., Kerberos

12. Identity Providers must provide a help desk function for problem resolution related to identity management and authentication.

2. Specific Requirements for Service Providers

   1. Applications that utilize UCTrust must be compliant with all University policy regarding privacy, security, and application development.

   2. Service Providers are responsible for the security and of their services; they must implement any additional authentication measures required for the criticality or sensitivity of the application or the data accessed by the application.

   3. Service Providers must conduct appropriate usability testing prior to registration with UCTrust Federation Administration.

   4. Service Providers must provide help desk function for problem resolution related to the application.

It is anticipated that higher levels of assurance will be implemented for UCTrust in the future. Those higher levels of assurance will include different sets of requirements.

8. TECHNICAL SPECIFICATIONS

Each member of UCTrust must be capable of exchanging attribute information with other members of UCTrust through the use of the protocols and formats implemented by Shibboleth version 1.2. The use of Shibboleth itself is highly recommended. The X.509 server certificates used to authenticate the site's Shibboleth servers must be issued by InCommon.

9. BEST PRACTICES

   1. Synchronization with Repositories of Record

• Establish processes that maintain close synchronization of Employee affiliations in the identity management repository with the corresponding records in the campus’s instance of PPS. Changes should be reflected in the identity management repository within 24 hours, if not sooner.

• Establish processes that maintain close synchronization of Student affiliations in the identity management repository with the corresponding records in the campus’s student information system. Changes should be reflected in the identity management repository within 24 hours, if not sooner.

• In general, when there is an existing repository of record for an identified category of users, synchronization should be maintained within an appropriate time interval.

2. Multi-Factor Authentication

• When UCTrust does not provide sufficient assurance for a particular service, as determined by the Service Provider, the Service Provider should use Multi-Factor Authentication to attain that higher level of assurance. For example, after receiving UCTrust’s assertion of a user’s identity, a high-security service could require possession of a hardware token (e.g., a smart card) or request that the user provide some shared secret.

• Possible sources for shared secrets include a) the answer to a question previously provided by the user, and b) one or more pieces of information that are well-known to the user, but not to others,

• An option for community member to use a secondary credential for validation when accessing ones own personal information may be implemented by a service provider to provide the community member a choice between convenience and security. Note that this will likely require an audit log entry by the service provider.

3. User Interface Design

• There is a certain amount of “bouncing” of community members between identity providers, service providers, and the “Where Are You From?” (WAYF) server that is inherent in the technology. Care should be taken to mitigate the confusion this may cause.

• Where possible, campuses should structure login processes to occur when community members initiate network sessions. The process should also interact with the InCommon WAYF to declare the “origin” institution without user interaction later in the session.

• Provide clear indications of the help desk that should be contacted for problems that may occur at each step.

• It is highly recommended that both service providers and identity providers conduct usability studies to identify confusing aspects of their user interfaces.