Released to the InAcademia customer integration platform 30th October 2020.
Merchants are urged to regression test their implemented workflow in the InAcademia Customer Integration Platform in preparation for this change that will be released to the production service on 30th November 2020.
Please refer to: https://wiki.geant.org/display/InAcademia/InAcademia+Functional+flow+with+errors for more details.
Assert idp_hint
Where a merchant's workflow utilises the IdP Hinting service, our validation response has been enhanced to assert that the user has been validated as an affiliate of the specific institution that was the subject of the request.
To receive the assertion of the requested idp_hint, the relying party (the merchant) should then request the claim 'idp_hint' in its authentication request, this example also specifies the requested idp_hint in claims:
OIDCAuthRequestParams claims={"id_token":{"idp_hint":{"value":"https://your.requested.idp/saml"}}} |
For those merchants that choose to utilise this feature, it adds a further level of assurance and can mitigate against exploitation by other users or third parties, ensuring that the user subject to the validation is not only affiliated with academia, but is affiliated with a specific institution. Please send email info@inacademia.org to request that ‘idp_hint’ is configured as an allowed claim for your client. The OIDC implementation guidelines provide more details on claims.
Attribute override
This new feature adds support for eduPersonEntitlement in specified national identity federations only, to be utilised as additional assurance. This is currently only planned for use in Sweden to denote students actively participating in the current semester.
Error: no attributes
Prior to implementing this change, the InAcademia workflow terminated outside the merchant's domain in the scenario where no attributes were received from the institution.
This implements a change that terminates InAcademia's workflow with a redirect to the merchant's client redirect URI with an error description that will also make it possible to handle these error scenarios.
For the purposes of regression testing, please refer to error scenario #9 as documented in InAcademia Functional flow with errors. Should they wish to do so, Merchants are invited to configure their workflow to respond to this new error flow, in order to ensure that users are redirected as appropriate to the scenario.
Error: affiliation does not match requested validation
Prior to implementing this change, the InAcademia workflow returned an 'Access_denied' error to the merchant's redirect URI, with the description 'no affiliation available for this user'. The implemented change amends the error description to 'affiliation does not match requested validation', allowing merchants to distinguish two differing unsuccessful validation scenarios. This change assists merchants in determining the best course of action when this error is received.
For the purposes of regression testing, please refer to error scenario #10 as documented in InAcademia Functional flow with errors. Should they wish to do so, Merchants are invited to configure their workflow to respond to this new error flow, in order to ensure that users are redirected as appropriate to the scenario.
Error: consent denied
Prior to implementing this change, the InAcademia workflow returned an 'Access_denied' error to the merchant's redirect URI, with the description 'Authentication Failed'. The implemented change amends the error description to 'User Consent Denied', allowing merchants to distinguish between unsuccessful validation scenarios. This change assists merchants in determining an appropriate course of action when this error is received. Please note that denied consent cannot and must not be used to imply affiliation with an institution: validation has failed in this scenario.
For the purposes of regression testing, please refer to error scenario #11 as documented in InAcademia Functional flow with errors. Should they wish to do so, Merchants are invited to configure their workflow to respond to this new error flow, in order to ensure that users are redirected as appropriate to the scenario.
References
The technical client implementation documentation: https://github.com/InAcademia/OIDC-implementation/wiki
Example client configuration for exiting client software: https://github.com/InAcademia/Client-docs
Implementation guidelines: