Page Comparison

...

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 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 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 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 require the college to regularly send flat files (or sometimes have sync or realtime connections) to the Could Service Provider that identify all the users from that college that should have access to that service. The Could 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. 

The absolute best practice for CCC colleges to follow is to always put the user's EPPN into that "user id" field. Because the Cloud Service uses the identifier that comes from the college/district IdP to match up to that "user id" from the provisioning feed. I.e. the Cloud Service Provider is going to take the identifier you send in the SAML response, and try to find that person in their user datastore. And the identifier you send in that SAML response to the Cloud Service Provider should be that EPPN value. It will greatly simplify the support and smooth functioning of federated identity across the CCC System if all colleges and districts follow the same set of standard practices with regards to integrating with Could Services and CCC-wide Services.

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.

Minimally Required Attributes

...