Integration Strategy 2
Integration Strategy 2 allows for the use of local accounts alongside "CommIT collaborative" accounts. This may be done as a permanent integration approach, or it may be useful as a transition mechanism towards an end state of Integration Strategy 1, where only "CommIT collaborative" accounts are used at a given service.
The following scenarios describe the four processes that can occur at authentication time. Other flows, such as the aggregation of attributes about a principal from all participants in the "CommIT collaborative" ecosystem at the end stage of the application process, are out of scope for this document, which addresses only authentication.
Actors Involved in these scenarios
1. Student: S1 - In this case it is the user Annie Applicant
2. Participating Portal: P1 - It could be a Service Organization (Ex. Collegeboard, ACT, FAFSA etc) or an Application Service Organization (Aggregation portal, school system etc). A user may have local account with this organization. P1 also offers an attribute service that can be viewed as a business opportunity for P1 to contract with potential customers who are interested in retrieving valuable information about the user.
3. "CommIT collaborative" Identity Provider: IdP - "CommIT collaborative" portal that also supports central account creation UI to establish a unique identifier for the user.
1. "CommIT collaborative" Login
Annie Applicant wants to use an application service. The application service permits both login with an application service credential, or login with an "CommIT collaborative" account. Annie doesn't have a local account yet, and there's an explanation on the page that tells her about all the benefits of using "CommIT collaborative" instead of a local account. She chooses to click on the "CommIT collaborative" button and she creates a new "CommIT collaborative" account. Following account creation, she's directed back to the "CommIT collaborative" IdP to authenticate. After successfully authenticating, "CommIT collaborative" sends back an assertion describing the authentication, the verification level associated with her account, her "CommIT collaborative" identifier, and optionally a set of attributes. The application service optionally creates or loads a local representation of Annie keyed by her "CommIT collaborative" identifier which is used to store additional local data about her.
The next time Annie returns to the service, she chooses to login with "CommIT collaborative". Since she already has an account, she clicks the "CommIT collaborative" button. After successfully authenticating, "CommIT collaborative" sends back an assertion describing the authentication, the verification level associated with her account, her "CommIT collaborative" identifier, and optionally a set of attributes. The application service optionally loads the local representation of Annie.
Precondition: User wishes to access PI site via "CommIT collaborative" account
1. User may not have local account
2. The user may or may-not have "CommIT collaborative" account.
3. The user may be accessing the P1 website via "CommIT collaborative" account for the first time.
Post-condition: User has successfully accessed the P1 website via his "CommIT collaborative" account
1. User now has "CommIT collaborative" account is he didn't have one.
2. User may not have local account
3. User has already at-least once accessed P1 website via "CommIT collaborative" account.
**********************************************************************************************************************************************
2. "CommIT collaborative" Login to Local Account Creation or Association
Arnie Applicant wants to login to a standardized testing service. The testing service offers to let him login with a local account, or to use an "CommIT collaborative" account. Arnie doesn't have a local account, but Arnie recognizes that he has an "CommIT collaborative" account, and clicks on that button. He's directed back to the "CommIT collaborative" IdP to authenticate. After successfully authenticating, "CommIT collaborative" sends back an assertion describing the authentication, the verification level associated with his account, his "CommIT collaborative" identifier, and optionally a set of attributes.
The testing service checks to see whether it recognizes the "CommIT collaborative" identifier. If it recognized the identifier, it would already have an associated local account. However, it doesn't recognize the identifier. The testing service prompts Arnie to either login with his existing testing service account so that it can be associated with his "CommIT collaborative" account, or to create a new testing service account. He does so and accesses the service.
Next time Arnie comes back to the testing service, he chooses to authenticate with his local testing service account. He is prompted for authentication by the testing service. His unique "CommIT collaborative" identifier is still associated with his local account, and he is granted access to the service.
Precondition: User has already logged into P1 website via his "CommIT collaborative" account.User wishes to access a protected resource within P1 site that requires local account.
Post Conditions: User has successfully accessed the P1 protected resource that requires local account.
1. User now has local account (if he didn’t have one before)
2. User’s "CommIT collaborative" Account is now linked with his Local Account
*********************************************************************************************************************************************************
3. Local Account Login to "CommIT collaborative" Account Creation or Association
Annie Applicant wants to login to a standardized testing service. The testing service offers to let her login with a local account, or to use an "CommIT collaborative" account. Annie knows that she has a local account with the testing service that she created when she took the standardized test, and clicks on that button. She's directed to the local testing service IdP to authenticate.
After successfully authenticating, the testing service prompts her to create an "CommIT collaborative" account, or to link her testing service account to her existing "CommIT collaborative" account, explaining to her the benefits of doing so. She might also have the option of proceeding without creating an "CommIT collaborative" account.
Annie is convinced, and she clicks to be redirected back to the "CommIT collaborative" IdP. "CommIT collaborative" asks her to either authenticate if she has an existing account, or to create a new account. She either creates an account or uses an existing account. After successfully authenticating, "CommIT collaborative" sends back an assertion describing the authentication, the verification level associated with her account, her "CommIT collaborative" identifier, and optionally a set of attributes. The testing service receives the assertion and associates the unique "CommIT collaborative" identifier with her local account. It then grants her access to the service.
The next time Annie comes back to the testing service, she chooses to authenticate with her "CommIT collaborative" account. She is redirected back to the "CommIT collaborative" IdP. After successfully authenticating, "CommIT collaborative" sends back an assertion describing the authentication, the verification level associated with her account, her "CommIT collaborative" identifier, and optionally a set of attributes. The testing service associates the "CommIT collaborative" identifier with the local account keyed by her "CommIT collaborative" identifier and grants her access to the application.
Precondition: User is not logged in and it accessing a protected resource.
1. User may not have local account.
2. User may not have "CommIT collaborative" account
Post condition: User has successfully accessed the P1 protected resource via his local account
1. User now has local account if he didn’t have one
2. User may have linked his local account with his "CommIT collaborative" account.
*************************************************************************************************************************************
4. Local Account Login
Arnie Applicant wants to login to an application service. The testing service offers to let him login with a local account, or to use an "CommIT collaborative" account. Arnie just wants access to the application; he is not interested in using or learning more about "CommIT collaborative". He clicks the local login button. After successfully creating a new local account or authenticating with an existing local account, Arnie is granted access to the application.
Outstanding Questions:
1. Can one "CommIT collaborative" account be mapped to multiple accounts from a given service organization? Probably the answer is No, however the policy group need to vet this out.
2. Can one account from a service organization be mapped to multiple "CommIT collaborative" accounts?
3. Failed login at "CommIT collaborative" sends you back to "CommIT collaborative"; is that right, or should you go back to the referring service organization? How do we avoid stranding users? Where is the default place to send them for help?
4. Is an active session at "CommIT collaborative" necessary for data transmission between organizations? Beyond establishing associations, does "CommIT collaborative" have any other key role to play? Is it because organizations will trust an "CommIT collaborative" authentication, but not another authentication?
5. If a user creates multiple "CommIT collaborative" accounts, are they reconciled? If so, how?
Wireframe UI's for Sequences:
(tbd)