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:
- 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
The code for the PoC-level TV-player with the necessary OAuth2 and workflow request code is available here.
This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.