The Policy Enforcement Point (PEP)
This is the component that your application code uses, either directly or indirectly, to invoke the authorization policy evaluation.
When invoked it can be passed an AttributeValueProvider for this specific evaluation. When the PDP returns the outcome of policy evaluation the PEP will take action based on the outcome. If the outcome is Indeterminate then it will use configurable PEP Bias to determinate whether the result should be treated as Permit or Deny.
The PEP will attempt to execute any Obligations and Advice. Failure to execute an obligation is treated as an Indeterminate result and, again, PEP Bias determines the actual outcome. Any advice not executed is returned to the caller, along with the outcome of the evaluation.
You can read more about configuring the Policy Enforcement Point here.
Outcome Action Handlers
When the PDP returns an outcome to the PEP, the outcome may contain obligations and advice. The PEP must ensure all obligations can be satisfied. For each obligation it tries to resolve, it must find an OutcomeActionHandler that has been registered for that obligation type. Similarly it tries to execute any advice using the same set of registered OutcomeActionbHandlers. Enforcer ships with one out-of-the-box OutcomeActionHandler and a base class to allow you create your own for your specific business needs.
The OutcomeActionHandler that ships with Enforcer allows emails to be sent, via SMTP, when the authorization policy allows or denies access.
This base class allows you to define a class (T) with annotated properties that will be used to map the arguments for the obligation or advice. This is the simplest way to build a custom outcome action handler. See Implementing a Custom Outcome Action Handler for details.
This is a low level base class that allows you full control over extracting arguments required by your custom outcome action handler.