User Provisioning Use Cases

User Provisioning Use Cases

Connexxus

Connexxus is a travel booking system that incorporates UC's rates negotiated with airlines, hotels, etc.  Single sign-on is implemented via UCTrust/Shibboleth, but travelers must be known to the system before a login is permitted, so all campuses produce a nightly feed that is sent to Trondent, the company that was contracted to perform the user management and authentication for Connexxus.  This process is described in System Design Issues for Connexxus.  [At Trondent's request access has been restricted to that document.  Only participating ITLC groups have been allowed access.]

Some relevant aspects of this use case:

• Anyone affiliated with a campus may, potentially, be a traveler, not just employees or students.
• Not all campuses send the same information about their travelers, although all campuses share a common file format for their feeds.
• The fact that travelers are sent to the system on a nightly basis prevents creating new travelers on demand.
• The unique key for all feeds is eduPersonPrincipleName, which provides the "join" with Shibboleth assertions at the start of online sessions with Connexxus.

The Human Resources Learning Management System (HRLMS)

The HRLMS system's initial application was compliance-related training for UC employees.  At some campuses, it has also been used for other forms of training, not necessarily for employees.  Users must be created in the HRLMS before their first login.  Basic information about employees is extracted from UCOP's copy of the campus employee records.  Campuses can add additional learners and enhance the information provided about employees by creating a nightly feed to a system at UCOP that merges all of the sources of user information and sends all users to SumTotal, the company that has been contracted to operate the HRLMS.  This is described in User Provisioning and Authentication for the SumTotal Learning Management System at the University of California.

Some relevant aspects of this use case:

• Anyone affiliated with a campus may, potentially, be a learner, not just employees or students.
• All campuses send the same information to the merge program at UCOP, in the same file format.
• The fact that learners are sent to the system on a nightly basis prevents creating new learners on demand.
• There are two options for the "join" with Shibboleth asertions, UCnetID and UCTrustCampusIDShort, because UCnetIDs are currently assigned reliably only for employees.  UCnetIDs are used for employees, and UCTrustCampusIDShort is used for others.  There is, however, a current project to allowing UCnetIDs for learners who are not employees at certain campuses.

UCLA Administrative Applications Shared by UCOP and UC Merced

UCLA operates several key administrative systems, including Financial, Purchasing, and Payroll for UCOP and UC Merced. All of these systems rely on UCLA's access management system, DACSS, to manage users. There are currently approximately 7500 users across 3 campuses using these applications. UCLA is currently in negotiation with another campus to provide administrative systems hosting.

These applications draw user data from the Payroll system and email data feeds. UCLA receives daily FTP feeds from UCOP and UC Merced to populate email address data.

Key points:

• Today, security administrators from all 3 campuses sign in to DACSS to manage user access in these applications. All of the access rules are tied to UCLA's mainframe ACF2 credentials.
• In last 2009, UCLA moved all of the involved web applications onto Shibboleth. The intent is to federate them in 2010. As these applications become federated, it brings up the question of how federated access management will work, or whether it's even desirable.
• These applications currently use UCLA mainframe's ACF2 logon ID as its use key identifier. As applications federate, and more applications are developed away from the mainframe, using ACF2 ID stops making sense. We already have several web applications that are requiring users to have a mainframe logon ID only because of this access control dependency. The problem will only grow as we move toward a shared services model.
• The current daily FTP email feed could use improvement. The merge and change detection routine is complex and error prone.

Service-now.com

Service-now.com is a popular ITIL compliant ITSM tool. It is a cloud-based, hosted solution. UCLA has adopted it as its ITSM tool, as has UCSF and several other universities. At least at UCLA, the intent is to eventually allow all IT service consumers (which pretty much means everyone at UCLA) to sign in to submit and track submitted incident tickets and service requests. Similar to LMS and Connexxus, Service-now.com receives a daily feed of employee data from UCLA, except that in Service-now.com's case, UCLA presents a LDAP interface. Service-now.com refreshes the data daily from it.

Relevant Points:

• Service-now.com supports SAML 1.1 for federated sign-on. UCLA has integrated it with its Shibboleth implementation.
• Service-now.com relies on the feed not only to populate user accounts, but also to create a search directory for Service Desk workers to look up caller information.
• The current user identifier used for record matching is eppn.
• The daily refresh is far from ideal. Not only does it prevent on-demand user provisioning and de-provisioning, the merge/change detection routine is complex and error prone. It also does not scale well as the user count grows.
• While UCLA's current deployment is bilateral, two things make this user case interesting:
  1. UCSF is also pursuing Service-now.com.
  2. Because UCLA provide administrative application hosting services for other campuses, users from other UC's will likely sign in to Service-now.com as well. We'd like to push Service-now.com to federate, but the back channel user provisioning becomes interesting.

Ethics Point

Ethics Point was deployed by UCOP in 2009 to support UC's management of "whistle blower" incidents. It has approximately 100 authorized users spread over UC's locations who manage the incidents; it also supports anonymous access for reporting incidents. Each UC location has an officially-delegated person who authorizes access for others at that campus. Since Ethics Point is already deployed, it will not participate in our project, but the use case is interesting.