Identities
New identities are created primarily through three core mainframe applications: payroll(PPS), financial(IFIS), and student(ISIS) systems. This data may be entered via terminal emulators connected directly to the mainframe or web front ends using screen scraping, web services, etc. Some of this data is fed via file extracts into our email and Active Directory provisioning systems. All of these identities are then synchronized and merged nightly into a relational DB schema we call affiliates_db. This nightly load job also attempts to join the identities with the email and Active Directory accounts which were created separately. For certain affiliate types which are not entered into the three core systems, data can be entered from a web front end and saved directly into affiliates_db.
Identifiers
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.
Shibboleth
Our Shibboleth implementation allows users to log in either with their SSO account or with Active Directory using a tabbed interface. The available tabs can be customized depending on the needs of each application(s). This allows applications to integrate with a single API (shibboleth) and later change which authentication method(s) they support. However the user authenticates we use the associated affiliates_db record to resolve attributes.
Other Provisioning
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 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.