A Policy Engine is software that process programs called policies in order to produce a final decision. Policies are expressed in policy languages that vary depending on the engine. Some languages are very limited in functionality, while others are Turing Complete.
In permission systems, policy engines are used to determine whether or not a subject has access to perform an action on an object. This can occur at various points during a request's lifecycle:
- early in software infrastructure such as load-balancing
- in a reverse-proxy directly in front of an application
- after an application has received a request and gathered any additional context to be used as input
Choosing between these integration points depends on what the goal of the policies are and what input data is available at each.
Policy Engines are great because they separate policy from the business logic in your application. This separation allows for much easier changes to policy than if the policy is deeply coupled to the application. A dedicated language for describing policies can also be far more succinct than a general-purpose programming language. Policies are also often pure, so they can be exhaustively tested.
Because Policy Engines are only focused on checking access to a resource, they are not full solution for solving permissions in an application. Policies can only evaluate input and compute "yes or no", so they do not efficiently answer questions such as "Who are all the people with access to this resource?" or "What are all the resources that this user can access?".
Policy Engines can only be as consistent as the input data they are provided, which often puts the task of synchronizing input data into the hands of the application developer. This could be either good or bad, depending on the design of the policy engine and the requirements of the application.