...
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.
Here is a diagram that illustrates how this all "fits together":
A. College sends provisioning feed to Cloud Service Provider, making sure the "user_id" is going to match what the Shibboleth IdP will send, either the jsmith@collge.edu or 12345678@college.edu.
B. User logs in at college, to the IdP, with their Username (jsmith).
C. User record in AD/LDAP is found, password verified.
D. IdP pulls the needed attributes out of AD/LDAP for the user, including whichever identifier will be used to "construct" the EPPN. It "constructs" the EPPN by taking that identifier and adding the scope for the college to it, in this case "@college.edu".
E. IdP builds and sends the SAML response, including the EPPN.
F. CCC IdP Proxy adds the CCCID to that response if needed, and sends it on to the cloud service.
G. Cloud Service finds the user in its user database (built from the provisioning feed) by looking for the user with the EPPN it just received in the SAML response, and presents that user their information/services.
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 Primary federated identifier of a given user from a college/district IdP. |
| EPPN has the syntax of an email address, but it really is a "globally unique federated identifier", not an email address. It is generally the most important attribute to be shared with federated services. See 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. |
...