Date: Fri, 29 Mar 2024 04:07:18 -0700 (PDT) Message-ID: <1510180499.1140.1711710438548@cms-as-p03.it.ucla.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1139_1870725499.1711710438548" ------=_Part_1139_1870725499.1711710438548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
(DRAFT - 7/25/2007)
UCTrust supports a variety of identity attributes that can be used by ap= plications as user identifiers, some of which are inherited from InCommon, and some of which are unique to= UCTrust. The most notable of these are:
The selection of which of these identifiers should be used for a particu= lar application is shown in the following table. Selection is dependent on = the application's requirements for provisioning of users prior to the first= session ("Provisioning Required?"), the application's tolerance of duplica= te identifiers for the same person ("Duplicates allowed?"), and whether the= identifier must be valid for a long time or forever ("Persistence required= ?").
Provisioning required? |
Duplicates allowed? |
Persistence required? |
Strong match possible? |
Recommended Identifier |
Example Applications |
---|---|---|---|---|---|
Y |
Y |
Y |
Y |
Kuali, Travel? |
|
Y |
Y |
Y |
HRLMS non-employees |
||
Y |
Y |
Y |
ePPN |
||
Y |
Y |
ePPN |
|||
Y |
Y |
Y |
uCnetID |
HRLMS employees |
|
Y |
Y |
Not feasible |
|||
Y |
Y |
uCnetID |
|||
Y |
Not feasible |
||||
Y |
Y |
Y |
ePTID |
||
Y |
Y |
ePTID |
Library services |
||
Y |
Y |
ePTID |
|||
Y |
ePTID |
||||
Y |
Y |
uCnetID |
AYSO |
||
Y |
Not feasible |
||||
Y |
uCnetID |
||||
Not feasible |
The "Strong match possible?" column specifies whether it is possible to = acquire SSN and date of birth from the target user community for the applic= ation (in order to assign a uCnetID).
Note that we have no recommended identifier for applications that requir= e provisioning and persistence, and we are starting to see applications tha= t require such identifiers. UC's new system-wide training management system= is a good example of such an application.
Other than uCnetID, all of the identifiers mentioned here can be very lo= ng. For example, if a UUID, which is typically written as 36 characters, we= re used for the campus part of the a scoped attribute, then the maximum len= gth of the value of that attribute for UC Berkeley would be 49 characters (= 36 for the UID, plus 13 for "@berkeley.edu"). This is longer than the maxim= um length of a user ID for many applications, and eduPersonPrincipleName ca= n be even longer.
Implementation of the University of Washington's alternate implementatio= n of eduPersonTargetedID (or waiting for it to become part of the standard = Shibboleth distribution) should give us a fairly complete set of identifier= s that can be used by applications within UCTrust, except for applications = that cannot accomodate long identifiers.
It is strongly recommended that applications be designed or modified to = accommodate identifiers of arbitrary length, at least 100 characters. A con= venient work-around to accomplish this for an existing application is to ad= d a front-end to the application's normal authentication that maps a UCTrus= t identifier to the application's native identifier.
Recognizing that migration to long identifiers will not be trivial for m= any applications, however, a new attribute, uCTrustCampusIDShort, will be a= vailable for a limited transition period, no more than five years. It will = not exceed 12 characters in length, it will contain only alphanumeric chara= cters, and its persistence will not be greater than five years. uCTru= stCampusIDShort will also have the following properties: