This second blog on UMA, follows on from part 1, where I looked at creating resource sets and policies on the authorization server.
Once an authorization server understands what resources are being protected and who is able to access them, the authorization server is in a position to respond to access requests from requesting parties.
A requesting party is simply an application that wants to access resources managed by the resource server.
The above diagram looks complicated at first, but it really only contains a couple of main themes.
The authorization server, responsible for the resource sets, policies and ultimately the policy decision point for evaluating the inbound request, the resource server, acting as the data custodian and the relying party - the application and end user wanting to gain access to the resources.
There are a couple of relationships to think about. Firstly, the relationship between the resource server and the authorization server. Described in the first blog, this relationship centres around an OAuth2 client and the uma_protection scope. The second relationship is between the requesting party and the authorization server. This generally centres around an OAuth2 client and the uma_authorization scope. Then of course, there are the interactions between the requesting party and the resource server. Ultimately this revolves around the use of a permission ticket, used to receive a requesting party token, which then gives the resource server the ability to introspect that token via an authorization endpoint, in order to determine whether access should be granted.
Another aspect to consider, is the verification of the end user - in this case Bob. This is currently done via an OpenID Connect JWT issued by the authorization server. This JWT is then used by the relying party when submitting a request to the AS (step 3 in the above).
A powerful component, is of course the loose coupling of the main players. All integrated using standard OAuth2 patterns for API protection.
The above use cases are all available in the nightly build of OpenAM 13. As with any nightly build, there is instability, so expect a little inconsistency in some of the flows. The draft documentation describes all the detail with respect to the flows and interactions.
Chrome's Postman REST client can be used to test the API integrations. I created a project that contains all the necessary flows that can be used as starting point for testing ForgeRock integrations.