Technical Processes
- Participation in Building the User's Representation in the AdmitMe Ecosystem
- Attribute Gathering from the User's Representation throughout the AdmitMe Ecosystem
- Deprovisioning a User Representation from the AdmitMe Ecosystem
1. Participation in Building the User's Representation in the AdmitMe Ecosystem
In order to take advantage of AdmitMe, an individual will gradually assemble identity information at service organizations that are participants in the AdmitMe project. This identity information will be keyed by the user's central AdmitMe identifier.
First, any participant may decide to use only AdmitMe for login. Second, a participant may choose to offer both local accounts and AdmitMe for login. A third choice envisions permitting login from any InCommon member. These three strategies are described below.
In each integration strategy, there is a consistent, shared AdmitMe identifier. User information is not stored centrally, but is instead stored at each service organization.
The choice of integration strategy is the sole province of each participant, and all three strategies can co-exist. Each participant is encouraged to choose the integration strategy that best suits their needs.
Integration Strategy 1: The Service Organization Relies on AdmitMe for All Authentication
Integration strategy 1 presents a user with a single login choice: AdmitMe. This removes the need for the service organization to manage the authentication of users, a costly and time-consuming process. It also greatly simplifies the user experience.
After clicking login, the user will be sent to AdmitMe and shown the logos for all the various participants in the system, and will learn how a single system account will Federate their identity and provide single sign on to some or all of each participant's offerings. The student will create a system account at that time, and will be given the option to create identities with each participant.
Participants will only use the system credentials for authentication, and will only keep enriched participant-relevant data locally. The system will provide an identifier that is unique to the student that links all the accounts together.
Integration Strategy 2: Login through AdmitMe or through Local Credentials
This integration strategy reflects both some participant's desires to have local participant credentials and the reality that there may be a migration strategy required for participants who will eventually use Integration Strategy 1. There are 4 different flows through this strategy that are described in further detail.
Integration Strategy 3: Student has system account linked to University account, and wants to use University account to apply to other institutions
More to follow. Michael Gettes and Jim Leous
2. Attribute Gathering from the User's Representation throughout the AdmitMe Ecosystem
Attribute gathering will occur after an individual has created an AdmitMe account and associated it with identity information at participating service organizations. A service provider that needs to pull information from these service organizations can do so using the AdmitMe identifier for the individual, and may optionally leverage the AdmitMe IdP for authentication. This process is independent from and fully compatible with the integration strategies used by each service organization in building the AdmitMe representation of the individual.
Use Case C1: Attribute aggregation with single sign-on
When a student logs in to a service provider using their system credentials, they are initially directed to the system to perform authn duties. The system will verify the user's identity and return their unique identifier. The service provider will then take the unique identifier to the local identity provider, where additional 'enriched' attributes can be found.
3. Deprovisioning a User Representation from the AdmitMe Ecosystem
While not likely to be a powerful initial concern for the AdmitMe project and its participants, eventually there will need to be processes and policies in place for deprovisioning user information that is no longer needed. Because this information is stored in a highly distributed fashion, special care will need to be paid to purging it to avoid either premature deletion of parts of a user's representation, or storage of old, possibly sensative personal information. This should be coherently addressed for the AdmitMe Ecosystem, but the wide variety of data persisted at each service organization make several integration strategies a likely outcome for deprovisioning as well as identity building.
Questions:
- In Integration Strategy 2, is it possible that the participant's account creation process acquires the unique identifier and registers the student with the system even if the student does not yet get a system username and password?