Overview and High-Level Design

This document provides a high-level description of an infrastructure to support user provisioning for inter-campus applications within the University of California. Other documents will provide greater detail about components of this infrastructure, within the context of this overview.

For the purposes of this document, user provisioning is defined to be the processes, both human and automated, that authorize (and de-authorize) people to use application systems, when those occur at times other than the start of an online session.  This is distinguished from application systems that use a "pure" single sign-on infrastructure (e.g., Shibboleth), authorizing anyone with a defined set of attributes that are provided at the start of a session.

The infrastructure described in this document will support the exchange of identity information from campus Identity and Access Management (IAM) systems to application systems, not the entire set of provisioning processes.  The Roles and Responsibilities section below will identify responsibility those other provisioning processes.

Also, this infrastructure is specific to the exchange of identity information for user provisioning. It does, however, embody many aspects of a more general-purpose infrastructure for data interchange among arbitrary systems that may be useful in the future.

Principles and Assumptions

• Campus identity and access management systems are authoritative for information about the members of their respective communities.
  • (Note that much of the IAM's information will likely be aggregated from other systems of record on the campus.  Nevertheless, UCTrust designates the IAM as the authoritative contact for its campus.)
• The existing UCTrust agreements, policies, processes, and technology should be leveraged as much as possible.
• The design and implementation must make effective use of University resources.  Where possible implementations should be shared and/or reused.

High-Level Design

The following diagram illustrates the high-level design of this infrastructure for two applications that retrieve identity information from four campuses.

Just as with Shibboleth in UCTrust:

• Inter-campus applications obtain identity information about their users from IAMs through the use of standard network protocols and formats.  (Should we name that format?  Originally, I was thinking of SAML, as is used by Shibboleth, but we also discussed XACML, as I remember.)
• All IAMs and inter-campus applications have unique names that are assigned to be the same as Shibboleth's names for IdPs and SPs, respectively.
• IAMs control the release of information to service providers through the use of Attribute Release Policies, which specify which identity attributes should be released to an application. In the case of user provisioning, however, the application's SP name will also determine the users for which the IAM will release those attributes.
• Software will be provided, written in Java, for integration into each campus IAM to implement the standard protocols and formats.

Three types of access will be supported by the Common Interface:

• Snapshot. All identity information allowed by the attribute release policy will be transmitted to the application.
• Subscription. Identity information will be transmitted to the application as add, delete, and update transactions on an event-driven basis.
• PointInTime. All add, delete, and update transactions that have been generated since a specific point in time will be transmitted.(I wrestled with what to call these types of access, particularly PointInTime.  Anyone have a better set of names?)

Roles and Responsibilities

• IAM Responsibilities
  • Accuracy and currency of identity information
  • Maintenance of identity attributes, such as group membership, to enable selection of users to transmit to specific applications, based on attribute release policies.
  • Interfacing and operation of the Common Interface
  • The process for approving attribute release policies
• Application Administrator Responsibilities
  • Implementation of provisioning interfaces for the application
  • Implementation of appropriate protections for the identity information received
• UCTrust Responsibilities
  • Unique naming of all IdPs (IAMs) and SPs (inter-campus applications), as is already done for Shibboleth
  • Other UCTrust operational responsibilities, such as identification of support contacts, maintenance of logs, etc. These are described in UCTrust University of California Identity Management Federation Service Description and Policies.