...
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. | 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 students.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. |
...
Other Attributes
Optional Attributes
These are optional attributes that can be sent by the college. There may be a few services that would use these attributes if available. One example use is that these can be used to pre-populate values when the user is required to create a central CCCID account.
...