We know of it as a job usually done by the OpenAM Web/J2EE Policy Agent to enforce a Policy Decision sent by the Access Management Solution. To help you recollect, this is how it works:
– An End User tries to access a resource (say, a URL)
– The Web/J2EE Policy Agent deployed in the Container, intercepts the requests and redirects the request to Access Management Solution
– The Access Management Solution, first Authenticates the User, does a redirection to the the Resource (URL), where Agent would again receive it
– The Agent would now ask the Access Management Solution whether the Authenticated User has access to the Protected Resource (Authorization)
– Based on the policies defined in the Access Management Solution for the Protected Resource, it constructs a Decision and sends it back to the Agent
– Whatever the decision Agent receives from the Access Management (whether to ALLOW or DENY access to the Protected Resource), the Agent Enforces it!
The story in the video below is a bit different. In fact, the protagonist is different. The honours of Enforcing a Policy Decision sent by OpenAM is on ForgeRock OpenIG 4. As for the flow, it by and large remains what is mentioned above, just that the OpenIG uses its Route Configuration file to decide whether it should redirect the Client requests to OpenAM (should the SSO Cookie is absent in the request), ask OpenAM for Policy Decisions on Protected URLs by Authenticated Users and finally to enforce a Decision that is sent by OpenAM (whether to ALLOW or DENY access to Protected URLs).
Very roughly, here’s an illustration of the flow:
To see it in action, watch the screen-cast below. Enjoy!
– ForgeRock OpenIG Documentation
One thought on “ForgeRock OpenIG 4 As OpenAM Policy Enforcement Point”
How does “Protected Resource” obtain the authenticated username in this scenario? With a traditional agent, it might be via REMOTE_USER server variable.