Planning Your Data Access Needs
This page is being updated and refined - the information on it is not yet considered to be "official". Thanks for your understanding!
Shibboleth's flexible attribute management mechanism, combined with the Enterprise Directory, enables us to offer a rich set of user attributes to applications. As IAMUCLA deploys its access management services. Attributes will include user roles and entitlements as well basic identity and contact data.
Before you say, "Great! Give me everything." Consider the following:
Gaining access to data means taking on the responsibility of protecting that data.
Most of the data we can potentially release is governed by one privacy legislation or another. By getting access to the protected data, you are committing yourself and your application to comply with all applicable federal, state, and university privacy regulations. Prepare for it.
Think through the technical implications.
The more data you ask for during an Shibboleth attribute exchange, the more processing is required on both sides. This, in extreme cases, can have a significant impact on the performance of your system. Is it worth it?
Prepare for the lead time required to file the petition to gain access to data.
In order to gain access to restricted data, campus data stewards must first approve your petition. We are working with the data stewards to streamline the vetting and approval process. However, you will be required to demonstrate the business need to access each data element you ask for. Expect significant delay while the vetting is in progress and plan your project schedule accordingly.
Generally, we recommend filing your data access request before you finalize your application design.
Determining Data Needs
So, how do you determine what data you'll need? The following checklist might help:
Define your User Identifier(s)
Do you need a user identifier attribute to match the user to some back end user record? If your application doesn't care about identifying the exact individual (e.g., library content access), not asking for a user identifier can save you a lot of headaches.
If you do need one, IAMUCLA offers several possible choices. Each has advantages and disadvantages:
uclaUniversityID — This is commonly known at UCLA as the "UID". an UID is a 9 digit number issued to each UCLA student, employee, and select affiliate members such as UCOP and UC Merced employees. UID is very useful for matching records of those who have one. It is immutable. However, not every signing on with a UCLA Logon ID will have a UID.
eduPersonPrincipalName (ePPN) — The ePPN, at UCLA, is a person's UCLA Logon ID scoped by "@ucla.edu". For example, a person with the logon ID "joebruin" would have an ePPN of "joebruin@ucla.edu". Everyone logging in via Shibboleth has a ePPN. However, ePPN for a person can, in rare cases, change over time.
eduPersonTargetedID — The TargetedID is an opaque identifier designed to provide an application a mean to identify a user across sessions while preserving complete privacy of the user. A unique ID is generated for each individual per application requesting it. The TargetedID is immutable as long as the application retains the same identity. In Shibboleth, that means the application continues to use the same entityID.)
uclaPPID — The PPID is a persistent identifier uniquely identifying an entry in the Enterprise Directory. This is our unique, permanent system identifier for a record in IAMUCLA services. It is immutable and never reassigned.
Determine the User Profile Needs
"User Profile" refers to common display and contact attributes for a person such as name, email address and phone number. Check the available attributes list to see which attributes are suitable for your application. Note that all of these attributes are subject to privacy policy and legislation protection. You will need to petition to access the data.
Roles, Groups, and Entitlements
IAMUCLA currently offers a few basic role and entitlement attributes. This is the area we are actively working to grow in 2008 and 2009. We welcome your input on the types of roles and entitlement attributes you'd like to see made available.
Requesting Access for Data
Once you have determine your data needs, the next step is to file petitions to access data. This is mostly a process operated by the perspective data stewards (e.g., the Registrar's Office for student data, Payroll Office for PPS data, etc.). Contact the IAMUCLA team mailto:albertwu@ucla.edu for details.