Page History

...

Each of the core mainframe systems has its own internal identifier which we store in affiliates_db for cross referencing.  We have an internal primary key for each person as well as a table for mapping targeted IDs to our internal ID.  Our targeted IDs are UUIDs and therefore not based on any other user attributes.  UCNETIDs are also loaded into affiliates_db from a UCOP file dump.

SSO

In order to receive a single sign-on account, employees and students must first self register using data from the payroll and student systems.  For employees, this creates a mainframe (RACF) account and links it to their (hopefully) singular affiliates_db record.  Students get a kerberos account instead of a mainframe account.  Either account is separate from the Active Directory system.

...

A handful of federated applications require periodic feed files for user provisioning and we have custom jobs designed to support these applications.  Many local applications handle their own automated provisioning using data from our data warehouse.  Other local applications are provisioned provision access manually from within.  Access to our core business applications, however, is provisioned through a central web front end by officials designated in each department (DSAs).  Department heads and their delegated DSAs are therefore responsible for all access within their own department.  Access is subject to approval by the data stewards.

Enterprise Roles

Several campus wide roles have been identified which require common access provisioning across many applications.  In order to improve efficiency and speed of provisioning we implemented a role based access model to store permissions which applications can consume for their own internal purposes.  These enterprise roles are not in wide use yet as we have many legacy applications which would need to be rewritten to support them.