UC IDM User Provisioning Middleware - Technical Design
Working Draft 04, July 08, 2011
Document identifier:
draft-ucitag-idmprovisioning-tech-design-04 (download Word document)
Technical Committee:
UC IT Architecture GroupUCTrust Work Group
Editors:
Albert Wu (albertwu@ucla.edu), University of California Los Angeles
Contributors:
Arlene Allen, University of California Santa Cruz
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.
Status of This Document
This is an incomplete draft document. Its content will change before completion, Please submit comments to Albert Wu (albertwu@ucla.edu).
Table of Contents
...
The UC IDM User Provisioning Middleware is built upon the following standards:
| Wiki Markup |
|---|
SAML V2.0 *\[SAML2Core\]*unmigrated-wiki-markup- SAML V2.0 Change Notify Protocol V1.0 *\[SSTC-SAML2-Notify-Protocol-V1.0\]*
Assumptions
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.
The existing UCTrust agreements, policies, processes, and technology should be leveraged as much as possible.
This design assumes that the offices currently operating the identity management implementation within each UC campus will implement the Identity Provider Provisioning Service components. Furthermore, it assumes that the same organization operates the campus's 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.
...
A conforming UC IDM Provisioning Middleware implementation includes at least one Identity Provider Provisioning Agent and one Relying Party Provisioning Agent. These components interact with existing identity management components to replicate changes to a subject's identity information.
Figure 1: IDM Provisioning Middleware Components
| Anchor |
|---|
| _Toc171484113 |
|---|
| _Toc171484113 |
|---|
|
| Anchor |
|---|
| _Toc171485591 |
|---|
| _Toc171485591 |
|---|
|
External Components
...
The following identity management components interact with the provisioning components described in this document. They are not within the scope of this design.
In addition, the SAML2 Glossary defines additional identity management related terms used throughout this document. *\[SAML2Gloss\]*
| Anchor |
|---|
| _Toc171484114 |
|---|
| _Toc171484114 |
|---|
|
| Anchor |
|---|
| _Toc171485592 |
|---|
| _Toc171485592 |
|---|
|
Identity Provider
...
An Identity Provider Provisioning Agent captures identity subject change events, notifies the relying party of change events, and responds to queries to retrieve identity subject data updates. Figure 2 illustrates the components within the Identity Provider Provisioning Agent (IdPPA). These sub-components are discussed in the following sub-sections.
| Anchor |
|---|
| _Ref171472843 |
|---|
| _Ref171472843 |
|---|
|
| Anchor |
|---|
| _Ref171472831 |
|---|
| _Ref171472831 |
|---|
|
Figure 2: Identity Provider Provisioning Agent Components| Anchor |
|---|
| _Toc171484119 |
|---|
| _Toc171484119 |
|---|
|
| Anchor |
|---|
| _Toc171485597 |
|---|
| _Toc171485597 |
|---|
|
Change Notify Issuer
...
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.
| Anchor |
|---|
| _Ref171472901 |
|---|
| _Ref171472901 |
|---|
|
Figure 3: Service Provider Provisioning Agent Components| Anchor |
|---|
| _Toc171484126 |
|---|
| _Toc171484126 |
|---|
|
| Anchor |
|---|
| _Toc171485604 |
|---|
| _Toc171485604 |
|---|
|
Change Notify Receiver
...
The interaction between a Target Resource and the RP Provisioning Agent depends on the specific Target Resource Adapter (TRA) selected for the Target Resource.
LDAP TRA
| Wiki Markup |
|---|
Interaction with the LDAP TRA is specified by version 3 of the LDAP protocol \[LDAPv3\]. Only read access is Interaction with the LDAP TRA is specified by version 3 of the LDAP protocol [LDAPv3]. Only read access is supported.
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.
...
In the Snapshot update mechanism, the SP initiates all transfers of user information via the Service Provider Provisioning Agent. The scheduling, therefore, is driven by the SP, but IdPs and the federation may establish service level descriptions that limit when and how often Snapshot updates can be initiated, because of the potential load that could be placed on the IdPs.
Figure 4: Snapshot Update Sequence
| Anchor |
|---|
| _Toc171484137 |
|---|
| _Toc171484137 |
|---|
|
| Anchor |
|---|
| _Toc171485615 |
|---|
| _Toc171485615 |
|---|
|
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. Note 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.
Figure 5: Subscription Update Sequence
| Anchor |
|---|
| _Toc171484138 |
|---|
| _Toc171484138 |
|---|
|
| Anchor |
|---|
| _Toc171485616 |
|---|
| _Toc171485616 |
|---|
|
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 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 Batched Change mechanism, the SP will use the Snapshot method to re-synchronize its data and then restart the Batched Change mechanism.
Figure 6: Batched Change(Change Log) Update Sequence
| Anchor |
|---|
| _Toc171484139 |
|---|
| _Toc171484139 |
|---|
|
| Anchor |
|---|
| _Toc171485617 |
|---|
| _Toc171485617 |
|---|
|
Implementation Guideline
...
| Anchor |
|---|
| _Toc171485630 |
|---|
| _Toc171485630 |
|---|
|
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.oasis-open.org/security/saml/Post2.0/sstc-saml2-notify-protocol/v1.0/csprd01/sstc-saml2-notify-protocol-v1.0-csprd01.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|http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf]
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4f4df42e-8a2c-4178-80bd-2a87b6fe5cf7"><ac:parameter ac:name="">Ref_SAML2Core</ac:parameter></ac:structured-macro>*\[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|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|http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf]
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7f8ddf02-6df5-4f22-ba65-7a3a6115b6c1"><ac:parameter ac:name="">Ref_SAML2Prof</ac:parameter></ac:structured-macro>*\[SAML2Prof\]* OASIS Standard, _Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0._ March 2005.[
| Anchor |
|---|
| Ref_SAML2Core |
|---|
| Ref_SAML2Core |
|---|
|
[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-profilescore-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-profilesmetadata-2.0-os.pdf]
*\[SAML2Gloss\]* OASIS Standard, _Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0_. March 2005. [http://www| Anchor |
|---|
| Ref_SAML2Prof |
|---|
| Ref_SAML2Prof |
|---|
|
[SAML2Prof] OASIS Standard, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. March 2005.http://docs.oasis-open.org/committeessecurity/saml/downloadv2.php/211110/saml-glossaryprofiles-2.0-os.html|.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]\\
\\Document History