Planning Your Data Access Needs
Shibboleth's flexible attribute management mechanism, combined with the Enterprise Directory, enables us to offer a rich set of user attributes to applications. As
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,
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 "email@example.com". Everyone logging in via Shibboleth has a ePPN. However, ePPN for a person can, in rare cases, change over time.
eduPersonTargetedID — The 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 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
Determine the User Profile Needs
Roles, Groups, and Entitlements
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