Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 inlcuidng including the CCC IdP Proxy.

Info
The eduPerson schema ( http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html ) has a more detailed description of many of these attributes and their intended meaning and purpose.

...

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 that , 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 important key considerations to keep in mind in considering what your college/district should use as the EPPN for each of their 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 . That distinction that 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 of to consider for choosing the campus identifier(s) to be used for your EPPN are the following:
    • s unique within your user base
    • s never re-assigned to another person
    • s 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

Minimally Required Attributes

...