Connect SBS as external athorization engine to Engineblock

[johanib]

Introduction

SBS is a membership management portal. It allows user to define their own collaborations (rich groups), invite new users to those groups, and give this collaboration access to services.

We want to integrate this with Engineblock, such that users get access to services based on their collaboration membership (instead of IdP-SP combinations) and that extra attributes can be added from SBS.

We will add a config option in Manage coin:collab_enabled that is true for all entities for which the checkes below need to be carried out.

Changes

This means that the following changes in EB need to be made:

• Change the ValidateAllowedConnection input filter so that collab_enabled-services skip the IdP-SP check. I.e., if coin:collab_enabled is set, skip the check if the correct IdP is connected, and always allow the flow to continue.
• Add an SBSAuthorization Filter command, which makes a backchannel call to SBS to see if the user has access to the service (see below); the call will either return status=autorized and a set of attributes, or status=interrupt to indicate a redirect to SBS is required (see below).
• If the SBS call returns authorized, add the attributes sent by SBS to the Assertion
• If the SBS call returns authorized, then, after processing consent and stepup, redirect the user to SBS
• Add an "collab interrupt" route that receives the user when they get back from their SBS interrupt, fetches the attribues from SBS, and resumes the AuthN flow.

Flow and steps

The proposed flow is shown here:

Steps 1 and 2

No changes.

Step 3

TheValidateAllowedConnection input filter needs to be modified: if coin:collab_enabled is true, access should always be allowed, so no check if the IdP is connected to the SP should be performed. The other filter are unchanged.

Steps 4-9

A new input filter is introduced between AttributeAggregator and EnforcePolicy. A backend call to SBS is made using HTTP basic auth. Input is a json payload:

{
 "user_id":"[email protected]",
 "service_id":"https://entity_if_of_service",
 "issuer_id":"https://entity_id_of_authenticating_idp",
 "continue_url": "https://engineblock.openconext.nl/authentication/idp/process-collabinterrupt/c18307ded94fe10c41c5e7f296ac557699cec055dd52f76894cf75aa0b35166f"
}

Parameters are:

• user_id: an identifier for the user. eduPersonPrincipalName for SURFconext IdPs, voPersonID for eduGAIN?
• service_id: entityID or client_id of real client entity, not trusted proxy
• issuer_id: entityID of IdP
• continue_url: secret URL where to receive user where they will resume their EB journey when they get back from SBS (includes a 32 byte/64 char secret random hex string tied to this AuthN process) (see below)

SBS returns a json payload:

{
"status": {
 "result": "<authorized|interrupt|error>",
 "interrupt_url": "https://test.sram.surf.nl/interrupt?key=E0XOn6pAPqLASs3_BOatJYiKI+nWehAX66ABxCTSGCZJ",
 "message": "<USER_UNKNOWN|USER_IS_SUSPENDED|SERVICE_UNKNOWN|SERVICE_NOT_CONNECTED|NEW_FREE_RIDE_USER|MISSING_ATTRIBUTES|AUP_NOT_AGREED|SERVICE_AUP_NOT_AGREED|SECOND_FA_REQUIRED>"
 },
 "attributes": {
 "eduPersonEntitlement": ["[email protected]", "[email protected]"],
 "eduPersonPrincipalName": ["[email protected]"],
 "uid": ["test_user"],
 "sshkey": ["ssh_key1", "ssh_key2"]
 }
}

The fields are:

• result: the result of the authorization check in SBS. Three values are possible:
• error: some kind of error occurred, log the contents of message and show a generic Exception to the user
• authorised: user is allowed access, no redirect is necessary
• interrupt: user has to perform tasks in SBS, redirect the the specified redirect_url (see below)
• interrupt_url: (only if result=interrupt) url to redirect the user to, see below
• message: log message for internal use; do not show to the user
• attributes: (only if result=authorized) attributes to add to the Assertion

Steps 10-11

Process the remaining input filters (PDP and ARP), and (if applicable) Stepup.

Steps 12-15

If in Step 8 status=interrupt was received, we are redirecting the browser to the (secret) interrupt_url received from SBS. Because the URL is not guessable, SBS can be sure that the user who arrives at this endpoint is the same about whom information was exchanged in step 4.

SBS will check what exactly the user needs to do; it could simply show an error page (in which case the EB session is never resumed), or it could ask the user to agree to AUPs, perform stepup, become a member of a Collaboration, etc.

If the user is done, SBS will redirect the browser to the (secret) continue_url that was communicated by EB in step 4.

Step 16-19

We now repeat the /authz check of step 4. We expect only status=authorized now, any other status should be regarded as an error.

The returned attributes are added to the Assertion.

Steps 20-23

Process consent and the output filters en redirect the browser to the SP as usual.

Misc

Out of scope for now:

• allow exceptions for IdPs that should not be accessible using SBS
• allow either "full-IdP"-access and "per-collaboration"-access (for now, only implement that collab_enabled-SPs have access via collaboraion-memberships)

[mrvanes]

Dit is de branch met mijn SRAM interrupt experiment:
https://github.com/OpenConext/OpenConext-engineblock/tree/feature/sram-interrupt