UC IDM Provisioning Middleware: Technical Design Guide
UC IDM User Provisioning Middleware
Technical Design Guide
Working Draft 07, August 1, 2011
Document identifier:
draft-ucitag-idmprovisioning-design-guide-07
Location:
TBD
Technical Committee:
UC IT Architecture Group
UCTrust Work Group
Editors:
Albert Wu ([email protected]), University of California Los Angeles
Contributors:
Arlene Allen, University of California Santa Cruz
Dede Bruno, University of California, Office of the President
Dedra Chamberlin, University of California, Berkeley
Jeff McCullough, University of California Berkeley
Anthony Merriweather, University of California Los Angeles
Benn Oshrin, University of California Berkeley
Lucas Rockwell, University of California San Francisco
Dattathreya Sharma, University of California Los Angeles
David Walker, University of California, Davis
Mukesh Yadav, University of California San Francisco
Tom Zeller, University of Memphis
Abstract
This document provides a non-normative technical design overview and implementation guideline for the
UC Identity Management User Provisioning Middleware.
Document1
1
UC IDM Provisioning Middleware: Technical Design Guide
Status of This Document
This is a draft document. Its content will change before completion, Please submit comments to Albert Wu
([email protected]).
Document1
2
UC IDM Provisioning Middleware: Technical Design Guide
Table of Contents
1
INTRODUCTION ................................................................................................................................ 5
1.1 BACKGROUND ..................................................................................................................................... 5
1.2 ASSUMPTIONS AND RECOMMENDATIONS ............................................................................................... 5
1.2.1 Leverage the UCTrust Framework ........................................................................................... 5
1.2.2 Implementer Responsibilities .................................................................................................. 6
1.2.3 Implementation Timing ............................................................................................................ 6
1.2.4 Campus and Application Agnostic Design .............................................................................. 6
1.3 DEPENDENT (OUT OF SCOPE) COMPONENTS .......................................................................................... 6
1.3.1 Identity Provider........................................................................................................................ 7
1.3.2 Identity Registry ........................................................................................................................ 7
1.3.3 Service Provider ........................................................................................................................ 7
1.3.4 Target Resource (or Application) ............................................................................................. 7
1.4 OUTLINE ............................................................................................................................................. 7
2
UC IDM USER PROVISIONING MIDDLEWARE COMPONENTS .......................................................... 8
2.1 IDENTITY PROVIDER PROVISIONING AGENT ............................................................................................. 8
2.1.1 Change Notify Issuer ................................................................................................................ 9
2.1.2 Identity Registry Adapter....................................................................................................... 10
2.1.3 Attribute Authority ................................................................................................................. 10
2.1.4 Service Provider Registration Service .................................................................................. 10
2.1.5 Change Data Cache .............................................................................................................. 10
2.1.6 IdPPA Administration Service ............................................................................................... 10
2.2 SERVICE PROVIDER PROVISIONING AGENT .......................................................................................... 11
2.2.1 Change Notify Receiver ......................................................................................................... 11
2.2.2 Target Resource Adapter ...................................................................................................... 12
2.2.3 Attribute Requester ............................................................................................................... 12
2.2.4 IdPPA Registration Service ................................................................................................... 12
2.2.5 SPPA Administration Service ................................................................................................ 12
2.2.6 Change Data Cache .............................................................................................................. 12
3
COMPONENT INTERACTIONS ........................................................................................................ 13
3.1 OPERATING THE MIDDLEWARE IN A FEDERATED ENVIRONMENT ............................................................. 13
3.2 IDP PROVISIONING AGENT TO IDENTITY PROVIDER INTERACTION ............................................................ 14
3.3 SP PROVISIONING AGENT TO TARGET RESOURCE INTERACTION ............................................................. 15
3.3.1 LDAP TRA ............................................................................................................................... 15
3.3.2 CSV File TRA........................................................................................................................... 15
3.4 IDP PROVISIONING AGENT TO SP PROVISIONING AGENT INTERACTION ................................................... 16
3.4.1 Snapshot Update ................................................................................................................... 16
3.4.2 Subscription Update .............................................................................................................. 17
3.4.3 Batched Change Update ....................................................................................................... 18
4
IMPLEMENTATION GUIDELINE ...................................................................................................... 20
4.1 IMPLEMENTATION RESPONSIBILITIES .................................................................................................. 20
4.1.1 UCTrust’s Responsibility ....................................................................................................... 20
Document1
3
UC IDM Provisioning Middleware: Technical Design Guide
4.1.2 The UC IDM User Provisioning Team’s Responsibility ........................................................ 20
4.1.3 The Identity Provider Team’s Responsibility ........................................................................ 21
4.1.4 The Service Provider Team’s Responsibility ........................................................................ 21
4.2 IMPLEMENTATION TECHNOLOGY ......................................................................................................... 22
4.2.1 The UC IDM User Provisioning Middleware Should Be Implemented in Java. .................. 22
4.2.2 Data within and exchanged with the UC IDM User Provisioning Middleware must meet
specific authentication, authorization, and encryption requirements. .......................................... 22
4.3 IDENTITY PROVIDER PROVISIONING AGENT .......................................................................................... 23
4.3.1 Design Directives ................................................................................................................... 23
4.3.2 Target Resource Adapter Implementation .......................................................................... 24
4.3.3 Interacting with the SP Provisioning Agent .......................................................................... 25
4.4 SERVICE PROVIDER PROVISIONING AGENT .......................................................................................... 25
4.4.1 Design Directives ................................................................................................................... 25
4.4.2 Interacting with the Target Resource................................................................................... 26
4.4.3 Interacting with the IDP Provisioning Agent ........................................................................ 27
5
REFERENCES ................................................................................................................................ 28
6
DOCUMENT HISTORY .................................................................................................................... 29
Document1
4
UC IDM Provisioning Middleware: Technical Design Guide
1 Introduction
This document describes the conceptual design of an UCTrust-based middleware infrastructure that
enables on-demand user provisioning among the University of California’s inter-campus applications This
infrastructure represents an extension to the existing Shibboleth-based UCTrust infrastructure. It
complements Shibboleth’s front-channel, synchronous user data provisioning capabilities with a backchannel, asynchronous and/or batch user data change notification and replication mechanism.
For the purposes of this document, user provisioning is defined as the processes, both human and
automated, that authorize (and de-authorize) people to use application systems, when those processes
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 supports the delivery of identity information from campus
Identity and Access Management (IAM) systems to application systems. It does not account for the entire
set of provisioning processes.
A note to implementers: this document is not meant to be a detailed, normative specification document. It
is important that the implementation team of this project work closely with UC Trust members and UC IT
Architecture Group to clarify detailed implementation requirements and specifications throughout the
project.
1.1 Background
The UC IDM User Provisioning Middleware is built upon the following standards:


SAML V2.0 [SAML2Core]
SAML V2.0 Change Notify Protocol V1.0 [SSTC-SAML2-Notify-Protocol-V1.0]
1.2 Assumptions and Recommendations
1.2.1 Leverage the UCTrust Framework
The middleware described in this document leverages existing UCTrust agreements, policies, processes,
and technology. The document assumes the reader has detailed understanding of UCTrust technologies,
policies, and operating principles.
Where possible, the implementer of this infrastructure should leverage existing UCTrust agreements,
policies, processes, and technology.
This design assumes that the offices currently operating each UC campus’s identity management
implementation implement the Identity Provider Provisioning Service components. Furthermore, it
assumes that the same offices also operate the campus’ Shibboleth Identity Provider.
This framework provides a common mechanism for application systems to obtain identity information from
each campus’ identity management system. Merging the results from multiple campuses, however, is left
to the application.
Document1
5
UC IDM Provisioning Middleware: Technical Design Guide
1.2.2 Implementer Responsibilities
This document is a conceptual design guide. It’s written to frame the middleware infrastructure’s key
design scope and direction.
Throughout this document, it specifies technologies to be used in the middleware’s design. These
specifications are made to ensure that the eventual product leverages the work already done in the
UCTrust framework. However, this document is by no means a comprehensive and normative design
specification. The implementation team must still engage all relevant stakeholders (UCTrust, UC IT
Architecture Group, UC IT Leadership Council, key Service Providers) to iteratively determine detailed
implementation level architecture and software/hardware selection.
This document’s authors recommend that the implementation team include at least one fulltime technical
architect with detailed understanding of US higher education identity management issues to ensure
successful implementation.
1.2.3 Implementation Timing
Deploying identity provisioning middleware, or middleware in general, across UC requires time and
timing. Middleware, by definition, has no value on its own unless it facilitates interactions between other
components of an IT infrastructure. Without a compelling adoption use case (i.e., “the killer app”),
deploying middleware is difficult at best.
As of July 2011, UC is on the verge of adopting a new UC-wide HR/PPS system. All UC identity providers
will need to integrate with the new HR/PPS system; the HR/PPS project presents a compelling
provisioning middleware adoption use case. We recommend that the Provisioning Middleware
implementers adopt HR/PPS as its primary integration use case. We also recommend UC campuses pool
together resources allocated to perform HR/PPS to IDM integration to develop and deploy this
Provisioning Middleware.
1.2.4 Campus and Application Agnostic Design
Although the Provisioning Middleware will initially integrate only with a small number of applications, it is
critical that the Provisioning Middleware is standards-based and application-agnostic. To provide longterm value, this provisioning middleware must easily integrate with a wide variety of current and future
target applications without requiring significant modifications or extensions.
1.3 Dependent (Out of Scope) Components
The UC IDM Provisioning Middleware is one piece in a broader UC federated identity management
framework. To help clarify design, section 1.3 describes key identity management components the
Provisioning Middleware interacts with. These components are not within the implementation scope of the
Provisioning Middleware.
In addition, the SAML2 Glossary defines additional identity management related terms used throughout
this document. [SAML2Gloss]
Document1
6
UC IDM Provisioning Middleware: Technical Design Guide
1.3.1 Identity Provider
An Identity Provider creates, maintains, and manages identity information for principals and provides
principal authentication to service providers within a federation.
Within this document, an Identity Provider (IdP) refers to the entire set of technical mechanisms an
organization operates to manage identity information and to perform principal authentication. This
includes, but is not limited to, the organization’s Shibboleth Identity Provider.
1.3.2 Identity Registry
An Identity Registry stores identity information within an IdP. It is typically the organization’s enterprise
directory. Although the Identity Registry may also describe any number of programmatic interfaces an
external entity uses to manipulate identity information.
1.3.3 Service Provider
A Service Provider provides services to principals or other system entities.
In this document, a Service Provider (SP) describes the Target Resource providing the service as well as
the Shibboleth Service Provider components the Target Resource relies on to perform federated single
sign-on.
1.3.4 Target Resource (or Application)
A Target Resource is the application providing services to principals within the federation. A Target
Resource is likely a federated web application.
1.4 Outline
Section 2 of this document describes the components comprising the UC IDM User Provisioning
Middleware.
Section 3 introduces the message flows between components of the User Provisioning Middleware.
Section 4 provides key implementation guidance to the technical implementation team tasked to develop
the UC IDM Provisioning Middleware.
Document1
7
UC IDM Provisioning Middleware: Technical Design Guide
2 UC IDM User Provisioning Middleware Components
A conforming UC IDM Provisioning Middleware implementation includes at least one Identity Provider
Provisioning Agent and one Service Provider Provisioning Agent. These components interact with existing
identity management components to replicate changes to a subject’s identity information.
SAML Change
SAMLEvents
Change
Notify
Events
Identity
Registry
Identity Provider
Identity Provider
Provisioning Agent
SAML Attribute
Query
SAML Attribue
Assertion
Service Provider
Provisioning Agent
Target
Resource
Service Provider
Figure 1: IDM Provisioning Middleware Components
2.1 Identity Provider Provisioning Agent
An Identity Provider Provisioning Agent (IdPPA) captures identity subject change events, notifies the
service provider of change events, and responds to queries to retrieve identity subject data updates. The
IdPPA consists of a collection of interrelated runtime modules, each responsible for specific tasks. These
modules may be implemented as a single executable. However, they are more likely to be implemented
as several loosely coupled runtime modules. Figure 2 illustrates the components within the Identity
Provider Provisioning Agent (IdPPA). These sub-components are discussed in the following sub-sections.
Note: The interaction between an Identity Provider Agent and external components is described in
Sections 3 and 4.
Document1
8
UC IDM Provisioning Middleware: Technical Design Guide
Identity Provider Provisioning Agent
IdPPA
Administration
Service
Attribute Authority
Change Notify Issuer
Change
Data Cache
Identity Registry Adapter
Identity Registry
SPPA
Registration Service
Attribute
Filter Policy
Shibboleth
Metadata
Shibboleth Identity Provider
Figure 2: Identity Provider Provisioning Agent Components
2.1.1 Change Notify Issuer
The Change Notify Issuer implements the SAML 2 Change Notify Protocol. It is the IdPPA’s data change
detection and signaling mechanism. The Change Notify Issuer (CNI):





Receives identity subject data changes from the Identity Registry through the Identity Registry
Adapter;
Manages pending change transactions for each registered SP Provisioning Agent;
Writes the pending change transactions to the Change Data Cache;
Composes and sends SAML Change Notify requests to registered SP Provisioning Agents at
scheduled intervals;
Process change notify responses from SP Provisioning Agents;
The CNI is one of the IdPPA interfaces to the Service Provider Provisioning Agent.
The CNI also exposes the standard change event signal interface an Identity Provider uses (via the
Identity Registry Adapter) to signal change events occurring within the Identity Provider.
Document1
9
UC IDM Provisioning Middleware: Technical Design Guide
2.1.2 Identity Registry Adapter
The Identity Registry Adapter (IRA) is a connection and signal adapter between the CNI and the Identity
Provider. The IRA provides the necessary data connection and conversion processing between IdPPA
and the Identity Registry. Because each campus has a unique identity management infrastructure, the
campuses will likely need to work with the Middleware implementation team to develop its own Identity
Registry Adapter. The Identity Registry Adapter:


Detects identity subject data change events in the Identity Provider;
Sends relevant change events to the CNI;
2.1.3 Attribute Authority
The Attribute Authority processes SAML attribute requests; that is, it issues SAML attribute assertions.
The Attribute Authority (AA) authenticates and authorizes any requests it receives via the Service
Provider Registration Service.
The AA is one of the IdPPA interfaces to the Service Provider Provisioning Agent.
The AA may retrieve attributes from either the Change Data Cache or directly from the Identity Provider.
In implementation, the AA could be a minor variation of the Shibboleth Attribute Authority in order to
maintain maximum compatibility and reuse between Shibboleth and the Provisioning Middleware.
2.1.4 Service Provider Registration Service
The Service Provider Registration Service provides location discovery, authentication and authorization
service to the CNA and the AA. The Service Provider Registration Service (SPRS):


Accesses the Identity Provider’s Shibboleth metadata and attribute filter policy to determine SP
access;
Manages the Service Provider’s provisioning metadata;
2.1.5 Change Data Cache
The Change Data Cache stores all queued identity subject change events.
2.1.6 IdPPA Administration Service
The IdPPA Administration Service provides programmatic and end user facing interfaces to monitor,
configure, and administer the IdPPA. The IdPPA Administration Service’s key responsibilities include:






Change event monitoring;
Relying Party registration and access management;
System startup and runtime settings configuration;
Change notification scheduling;
Error and transaction log viewer;
Identity Registry Adapter configuration;
Document1
10
UC IDM Provisioning Middleware: Technical Design Guide
2.2 Service Provider Provisioning Agent
A Service Provider Provisioning Agent listens for identity subject change notifications from registered
IdPPA’s, queues the change events, queries the appropriate IdPPA to retrieve the identity subject data
changes, and updates the Target Resource. Figure 3 illustrates the components within the Service
Provider Provisioning Agent (SPPA). These components are discussed in the following sub-sections.
Note: The interaction between a Service Provider Agent and external components is described in
Sections 3 and 4.
Service Provider Provisioning Agent
SPPA
Administration
Service
Attribute Requester
Change Notify Receiver
Change
Data Cache
IdPPA
Registration Service
Attribute
Acceptance
Policy
Target Resource Adapter
Shibboleth
Metadata
Target Resource (Application)
Shibboleth Service Provider
Figure 3: Service Provider Provisioning Agent Components
2.2.1 Change Notify Receiver
The Change Notify Issuer implements the SAML 2 Change Notify Protocol. It is the SPPA’s data change
receiving and response mechanism. The Change Notify Receiver (CNR):




Listens for identity subject data changes from registered IdP Provisioning Agents;
Acknowledge the receipt of identity subject change requests;
Optionally queues the change request for batched processing;
Signals the Attribute Requester to submit SAML attribute requests to update changed subject
data;
The CNR is one of the SPPA’s interfaces to the Identity Provider Provisioning Agent.
Document1
11
UC IDM Provisioning Middleware: Technical Design Guide
2.2.2 Target Resource Adapter
The Target Resource Adapter (TRA) connects to the Target Resource and pushes change data from
SPPA to the Target Resource. The Target Resource Adapter pushes data stored in the Change Data
Cache to the Target Resource at scheduled intervals.
Because each Target Resource differs in its design and implementation, there will be multiple Target
Resource Adapter implementations. The Provisioning Middleware implementation team should develop at
least the two common TRA described in section 3.3.
2.2.3 Attribute Requester
The Attribute Requester composes SAML attribute requests; that is, it issues SAML attribute requests.
The Attribute Requester (AR) also processes the returning SAML attribute responses, queues the
responses in the Change Data Cache, and schedules update to the Target Resource.
The AR is one of the SPPA’s interfaces to the Identity Provider Provisioning Agent.
2.2.4 IdPPA Registration Service
The IdPPA Registration Service provides location discovery, authentication and authorization service to
the CNR and the AR. The IdPPA Registration Service:


Accesses the Service Provider’s Shibboleth metadata to determine IdP endpoint configurations;
Manages the IdP’s provisioning configurations in addition to it’s Shibboleth configuration;
2.2.5 SPPA Administration Service
The SPPA Administration Service provides programmatic and end user facing interfaces to monitor,
configure, and administer the SPPA. The SPPA Administration Service’s key responsibilities include:






Change event monitoring;
Identity Provider registration and access management;
System startup and runtime settings configuration;
Attribute update scheduling;
Error and transaction log viewer;
Target Resource Adapter configuration;
2.2.6 Change Data Cache
The Change Data Cache stores all queued identity subject change events.
Document1
12
UC IDM Provisioning Middleware: Technical Design Guide
3 Component Interactions
3.1 Operating the Middleware in a Federated Environment
The UC IDM User Provisioning Middleware operates in a federated environment, that is, there are
multiple IdPPA and SPPA in a mature runtime environment. The IdPPA must have be ability to register
and communicate with multiple SPPA’s. Each SPPA must be able to register and communicate with
multiple IdPPA’s.
The IdPPA has the responsibility to track the SPPA it communicates with. The IdPPA manages each
SPPA’s access to the individuals’ identity data within the IdPPA’s community.
The SPPA has the responsibility to track each IdPPA it communicates with. It is also responsible for
declaring to the IdPPA (via either registration metadata or runtime declaration) the mechanism it wishes
to use to receive data.
The SPPA also has the responsibility to merge the records it receives from multiple IdPPA's. In most
cases, this “merging” is simple concatenation, but it may require algorithmic matching, when it is
necessary to detect the same person being asserted by multiple IdPPA's.
Federation
Metadata
Campus
IdP
Campus
IdP
Campus
IdP
IRA
IRA
IRA
SPPA
TRA
Campus
SP
SPPA
TRA
Campus
SP
SPPA
TRA
External
SP
SPPA
TRA
External
SP
IdPPA
IdPPA
IdPPA
●
●
Federation responsibility
Campus responsibility, to federation specs
SAML V2.0
SAML V2.0
Change Notify
Protocol V1.0
LDAP
File
● Others in future
●
●
Campus responsibility
Third-party responsibility
Figure 4: Provisioning Middleware in a Federated Environment
Document1
13
UC IDM Provisioning Middleware: Technical Design Guide
3.2 IdP Provisioning Agent to Identity Provider Interaction
The interaction between the IdPPA and the (external) Identity Provider is modeled after the SAML
Change Notify Protocol but does not actually require implementation of that protocol in the Identity
Provider. This interaction is implemented in the Identity Registry Adapter. The Identity Provider operator
must provide an implementation of the Identity Registry Adaptor. It should implement the following Java
interfaces:
// The unique identifier for individuals in the IdMS
Interface SubjectID {
};
Interface IdentityRegistryAdapter {
// Return all attributes for the individual identified by id.
// SAMLObject is provided by the Shibboleth project’s OpenSAML
// distribution.
public SAMLObject getAttributes (SubjectID id);
};
In addition, the Identity Registry Adapter listens for changes within the Identity Provider. When relevant
identity data change occurs, it invokes the following CNI interface method to let CNI know to retrieve the
updated subject data via the IRA
// Tell the IdPPA’s Change Notify Issuer that the user identified by id
has been updated.
public void IdPPACNI.signalUpdate (SubjectID id) {
};
The following diagram illustrates this interaction.
Document1
14
UC IDM Provisioning Middleware: Technical Design Guide
Identity Provider
Identity
Registry
User information Updated
IdP Provisioning Agent
Identity Registry
Adapter
Change Notify
Issuer
Listening for data change...
1. IdPPACNI.signalUpdate()
2. IdentityRegistryAdapter.getAttributes ()
3. return SAMLObject
Figure 5: Interaction between IDP and IdPPA
Note that there may be a time delay between the IdPPA calls signalUpdate() and when the SPPA calls
IdPConnector.getAttributes(). The amount of time is determined by the configuration of the SPPA and the
access method being employed between the SPPA and the IdPPA.
3.3 SP Provisioning Agent to Target Resource Interaction
The interaction between a Target Resource and the RP Provisioning Agent depends on the specific
Target Resource Adapter (TRA) selected for the Target Resource.
3.3.1 LDAP TRA
Interaction with the LDAP TRA is specified by version 3 of the LDAP protocol [LDAPv3]. Only read
access is supported.
3.3.2
CSV File TRA
The CSV File TRA is configured with the location of the CSV file and the frequency with which the file is
written to that location. Target Resources read the file from that location whenever they require an
update to their user information.
Document1
15
UC IDM Provisioning Middleware: Technical Design Guide
3.4 IdP Provisioning Agent to SP Provisioning Agent Interaction
The IdP Provisioning Agent and SP Provisioning Agent communicate with each other via the SAML V2.0
Change Notify Protocol V1.0 [SSTC-SAML2-Notify-Protocol-V1.0] to support three access methods:



Snapshot,
Subscription, and
Batched Change
The following sections describe each of these methods.
3.4.1 Snapshot Update
The Snapshot update mechanism is intended to address the following three use cases:

initial retrieval of user information when the SP is first put into service,

recovery from lost transactions or other failures of the Subscription and Change Log update
mechanisms, and

on-going update of the SP’s user information when the need for currency in that information is
low, compared to the cost of implementing either the Subscription or Change Log update
mechanisms.
In the Snapshot update mechanism, the SP initiates all transfers of user information via the Service
Provider Provisioning Agent. The SP, therefore, drives the scheduling. However, the Identity Providers
and the federation may establish service level descriptions that limit when and how often Snapshot
updates can be initiated in order to avoid overloading the Identity Providers’ ability to transmit data.
Document1
16
UC IDM Provisioning Middleware: Technical Design Guide
IdP Provisioning Agent
Change Notify
Issuer
SP Provisioning Agent
Attribute
Authority
Change Notify
Receiver
Attribute
Requester
1. Snapshot event triggered;
2. request snapshot dataset
3. return snapshot dataset
Figure 6: Snapshot Update Sequence
3.4.2 Subscription Update
The Subscription update mechanism is the preferred method for an SP to keep its user information
current, when the need for currency is not low, compared to the cost of maintaining high availability of the
SPPA (to receive the updates).
In the Subscription update mechanism, the SP initially uses the Snapshot method to initialize its user
information. The SP then uses the Subscription mechanism to receive updates that occur after the
Snapshot; the timing of those updates is driven by IdP events that affect user information that may be
needed by the SP. It is worth noting that not all updates will be of interest to the SP. It is the SP’s
responsibility to apply updates according to its requirements. The federation and the IdPs will establish
service level statements concerning any delays that may exists between the IdP events affecting user
information and when the Change Notify Issuer signals the Change Notify Receiver.
In the event of lost transactions or other failures of the Subscription mechanism, the SP will use the
Snapshot method to re-synchronize its data and then restart the Subscription mechanism.
Document1
17
UC IDM Provisioning Middleware: Technical Design Guide
IdP Provisioning Agent
Change Notify
Issuer
SP Provisioning Agent
Attribute
Authority
Change Notify
Receiver
Attribute
Requester
1. Change Event Triggered;
2. <ChangeNotifyRequest>...
3. CNR determines
response;
4. <ChangeNotifyResponse>...
5. signals change
6. SAML attribute assertion request
7. SAML attribute assertion response
Figure 7: Subscription Update Sequence
3.4.3 Batched Change Update
The Batched Change (Change Log) update mechanism is the preferred method for an SP to keep its user
information current, when the need for currency is not low, compared to the cost of maintaining high
availability of the SPPA (to receive the updates), but there are operational or technical reasons why
updates to the SP’s copy of the user information should be applied in batches according to an SP-driven
schedule.
In the Batched Change update mechanism, the SP initially uses the Snapshot method to initialize its user
information. The SP then uses the Batched Change mechanism to receive updates that occur after the
Snapshot. The timing of those updates is driven by the SP. Note: Not all updates will be of interest to the
SP; it is the SP’s responsibility to apply updates according to its requirements. The federation and the
IdPs will establish service level statements concerning any delays that may exists between the IdP events
affecting user information and when the Change Notify Issuer signals the Change Notify Receiver.
In the event of lost transactions or other failures of the Batched Change mechanism, the SP will use the
Snapshot method to re-synchronize its data and then restart the Batched Change mechanism.
Document1
18
UC IDM Provisioning Middleware: Technical Design Guide
IdP Provisioning Agent
Change Notify
Issuer
SP Provisioning Agent
Attribute
Authority
Change Notify
Receiver
Attribute
Requester
1. Change Event Triggered;
2. <ChangeNotifyRequest>...
3. add to queue;
4. <ChangeNotifyResponse>...
5. ---- time passes ----
6. batched SAML attribute assertion request
7. SAML attribute assertion response
Figure 8: Batched Change (Change Log) Update Sequence
Document1
19
UC IDM Provisioning Middleware: Technical Design Guide
4 Implementation Guideline
This section contains specific implementation guidance and reminders to the implementation team. It is
not meant to be a normative specification. The implementation teams should make every effort to
understand the statements within this section and proactively seek clarification from the document
authors.
4.1 Implementation Responsibilities
Developing, deploying, and operating the UC IDM User Provisioning Middleware is a collaborative effort.
In order for the middleware to succeed, entities within UC need to work closely together. The key entities
are:
UCTrust – UCTrust is the University of California’s identity federation. It 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 (Resource Providers) throughout the UC system. UCTrust is based
on industry standard technologies and a common set of identity attributes and identity management
practices.
UC IDM User Provisioning Middleware Team – The UC IDM Provisioning Middleware Team is the
implementation team (to be formed) responsible for developing the bulk of the UC IDM User Provisioning
Middleware.
Identity Provider Team – The Identity Provider Team refers to each UC organization operating its
Identity Management System, including Shibboleth.
Service Provider Team – The Service Provider Team refers to the UC or vendor application team
responsible for the development and/or operations of an UC federated application.
4.1.1 UCTrust’s Responsibility
The UCTrust federation is responsible for:



The on-going development and maintenance of UC federated identity management policies and
practices;
Coordinate the deployment of the Provisioning Middleware across UC;
Coordinating, collecting, and proposing future Provisioning Middleware feature enhancements;
4.1.2 The UC IDM User Provisioning Team’s Responsibility
The Provisioning Middleware Team needs to:

Design and publish detailed IdP Provisioning agent component interfaces:
o Identity Register Adapter interface;
o The Change Notify Issuer;
o The Attribute Authority;
o The Change Data Cache;
Document1
20
UC IDM Provisioning Middleware: Technical Design Guide





o The SP Registration Service;
o The IdPPA Administration Service;
Deliver production implementation of the following IdP Provisioning Agent components:
o The Change Notify Issuer;
o The Attribute Authority;
o The Change Data Cache
o The SP Registration Service
o The IdPPA Administration Service
Assist each UC Identity Provider team with:
o The development and deployment of the appropriate Identity Registry Adapter;
o The configuration and deployment of the IdPPA at each UC location;
Design and publish SP Provisioning agent component programmatic interfaces:
o The Target Resource Adapter interface;
o The Change Notify Receiver;
o The Attribute Requester;
o The Change Data Cache;
o The IdP Registration Service;
o The SPPA Administration Service;
Deliver production implementation of the following SP Provisioning Agent components:
o Two reference Target Resource Adapter implementations:
 LDAPTargetResourceAdapter;
 FileTargetResourceAdapter;
o The Change Notify Receiver;
o The Attribute Requester;
o The Change Data Cache;
o The IdP Registration Service;
o The SPPA Administration Service;
Demonstrate the successful deployment and operation of the UC IDM User Provisioning
Middleware among at least two UC Identity Providers and three Service Providers;
4.1.3 The Identity Provider Team’s Responsibility
Each Identity Provider Team needs to:
o
o
o
o
o
Understand the Provisioning Middleware’s implementation requirements;
Work with ITLC and its CIO to develop funding and implementation plan;
Secure the appropriate development resources to develop the IdP-specific Identity Registry
Adapter;
Work with the Provisioning Middleware team to integrate the Provisioning Middleware with its
Identity Management operations;
Work with any applicable federated Service Providers to provision user identity data via the
Provisioning Middleware;
4.1.4 The Service Provider Team’s Responsibility
Each Service Provider Team needs to:
o
Understand the Provisioning Middleware’s implementation requirements;
Document1
21
UC IDM Provisioning Middleware: Technical Design Guide
o
o
o
Deploy and operate the SP Provisioning Agent for its Target Resource;
Optionally develop custom Target Resource Adapters if neither reference adapters work for its
Target Resource;
Work with UC Identity Providers to provision user identity data via the Provisioning Middleware;
4.2 Implementation Technology
4.2.1
The UC IDM User Provisioning Middleware Should Be Implemented in Java.
The UC IDM User Provisioning Middleware is designed to work with SAML 2 compliant Identity Providers
and Service Providers. Within UC, Shibboleth is the standard federated SAML SSO implementation.
The implementers of this document’s design should leverage the same Java implemented
Shibboleth/SAML code whenever appropriate.
Furthermore, a Java-written solution is easier to deploy across multiple operating systems.
Finally, it is anticipated that IdPOs will operate SPPAs as a service on behalf of SPs. The choice to
implement the UC IDM User Provisioning Middleware in Java aligns with the fact that the Shibboleth IdP
is also implemented in Java.
4.2.2 Data within and exchanged with the UC IDM User Provisioning Middleware
must meet specific authentication, authorization, and encryption requirements.
4.2.2.1
The IdP Provisioning Agent must authenticate all data request to ensure that only a
registered SP Provisioning Agent may connect;
We assume that authentication will be done in the same manner an Shibboleth IdP authenticates attribute
requests from an Shibboleth SP.
4.2.2.2
When responding, the IDP Provisioning Agent must ensure that it only returns data a
registered SPPA is authorized to access;
We assume that data authorization control will be done in the same manner an Shibboleth IdP filters
attribute responses.
4.2.2.3
The SP Provisioning Agent must authenticate all change notify requests to ensure that
only a registered IdP Provisioning Agent may connect;
We assume that authentication will be done in the same manner an Shibboleth IdP authenticates attribute
requests from an Shibboleth SP.
4.2.2.4
All communication between an IdP Provisioning Agent and a SP Provisioning must be
encrypted;
We assume that encryption between an IdPPA and a SPPA will reuse the same encryption mechanism
used between a Shibboleth IDP and a Shibboleth SP.
Document1
22
UC IDM Provisioning Middleware: Technical Design Guide
4.2.2.5
While at rest, data managed by the Provisioning Middleware should be appropriately
protected from unauthorized access.
The information managed by the Provisioning Middleware is likely sensitive and must be protected from
unauthorized access. The Provisioning Middleware Team must evaluate each data store’s (e.g., the
change data cache, the file generated by the FileTargetResourceAdapter, etc.) technical capabilities and
recommend the appropriate encryption and/or access control mechanism.
4.2.2.6
The IdP Provisioning Agent must authenticate all data change events to ensure that
only the registered Identity Provider may connect;
To avoid an unauthorized agent from injecting illegal data change events, the IdPPA must authenticate
data change events from its Identity Provider. The authentication mechanism used must be at least as
strong as the one used between the IdPPA and the SPPA.
4.2.2.7
All user identity data exchange between an IdP Provisioning Agent and its Identity
Provider should be encrypted;
If the Identity Provisioning Agent will be exchanging user identity data with its Identity Provider over a
network, the exchange must be encrypted. This means that the Provisioning Middleware team must
implement the appropriate encryption mechanism so that the identity management operators can enable
it at runtime.
4.2.2.8
All user identity data exchange between an SP Provisioning Agent and its Service
Provider should be encrypted;
If the SP Provisioning Agent will be exchanging user identity data with its Identity Provider over a network,
the exchange must be encrypted. This means that the Provisioning Middleware team must implement the
appropriate encryption mechanism so that the service provider operators can enable it at runtime.
4.3 Identity Provider Provisioning Agent
4.3.1 Design Directives
4.3.1.1
The Identity Provider operators are members of the development team.
To accommodate the uniquely different data management practices and technical architecture its
campus, the IdMS implementation at each UC differs significantly from one and the other. These
differences make creating a generically installable IdPPA impractical. Therefore, we expect that each UC
Identity Provider operator will contribute technical resources to assist in the development of the
integration components between the IdPPA and its campus IdMS infrastructure.
Document1
23
UC IDM Provisioning Middleware: Technical Design Guide
4.3.1.2
The IdP Provisioning Agent extends an organization’s existing Identity Provider
implementation. It does not replace it.
The Provisioning Middleware’s design can be potentially generalized to perform additional data replication
and provisioning tasks within an identity provider’s infrastructure. That work is beyond the scope of this
project. Any modification made to the internals of the Identity Provider’s infrastructure while integrating
and/or deploying the IdPPA is the sole responsibility of the Identity Provider team. The Implementation
team and the Identity Provider operators MUST exclude any requirements to replace any portion of
existing Identity Provider infrastructure from the scope of this project.
4.3.1.3
The IdP Provisioning Agent relies on the IdP to consolidate identity information from
multiple sources.
The Identity Provider SHOULD consolidate identity information in the Identity Registry prior to interfacing
with the IdP Provisioning Agent. Managing multiple identity data sources on the IDP side is beyond the
scope of the IdPPA’s implementation.
4.3.1.4
The IdP Provisioning Agent SHOULD be able to run on separate machines from the
Identity Provider.
The IdPPA retrieves data from the Identity Provider. However, it should not necessarily be required to run
on the same machine or network as the Identity Provider services.
4.3.1.5
The IdP Provisioning Agent MUST be able to run in a high availability configuration.
The IdPPA is a part of a mission critical service. The software must be designed from the ground up to
run in a 24/7, uninterrupted, and redundant configuration.
However, it should also be able to run in a single, standalone mode.
4.3.1.6
The IdP Provisioning Agent SHOULD use the IdP’s Shibboleth metadata and attribute
filter policy to manage a Service Provider’s access to subject identity data.
A key design principle of this Provisioning Middleware is to leverage the investments UC has made in its
federated identity management framework. A central component of that is the UCTrust federation and the
adoption of Shibboleth as its federated single sign-on service. This Shibboleth infrastructure has already
generated a substantial amount of service provider metadata. This project should build on that effort by
extending it where appropriate. It should not duplicate any work already done in Shibboleth unless there
is proper technical justification.
4.3.1.7
Expect to track multiple SP’s
Each IdPPA will have to provision data to an unknown number (potentially quite large number) of Service
Providers. The IdPPA’s design should allow its operator to easily configure and manage a large number
of authorized SP’s without any interruption to the service.
4.3.2 Target Resource Adapter Implementation
There will be two initial Target Resource Adapters (TRAs) provided as part of the UC IDM User
Provisioning Middleware,
Document1
24
UC IDM Provisioning Middleware: Technical Design Guide


LDAP - The LDAP TRA will implement a read-only LDAP server containing the users and
attributes required by the SP.
o
The OIDs used to identify attributes will be those defined by the federation, or others
mutually agreed upon by the SP and affected IdPs.
o
The user entries will be created under a top-level branch of the server’s directory tree
called People.
CSV File - The CSV File TRA will provide user information in a “CSV” file format.
o
The first record in the file will contain the OIDs of the attributes provided for each user,
and the user information itself will follow, one record per user. All non-numeric values will
be enclosed in quotes.
o
The OIDs used to identify attributes will be those defined by the federation, or others
mutually agreed upon by the SP and affected IdPs.
o
When there are multi-valued attributes, the maximum number of occurrences of those
attributes will be defined by the federation, or by mutual agreement between the SP and
affected IdPs.
Both TRAs can be configured for the update mechanism (Snapshot, Subscription, Batched Change) they
will use in interactions with IdPs. It should be noted, however, that neither of these methods include a
mechanism for signaling the SP when changes occur. They simply provide the most current information
available to the SPPA.
4.3.3 Interacting with the SP Provisioning Agent
The general interaction pattern between the IdPPA and the SPPA is described in sections 3.1 and 3.4.
In addition, the IdPPA implementation team should ensure that the IdPPA is fault tolerant and is arbitrarily
scalable to handle extreme transaction loads. In other words, the IdPPA’s software design should allow it
to run in a clustered configuration out of the box.
4.4 Service Provider Provisioning Agent
4.4.1 Design Directives
4.4.1.1
Service Provider operators are product consumers (end users).
Service Provider operators are often administrators of purchased applications. They should not be
expected to know the inner workings of your software. When designing the Service Provider Provisioning
Agent, provide user interfaces that a non-developer can use with ease. Intuitive graphical user interface
with context sensitive help are very welcomed features.
4.4.1.2
Minimize SP’s need to develop custom integration code.
There are many more Service Providers than Identity Providers. Service Provider operators are not
identity management specialists. They should not have to write custom integration code to consume
provisioning data from the Identity Provider. When designing the Service Provider Provisioning Agent,
Document1
25
UC IDM Provisioning Middleware: Technical Design Guide
make every effort to design for easy and flexible runtime configuration. Make effort to provide as many
common Target Resource Adapters as time and resource allows during implementation.
4.4.1.3
Design for hassle-free installation and operation.
Service Provider operators are not likely to be developers. Make your software easy to install and
operate.
4.4.1.4
Expect to track/manage multiple IdP’s
The SPPA operates in a federated environment, that is, it consumes data from multiple Identity Providers.
Make sure the SPPA has the ability to easily manage and track all IdP/IdPPAs it interacts with. Make sure
the operators can configure and manage these relationships at runtime without having to restart services.
4.4.1.5
The SPPA must be able to run remotely from its Target Resource
The SPPA is an intermediary between an IdP and a SP. Specifically, it collects and organizes provisioned
data on the SP’s behalf and make it easy for SP to consume. However, the SPPA may not run on the
same hardware or network as the SP. In fact, a 3rd party may operate the SPPA on the SP’s behalf. The
implementation team should take this operating requirement into consideration when designing the SPPA.
4.4.2 Interacting with the Target Resource
4.4.2.1
Implement at least the CSV File and LDAP Target Resource Adapters
CSV file and LDAP are two of the most popular formats SPs use to consume provisioning data. To
minimize the SP operator’s need to perform custom integration, the Provisioning Middleware
implementation team should develop at least these two Target Resource Adapters. Time and resource
permitting, the implementation team should develop additional Target Resource Adapters for commonly
used data integration formats (e.g., SQLTargetResourceAdapter).
4.4.2.2
The Target Resource Adapter must be configurable in such a way that it can transform
and integrate different file and database table formats without programming.
SP’s have different file, schema, and database designs. When implementing a Target Resource Adapter,
the TRA must allow its operator to configure it to work with a wide variety of file and database formats at
runtime.
4.4.2.3
Expose a robust Target Resource Adapter Interface to simplify the creation of other
custom Target Resource Adapters.
4.4.2.4
For the CSV File TRA, the files must be cryptographically signed and encrypted to
ensure authenticity of the SP Provisioning Agent and the Target Resource.
Encrypting and signing data files addresses the requirement for encryption and signing of communication
among and with UC IDM User Provisioning Middleware components.
Document1
26
UC IDM Provisioning Middleware: Technical Design Guide
4.4.3 Interacting with the IDP Provisioning Agent
The general interaction pattern between the IdPPA and the SPPA is described in sections 3.1 and 3.4.
The SP implementation team should ensure that the SPPA is fault tolerant and is arbitrarily scalable to
handle extreme transaction loads. In other words, the SPPA software design should allow it to run in a
clustered configuration out of the box.
Document1
27
UC IDM Provisioning Middleware: Technical Design Guide
5 References
[SSTC-SAML2-Notify-Protocol-V1.0] SAML V2.0 Change Notify Protocol Version 1.0. 22 February
2011. OASIS Committee Specification Public Review Draft 01. http://docs.oasisopen.org/security/saml/Post2.0/sstc-saml2-notify-protocol/v1.0/csprd01/sstc-saml2-notify-protocol-v1.0csprd01.odt
[SAML2Bind] OASIS Standard, Bindings for the OASIS Security Association Markup Language (SAML)
V2.0. March 2005.http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
[SAML2Core] OASIS Standard, Assertions and Protocols for the OASIS Security Assertion Markup
Language (SAML) V2.0.March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[SAML2Meta] S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML)
V2.0. OASIS SSTC, March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
[SAML2Prof] OASIS Standard, Profiles for the OASIS Security Assertion Markup Language
(SAML) V2.0. March 2005.http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
[SAML2Gloss] OASIS Standard, Glossary for the OASIS Security Assertion Markup Language (SAML)
V2.0. March 2005. http://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.html
[LDAPv3] Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map (RFC 4510).
http://tools.ietf.org/html/rfc4510
Document1
28
UC IDM Provisioning Middleware: Technical Design Guide
6 Document History
Revision 05....... 7/23/2011 .....................................................................complete draft for workgroup review
Revision 06....... 7/30/2011 ............ amend document to conceptual design; edits from Walker, Allen, Bruno
Revision 07....... 8/1/2011 ............................................................................................edits from Allen, Bruno
Document1
29