This page describes the functional flow and is provided to assist the design of merchant workflows in implementing the InAcademia academic validation service.
High Level Functional flow
Detailed functional flow
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
In Figure 2 this is presented in more detail. Light blue represents the merchant webshop, grey blue is InAcademia functionality. Institutional Identity provider is represented in Green.
The figure presents the 'happy' flow, ending in a successful validation, as displayed in green, as well the possible error scenarios represented in red or orange. The error situation where a institutional IdP, or teh merchant redirect URL component cannot be reached because of network issues or similar is not take into account as that is out of scope and control for InAcademia and will always yield an some error in the users browser.
Known error situations
|
| Table of Contents |
|---|
In the following diagram, light blue represents the merchant web shopIn Figure 2 this is presented in more detail. Light blue represents the merchant webshop, grey blue is InAcademia functionality. Institutional Identity provider is represented in Green.
The figure presents the 'happy' flow, ending in a successful validation, as displayed in green, as well the possible error scenarios represented in red or orange. The error situation where a institutional IdP, or teh the merchant redirect URL component cannot be reached because of network issues or similar is not take into account as that is out are out of scope and control for InAcademia and will always yield an some error in the users browser.
Operational information for merchants
There are scenarios in which merchants need to build error handling into their workflows. This table describes the scenarios and suggests mitigation. This information supplements that available in https://github.com/InAcademia/OIDC-implementation/.
...
InAcademia returns an error in conformance with the OIDC standard.
It is expected the client has sufficient support to display the error and inform the end user in a useful way.
The Merchant should configure appropriately crafted error messages to the user and should utilise the InAcademia test suite to validate all good and error scenarios.
...
From a technical point of view there is nothing that can be done inside InAcademia or the eduGAIN landscape to allow the authentication to continue.
The most appropriate mitigation is to implement idp_hinting.
...
If authentication fails, some IdPs stop the transaction. There are three potential error scenarios here:
Scenario 1– the IdP isn't available in the list or isn't functioning but hasn’t implemented SAML correctly and the process will just end as there is nowhere to go.
From a technical point of view there is nothing that can be done inside InAcademia or the eduGAIN landscape to allow the authentication to continue.
This is a challenging scenario to resolve as the user (browser) is already at the IdP, but InAcademia does not receive a response from the IdP. We can therefore not present information on the side of InAcademia.
Possible mitigation is to monitor for outgoing SAML authN request and incoming AuthN SAML responses. Normally these should match, however in this specific scenario, there will not be a response to our request.
Scenario 2 – the IdP is technically unavailable, but has implemented SAML correctly and presents an authentication failed error.
Merchants are advised to build in their own error handing workflow to mitigate these scenarios.
...
From a technical point of view there is nothing that can be done inside InAcademia or the eduGAIN landscape to allow the authentication to continue.
However, this should be signaled from the IdP with a SAML message "Access denied". InAcademia will pick up such message and send an OIDC complient "access_denied"message to the client (the merchant). It is expected the client has sufficient support to display the error and inform the enduser in a useful way.
The Merchant should configure appropriately crafted error messages to the user and should utilise the InAcademia test suite to validate all good and error scenarios.
...
Technically speaking this is not an error, as this is just a possible outcome of the validation process.
3 things may lead to failure of validation:
1) the user could not authenticate (see "Authentication Fails")
2) the user has the wrong affiliation
3) the end-user did not give consent to release the necessary information
...
- the user must complete the authentication between InAcademia and IdP withing 5 mins or we will no longer accept it as a valid response to a question
- If the user just stops/does nothing (at either WAYF, IdP or consent)/network fails/if a 443 redirect is blocked/closes browser after receiving the consent screen the process will fail.
...
If user returns to it after a period of time the session drops due to the 5-min TTL on the servers (which is necessary to avoid overload our infrastructure).
The InAcademia service is part of a continuing development programme and additional features planned for the future are also captured below.
Entry Flow with Errors v4.6.3
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Response Flow v4.6.3
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...