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:
The code for the PoC-level TV-player with the necessary OAuth2 and workflow request code is available here.
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:
- 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)
- OpenAM retrieves static profile data such as the waterShedContent attribute and makes available via the ../tokeninfo end point accessible using the OAuth2 access_token
- 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
- 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
- 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.
Comments
Post a Comment