...
And remember, just because you are sending EPPN as the "user id" to a Cloud Service, and even if the Cloud Service Provider itself refers to that as the "login name", that does not mean that your users are going to have to fill in their EPPN as their Username when they login. EPPN is what we send for them, it is independent of what the user uses to login.
Attribute Summary
Minimally Required Attributes
| Simple Name and the SAMLv2 name when sent in the SAMLv2 response | Short description | Sample value(s) | Description |
|---|---|---|---|
eduPersonPrincipalName (EPPN) urn:oid:1.3.6.1.4.1.5923.1.1.1.6 | The primary federated identifier of a given user from a college/district IdP. | 12345678@college.eduImportant things to keep in mind when choosing the identifier to be used to the "left of the @" for EPPN:
| EPPN has the syntax of an email address, and might even "work" as an email address, but it should be considered really is a "globally unique federated identifier" rather than , not an email address. It is generally the most important attribute to be shared with federated services. Note that the value of EPPN does not have to match what the user fills in as their username when they login, and the user does not need to know what their EPPN is, as it is shared between the IdP and the service.EPPN is most often not an actual attribute in your directory, it is "constructed" by the IdP. Everyone from your institution should have the same "suffix" (the value to the right of the @), and that should always be the primary DNS domain of the campus. (I.e. college.edu). If the sAMAccountName has the right properties to satisfy the needed identifier, than a very typical EPPN would be "sAMAccountName@college.edu". But the identifier to the LEFT of the @ does not have to be the sAMAccountName, nor the username the user logs in with, it can be any identifier that makes the most sense for your campus, any identifier that satisfies the properties listed to the left here. And the identifier you choose to use to the "left of the @" can even be different for staff versus studentsSee the above for a much longer description of this critical attribute. |
eduPersonAffiliation
urn:oid:1.3.6.1.4.1.5923.1.1.1.1 | Role within the institution |
| All of the roles a given person has within the college, but only the values defined in the eduPerson schema are allowed for this attribute, you can't make up "new values" for it. The affiliate value identifies a person that has applied to one or more colleges but is not a student yet. This is the only attribute listed here that is intended to have multiple values. All the rest are expected to have a single value. |
eduPersonPrimaryAffiliation
urn:oid:1.3.6.1.4.1.5923.1.1.1.5 | Primary role at the institution |
| Must be one of the values specified in eduPersonAffilliation. If the eduPersonAffiliation attribute has many values, the primary affiliation should reflect the role to be associated with services that differentiate based on this value (such as the CCC Portal). For example, if the user is both a staff member and a student, and the primary affiliation is staff, the portal experience will be geared towards a staff member. |
uid urn:oid:0.9.2342.19200300.100.1.1 | Username | jsmith | This is usually the value that the user fills in as their username when they login. If you are using AD, the usual attribute you want to use to populate uid is the sAMAccountName attribute. |
givenName urn:oid:2.5.4.42 | First Name | Jane | |
sn (surname) urn:oid:2.5.4.4 | Last Name | Smith | |
displayName urn:oid:2.16.840.1.113730.3.1.241 | Full name to display | Jane Smith | |
mail (email) urn:oid:0.9.2342.19200300.100.1.3 | Email Address | jane.smith@college.edu | |
cccId
| The CCCID | The CCCID is a critical attribute for students. If not specified, but required for a portal or service action, the CCCID will be looked up via the EPPN. If no match is found, the action cannot be performed until the user creates a CCCID via the OpenCCC portlet. |
...