Page Comparison

This page provides a description and examples of the key attributes that are needed to support and enforce appropriate access to CCC -wide services SSO federated applications 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 SSO Proxy.

Using Your College Identity to Access CCC

...

Applications and Cloud Services

...

The Importance of the EPPN: 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 Servicesapplications, which can provide services to many different institutions, having a user identifier that is "globally unique" is very advantageous. And such an

The identifier that has been defined , an identifier is called eduPersonPrincipalName, or EPPN for short. It was is 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  a globally unique federated identifier, rather than an email address. It is generally the most important attribute to be shared with federated services.

EPPN Construction

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.

...

• 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.
• Standard practice across Higher Education, InCommon, etc. is that EPPN is not an actual attribute that you store in your local directory. Instead, within your SAML Identity Provider (e.g. Shibboleth IdP, PortalGuard), you construct the EPPN by taking a campus identifier and adding the scope to it.
• 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.
• Examples could be values like jsmith@college.edu or 12345678@college.edu

The Key Link Between EPPN and Provisioning Feeds

Most Cloud Service Providers cloud service providers require the college to regularly send flat files (or sometimes have sync or realtime connections) to the Could Cloud Service Provider that identify all the users from that college that should have access to that service. The Could The Cloud Service Provider defines a set of fields that you need to fill in for each user. One of those fields will be defined to be the "user id"  for that service. That "user id" becomes the key field, the "username", for that user in the Cloud Service Provider user datastore. 

...

Here is a diagram that illustrates how this all "fits together":

Image Added

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.

...

E. IdP builds and sends the SAML response, including the EPPN.

F. CCC IdP SSO 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

...

Minimum Required Attributes

Other 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.

...