Contributors:
Arnie Miles, Vince Timbers, Tim McGraw, Michael Gettes
The Story:
Environment:
Technical detail for accuracy: For simplicity's sake, the term Identity Provider and IdP are misused throughout this document. An IdP doesn't actually hold any data or attributes, it acts as an interface the queries data stores. Data and attributes are actually kept in the data stores. So, in this document, an Identity Provider or IdP is the entity that has the identity store and the Shibboleth Identity Provider software installed. A "participant" is any organization that provides identity provider or service provider services to the system.
For this use case, there is an Identity Provider that provides unique identifiers to every student participating in the system that are matched to a name and a username and password pair. The IdP is responsible for managing and disseminating the unique identifier. The identity provider will be a disinterested 3rd parties, selected via a process described by the policy group. This Identity Provides will be called "the IdP". The IdP will also store the fact of each identity vetting performed by the various registration authorities.
Many participants will act as registration authorities for the IdP. These participants will provide a mechanism for students to register to the IdP.
Some registration authorities will have the further responsibility of providing vetting services for the IdP. These will be registration authorities that has some reason for verifying the identity of the student. Examples include the College Board and ACT, who check identities when college entrance exams are given, or FAFSA, who does extensive vetting as part of the financial aid process. The fact of any organization vetting the identity of a student will be entered at the IdP, with only sufficient detail to prove the event happened, not the details of the event. The IdP will hold information that College Board checked a students driver's license, but will not hold the driver's license number.
All participants will maintain their own identify providers, which may or may not have another user name and password for the individual students, based upon their business needs. The participant IdP will keep "enriched" data about each student that is required for that participant's business needs. This is the value add that each participant is able to bring to the marketplace (the technical details of this process will vary from vendor to vendor, and is simplified for this discussion).
There will be a mechanism for password resets, and the information required to perform these password resets will either be stored in the IdP, or will come from a combination of attributes housed by the IdP and other participating identity providers.
Student Registration:
Whenever a student visits a participant for the first time, the student will be asked if they have an account in this system. For the purposes of the prototype the first visit will happen at either College Board or ACT, but in the wild this even may happen much earlier. It makes no difference to the final outcome, because the large majority of participants will be capable of registering students at the time of their first visit. Several things may happen when a student arrives at a registration authority for the first time.
1. They may already have credentials, and remember them, in which case the RA can direct the student to log in with these credentials and complete the local registration event. When the student logs into the system, the local RA will receive the student's unique identity, which will be entered locally and connected to all local attributes. This may or may not include creating a local user name and password, but it will certainly include entering locally useful enriched attributes about the student. Depending upon how many participants the student has already registered with and how much cooperation there is among the participants, much of the work of registering the student with this new participant will be automated.
2. They may already have credentials, and have forgotten what they are, or even forgotten they even exist. This will be by far the most difficult use case to address, because of the risk of the creation of multiple accounts. These must be a mechanism for password resets, and this mechanism must be sufficiently robust to maintain any increased level of assurance the student may have gained via vetting from other authorities, or the level of assurance must be automatically lowered as necessary. In the case of a student who does not believe they have ever enrolled, there must be a mechanism for attempting to match students to existing records, which may prove to be difficult. One element working in our favor is that a student who has already taken exams or applied for financial aid will be aware of that fact, that information can be used to direct a student to a password reset page.
3. They may have never been registered. In this case, the student will register at the local participant's portal, which will automatically touch on the IdP to gather the required unique identifier. The student will be informed that there is a 3rd party handling the identity management and will be given the opportunity to opt out. The student will create their user name and password at the portal, and will then be redirected to the participant's portal to finish the registration process.
Diagram depicting the three registration flows described:
Examples of Usage:
Aggregated attributes:
This system works based upon the ability in SAML to aggregate attributes from multiple identity providers into a single identity. This allows the central identity provider to keep the slimmest minimum amount of information about a student; a unique identifier, name, user name, password, and the facts about various vetting that has been done to verify a student's identity. This allows aggregation across multiple participants to build a picture of the student that is customized specifically to the event the student is trying to initiate. All participants that keep data about students will do so locally, and the only commonality will be the unique identifier provided by the central identity store. When a student logs in to any site using the system credentials, the fact of their successfully logging in will be attached to their unique identifier, which can be sent to one or many specific participant identity providers to harvest other attributes about the student. When this aggregated data arrives at a school, no matter where it comes from, it is all tied together by the matching identifier, solving data matching problems at the school. It also contains one or many instances of the student having had their credentials physically verified by officials of various participants, which will give the university some assurance of the quality of the identity, allowing for the provisioning of local university customized services.
The flow through the system at sign-on:
A student arrives at any site in the system, and is met with a log-in prompt. When the student provides their system credentials, the system identity provider is queried, and if the correct credentials are provided the identify provider will return the student's unique identifier, and possibly the details of any identity vetting that has been done, to the requesting party. The requesting party will then query any identity provider that is required to complete the transaction requested, providing the unique identifier provided by the system IdP. The participant IdP's can verify with the system IdP that the unique identifier was legitimately acquired, and will then return the enriched data about the student to the requesting party. The complete package of aggregated attributes can then be sent out to complete the operation.