...
Most of the contexts above are optional and only present if authentication or attribute resolution are performed.
Authorization
Flows are free to implement any form of security they choose, but the access control service is a convenient mechanism to use. For simple use cases involving a single access check, flows may evaluate the action expression CheckAccess to run the named policy exposed by the deployer via the flow descriptor bean (and the name of that policy can itself be derived at runtime if desired).
In addition, two beans of type Function<ProfileRequestContext,String> may be defined:
- shibboleth.AdminOperationLookupStrategy
- shibboleth.AdminResourceLookupStrategy
These functions are called to derive the operation and resource to supply to the access control decision performed by the CheckAccess action.
Event Behavior
The system as a whole follows a fairly standard pattern: flows signal the "proceed" event to allow execution to continue, and any other event will propagate into the error handling machinery of the system (this can have different effects depending on the flow, e.g. a SOAP fault, a JSON result, an error page, etc.).
It's possible to create your own events that can be handled in custom fashion by adding an appropriate <end-state> element to your flow.