User Provisioning Detail Design Working Session - 1/28/11 9am-4pm Franklin St,
Rm 6113
ATTENDEES
Invited Attendees: Attendees: Mary Doyle; David Walker; Wu, Albert; Dedra Chamberlin; Mahabalagiri, Datta;
Merriweather, Anthony; Benn Oshrin; Jeff McCullough; Arlene Allen; Chet Burgess
Attendees Absent: Not applicable
Guests: Not applicable
INTRODUCTION, ANNOUNCEMENTS, AND AGENDA REVIEW
High Level Design Working Session:
 Meeting Purpose and Outcome
 User Provisioning Background
 User Provisioning to Date
 User Provisioning Working Design Session
AGENDA ITEMS
Item
Presenter
Notes
Meeting Purpose and Outcome
Team
Meeting Purpose:
Kick off of User Provisioning Detail Design
Meeting Outcome:
 New team members obtain overview of Detail Design
 Detail Design members have enough information to start
Detail Design
User Provisioning Background
Team
UC ITLC is sponsoring a common UC Middleware to provide an
architecture/approach that enables UC to more optimally leverage system wide
information technology resources while still addressing campus specific
operational differences and cultures. Common Middleware provides a common
tool set to facilitate sharing applications and services between campuses,
promotes interoperability, creates opportunities for re-use, and provides
opportunities for campuses to act as ASPs, thus lowers costs in time, effort and
resources both centrally and locally. The goals specific to this project are: A
Pilot/Proof of concept operationalization of common UC Middleware and a
White Paper with recommendation for common UC Middleware standards
going forward.
User Provisioning has been selected as the proof of concept project for the
ITLC Middleware Project. UCTrust federates authentication and identity
information during a session. Many applications need information about their
users at other times (e.g., Connexxus, SumTotal. We are extending UCTrust to
exchange identity information when the user is not online. This was a pain point
for SumTotal and Connexxus, among other UC-wide projects.
Author: Dede Bruno, UCOP – IT Project Office
Page 1 of 4
Date: 7/29/2017
Item
User Provisioning to Date
Presenter
Team
Notes




User Provisioning Working
Design Session
Team













Author: Dede Bruno, UCOP – IT Project Office
High Level Design, including use cases, service provider design, IAM
provider notes and observations and thoughts about interchange
formats completed, submitted to ITAG & UCTrust for input and
validation - 8/24/10 Completed
Identify potential candidates for User Provisioning/Middleware
project – 9/14/10 Completed
Present Proposal for User Provisioning/UC Wide ITLC Middleware
Project for ITLC – 9/28/10 Completed
Complete Phase 1 of Project - 9/30/10 - Completed
The scope of the design is currently limited to within the UC system,
although future Co-Manage cross institutional user provisioning may
be a consideration.
Design should have the ability to run as service centrally or on
separate instances by location
An asynchronous queue/service bus should be assumed for the design
Should there be a single pipe or multiple pipes? Multiple pipes but
transparent.
The complete solution should be SP dependent
The targeted id should be unique IDP/SP pair persistent
There should be one place for the SP to obtain and negotiate the data
with the authoritative source (Identity Manager at each location)
Management of membership in groups should be maintained locally,
although it could be maintained centrally and the person/group
responsible for that management would need to have access to
identity data at different locations.
The architectural design should be sufficiently detailed that each
location could build it and develop something that could be used in
Production at each location.
The IDP should provide enough for the SP to compute an ID, for
example the same person can have multiple IDs. There is no realistic
way for the IDP to do a match on id when the same person has IDs
at other locations.
The implementation of the design should be hosted and run like
Shibboleth
A unique ID across locations could assist in future ERP systems. This
design is not intended to address this requirement..
The design should include an event detector (as currently at UCSB)
to identify and accommodate change notification via multiple and/or
different methods:
 Snapshot. All identity information allowed by the attribute
release policy will be transmitted to the application for all
members.
 Subscription. Identity information will be transmitted to the
application as add, delete, and update transactions on an eventdriven basis. The transactions sent will be those that have
occurred (or will occur) since the last Snapshot, Subscription, or
Change Log access by the SP.
 Change Log. All add, delete, and update transactions that have
been generated since the last Snapshot, Subscription, or Change
Log access will be transmitted.
 SSO Event. Identity information about the current user is
transmitted at the start of a session. This is the existing
Shibboleth access type.
Page 2 of 4
Date: 7/29/2017
Item
Presenter
Next Steps
Team
Notes

Potential Pilots as of now:
o Service Now
 Starting to be deployed at additional campuses.
 We can leverage high level design Use Cases
created.
o Migration of UCSB financial applications to UCLA

We can leverage high level design use cases
already created (UCLA Administrative
Applications).
o Co Manage – Note this spans multiple institutions (includes
institutions outside of the UC system) and could increase
scope and lengthen the project.

Provide 1 page flow diagram and high level overview – 2/3 Benn
(completed) and Datta
Reach out to Tom Zeller and Chad La Joie re Shibboleth and
federated provisioning 2/11 Benn
Prepare update of Detail Design status as of 3/17 to assist Mary in
preparation for her presentation to the ITLC. This will include an
assessment of the work in progress of the following elements:
o Detail Design
o Use Cases
o Attributes
o Recommendations for pilot project
o Timeline for pilot project
o Next estimate for potential costs/resources
Mary to present update at ITLC 3/24
Complete Detail Design 4/15




DECISIONS




Leverage Shibboleth
Provide standard method to deliver data as well as standard implementation
Assume that roles and responsibilities are the same as UCTrust
P2 Implemented Pilot Project Deliverables Include:
o Establish methods for implementation
o IDP side solution that can deliver a number of data mechanisms common enough for most
SP to consume readily.
o Establish UC standard data interface
o Define set of data, how to define new elements, define dynamically – how to maintain
process/best practice, data dictionary
o SP implementation guide (conceptual)
o IM implementation guide (specific)
o Business Standard (process and standards for maintenance post implementation)
ACTION ITEMS
List action items including item, person the item is assigned to, and the expected completion date.
Author: Dede Bruno, UCOP – IT Project Office
Page 3 of 4
Date: 7/29/2017
Action Item
Provide User Provisioning 1 page flow diagram
Provide User Provisioning 1 page Overview
Author: Dede Bruno, UCOP – IT Project Office
Assigned to
Completion
Date
Benn
2/4
Datta/Tony/Albert
Page 4 of 4
2/4
Date: 7/29/2017