Preparing & Requesting Attributes
Who Should Read: This document is written for technical staff looking to integrate their application with Shibboleth SP 1.3 or above.
Planning Your Data Access Needs
We understand that documentation is not generally considered "fun," but it will save you time in the long run if you have a solid understanding of the process. We appreciate your continued patience and diligence. Please continue reading.
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 |
|---|
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 a 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?
Allocate enough lead time to file the data request.
In order to gain access to restricted data, campus data stewards must first approve your petition. You will be required to demonstrate the business need to access each data element you ask for. Expect a turn around time of a week for employee data requests and a month for student data.
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 trouble.
If you do need one,
| iamucla |
|---|
uclaUniveristyID — This is commonly known at UCLA as the "UID". A 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 everyone 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 means 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 |
|---|
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 attributes currently available in Shibboleth and the attributes that can be available to Shobboleth list to see which attributes are suitable for your application. These attributes are all subject to change. Note that all of these attributes are subject to privacy policy and legislation protection. You will need to petition for access to the data.
Note: If you have questions about certain attributes please contact the
team mailto:iamucla@ucla.edu. We can also try to assist you in obtaining attributes that also do not currently exists, if your application does need it.iamucla
Roles, Groups, and Entitlements
| iamucla |
|---|
Test Accounts
This will be repeated in the configuration guide.
After you have been added to our Test IdP, we will give you a test account to test if shibboleth is delivering data to you. These test accounts are not for end to end testing. You are responsible for testing the functionality of your application without shibboleth delivering real data to your application. This is normally achieved by manually feeding real user data to your application. Once you have successfully received data via shibboleth and are confident in your application's functionality, you can be given access to our Production IdP where you will receive real user data end to end.
We ask that you plan accordingly.
Moving on - Requesting Access for Data
Once you have determined your data needs, the next step is to file petitions to access data. This is mostly a process operated by the respective data stewards (e.g., the Registrar's Office for student data, Payroll Office for PPS employee data, etc.). If you need student data, you will need to file a request with the Registrar's Office here. If you need employee data, contact the
| iamucla |
|---|
Moving On
or
Contact the
| iamucla |
|---|
Planning Guide Topics
0. Get Started with Shibboleth
1. Analyze your application
2. Determine Data Needs and Submitting Data Access Requests
3. Register Your Application with IAMUCLA
4. Join the Shibboleth Support Community
5. Install and Configure Shibboleth