Scoping of SAML AuthnRequests

Background

From the SAML-perspective within the OpenConext platform, the OpenConext API represents an SP. Actual SPs using the OpenConext API must be white-listed in the SAML ACL for a specific IdP, else the SPs cannot request information from the API for that IdP.

This prevents an unauthorized SP from gaining access to all personal (and group) information provided through the REST API at api.demo.openconext.org. Allowing a more open policy for accepting SPs would make it possible for any SP, known or not, to access to personal user information and also "misuse" api.demo.openconext.org for user authentication.

Solution

To enable the registration of SPs, the API uses the Scoping feature of SAML to declare 'on whose behalf' (i.e., which SP) the API performs requests, with the RequesterID element.

In this configuration, it is not longer sufficient for an IdP to just give consent to "api.demo.openconext.org". The IdP must also give consent to the SPs using OAuth to retrieve personal information through the API. To avoid tampering with the AuthnRequest, the request MUST be signed and the signature MUST be validated by IdP or proxy (in the case of OpenConext this is OpenConext-engine).

Implementation

Implementation in API

API leverages the Scoping element within the AuthnRequest, e.g.:

<saml2p:Scoping>
    <saml2p:RequesterID>https://testsp.dev.surfconext.nl/shibboleth</saml2p:RequesterID>
</saml2p:Scoping>

And API signs all AuthnRequests.

Implementation in EngineBlock

The API SP MUST have the 'redirect.sign' option set in the OpenConext-serviceregistry, which commands the Engine to require a valid signature on the AuthnRequest.

Furthermore, the EngineBlock uses any RequesterID element to reduce the IdPs available.

For security reasons this will never lead to more IdPs, so the API must have access to all IdPs that the connected SPs have access to.

Tests

Integration tests for this feature are covered by ApiConext.scoping.story on github.