In flight Authorization Management

Access request, or authorization management is far from new.  The classic use case is the use of a workflow process that, via approval, updates a profile or account with a persisted attribute/group/permission in a target system.  At run time, when a user attempts to perform an action on the target system, the system locally checks the profile of the user and looks for particular attributes that have been persisted.

A slight variation on this theme, is to provide a mechanism to alter (or at least request to alter) the persisted permissions at near run time.  An example of this, is to leverage OAuth2 and use of a tokeninfo endpoint that can convert access_token scope data into scope values, that are used by resource server to handle local authorization.  Dependent on the content of the scope values, the resource server could provide a route for those persisted entries to be updated - aka an access request.

In the above example, we have a standard OAuth2 client-server relationship on the right hand side - it just so happens we're also using the device flow pin and pair paradigm that is described here. Ultimately the TV application retrieves user data using OAuth2 - one of the attributes we send back to the TV, is an attribute called waterShedContent - this is a boolean value that governs whether the user can access post 9pm TV shows or not.  If the value is false, the TV player does not allow access - but does then provide a link into OpenIDM - which can trigger a workflow to request access.

Above flow goes something like this:

1. User performs OAuth2 consent to allow the TV player access to certain profile attributes (0 is just the onboarding process for the TV via pin/pair for example)
2. OpenAM retrieves static profile data such as the waterShedContent attribute and makes available via the ../tokeninfo end point accessible using the OAuth2 access_token
3. Client interprets the data received from the ../tokeninfo endpoint to perform local authorization (if waterShedContent == true || false for example) providing a link into OpenIDM that can trigger an access request
4. The BPMN workflow in IDM searches for an approver and assigns them a basic boolean gateway workflow - either allow or deny.  An allow triggers an openidm.patch that updates the necessary attribute that is then stored in OpenDJ
5. The updated attribute is then made available via the ../tokeninfo endpoint again - perhaps via a refresh_token flow and the updated attribute is available in the client

Triggering a remote workflow (step 3) is pretty trivial - simply call /openidm/workflow/processinstance?_action=create with the necessary workflow you want to trigger.  To work out who to assign the workflow to, I leveraged the new relationship management feature of IDM and used the execution.setVariable('approver', approver) function within the workflow.  The approver was simply an attribute within my initial user object that I set when I created my managed/object.

The code for the PoC-level TV-player with the necessary OAuth2 and workflow request code is available here.