High Level Functional flow
Figure 1 above present the high level flow
Detailed functional flow
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
| Error | Description | Mitigation/Solution |
|---|---|---|
| Invalid Requests | When a merchant requests validation (user presses InAcademia button) the request is validated again technical correctness, as well as if it matches known configuration. See https://github.com/InAcademia/OIDC-implementation/wiki#transaction-fail for more details. If either fails, InAcademia will return an error, of either type "invalid_scope" or "unsupported_response_type". | 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 enduser in a usefull way. |
| IdP not available | InAcademia presents the user with a WAYF to allow selection of the IdP. The IdP might not be available in the list (so the IdP is not in eduGAIN) | From a technical point of view there is nothing possible to do to allow the authentication to continue. The user is however stuck at the WAYF screen of InAcademia. InAcademia might therefor offer a link where a user can ask for support to get the IdP connected - currently not yet implemented, and would require us to run our own WAYF. Alternatively InAcademia might allow a merchant to provide a link as part of the onboarding process. In this way the merchant could provide a page to resolve this as a fallback - currently not implemented, and would require us to run our own WAYF. |
| IdP not available | The IdP is available, but technically not allowing InAcademia to authenticate or the user abandons the login. | From a technical point of view there is nothing possible to do to allow the authentication to continue. This is a very hard scenario to resolve as the user (browser) is already at the IdP, and InAcademia just not receives a response. 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.This allows us to take action on problematic IdPs - currently not implemented |
| Authentication Fails | The IdP is available but, for some reason the authentication fails. Might be the user is not able to authenticate (password lost), OR the institution did not provide enough information to the InAcademia service to validate the affiliation (basically it is not releasing the affiliation attribute. | From a technical point of view there is nothing possible to do 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 usefull way. InAcademia could/should provide a test suite to allow the merchant to test all good and error scenarios - this is not yet implemented. If we do not receive affiliation we should detect this from the logs and take action to contact the IdP in question. |
| Validation Failed | 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 | In accordance with OIDC specification an "access_denied" message to the client (the merchant), see https://github.com/InAcademia/OIDC-implementation/wiki#transaction-fail. It is expected the client has sufficient support to display the error and inform the enduser in a usefull way. InAcademia could/should provide a test suite to allow the merchant to test all good and error scenarios - this is not yet implemented. |