This page provides a description and examples of the key attributes that are needed to support and enforce appropriate access to CCC-wide services and cloud services. These are the attributes which need to be supported by college/district Identity Providers, and released to various services including the CCC IdP Proxy.
Using Your College Identity to Access CCC-wide and Cloud Services – the Importance of eduPersonPrincipalName
When your users login to services at your college/within your district, they enter a Username and a password. Most commonly that Username is matched against the sAMAccountName or the uid attribute for the user in your Active Directory or other LDAP directory. Sometimes, particularly for students, you might actually have the student enter some other student identifier as their Username. Generally, most colleges don't require their users to add a '@college.edu' type suffix when they enter their Username.
However, for CCC-wide and Cloud Services, which can provide services to many different institutions, having a user identifier that is "globally unique" is very advantageous. And such an identifier has been defined, an identifier called eduPersonPrincipalName, or EPPN for short. It was defined first as part of the eduPerson schema, linked to above. EPPN has the syntax of an email address, and might even "work" as an email address, but its purpose is to be a globally unique federated identifier, rather than an email address. It is generally the most important attribute to be shared with federated services.
The standard practice in the Higher Education community is that EPPN is constructed by taking some local campus identifier (often SAMAccountName or uid, but sometimes some other local identifier like an employee or student id number), and adding to it a suffix of the form: @college.edu. That suffix is referred to as the "scope". So the EPPN for Jane Smith, who has a sAMAccountName of jsmith, at Best Community College, which has a campus domain of bestcc.edu, will typically be jsmith@bestcc.edu. But depending on how the college manages the sAMAccountName attribute for its users, if Jane Smith has a student id of 12345678, the college might choose to make her EPPN be 12345678@bestcc.edu instead.
Here are the key considerations to keep in mind in considering what your college/district should use as the EPPN for each of your users:
- the first thing to understand is that what your users enter as their Username to login can still be anything you want it to be, continue to the same as you currently use. There is no need for the user's Username for login to be the same as their EPPN, they are completely independent.
- Standard practice across Higher Education, InCommon, etc. is that every user from the institution has the same suffix for their EPPN, everyone has the suffix @college.edu. It doesn't matter that your staff members have a different email domain than your students. That distinction might be important for email or local needs, but is not an important distinction for "cloud services". The general expectation across federated services is that every user from an institution will have the same scope (suffix) for their EPPN.
- every user from your institution needs to have a unique EPPN. Now if you manage your staff and students in two different directories, and there is a chance that the same sAMAccountName/uid can occur in both directories, then constructing EPPN by taking the sAMAccountName/uid and adding @college.edu would not necessarily result in a unique identifier for all your users. But remember, you don't have to use the sAMAccountName/uid to construct the EPPN, you could instead use the employee id or student id. Or you could use sAMAccountName/uid for staff, and student id for students, to construct the EPPN – you don't have to use the same attribute to the "left of the @" for all your users.
- the most important properties to consider for choosing the campus identifier(s) to be used for your EPPN are the following:
- unique within your user base
- never re-assigned to another person
- persistent, and never (or rarely) changes
- unique within your user base
- Examples could be values like jsmith@college.edu or 12345678@college.edu
The Key Link Between EPPN and Provisioning Feeds
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. | Important 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 a "globally unique federated identifier" rather than 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. |
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. |
Optional Attributes
These are optional attributes that can be sent by the college. One example use is that these can be used to pre-populate values when the user is required to create a central CCCID account.
Simple Name and the SAMLv2 name when sent in the SAMLv2 response | Short description | Example | values |
---|---|---|---|
cccMisCode https://www.openccc.net/saml/attributes/cccMisCode | The MIS code assigned to a college by the CCC. If a IdP is for the district, and represents multiple colleges, each with their own MIS code, the IdP could send the district MIS code as a default. | 123 | 1 |
street urn:oid:2.5.4.9 | Street address | 303 Mulberry St. | many |
locality .... urn:oid:2.5.4.7 | City | Metropolis | 1 |
st .... urn:oid:2.5.4.8 | State or Province name | CA | 1 |
postalCode .... urn:oid:2.5.4.17 | Postal or zip code | 12345 | 1 |
homePhone .... urn:oid:0.9.2342.19200300.100.1.20 | Home Phone Number | +1 212 555 1234 | 1 |
mobile .... urn:oid:0.9.2342.19200300.100.1.41 | Mobile Phone Number | +1 775 555 6789 | 1 |