The Policy Access Point (PAP)
The PAP wraps up the compiler and configured policy store to ensure that compiled policies are cached until the policy store reports that they have changed. At that time the PAP will reload the policy from the store and re-run the compiler.
As the name suggests, the Policy Store is where the definition of the authorization policy is stored. By default, Enforcers expects policy to be defined in one, or more, policy files with a .alfa extension. However, these files can be stored in one of three ways:
- On the file system
- Embedded in your appication
- In a git repository on either Azure Devops or GitHub
The File System
The file system policy store is probably the simplest to set up. You put your policy files under a single root folder and the store will ensure they are loaded when required. You do not have to keep your policy files in a single flat list, the store supports multiple folders are long as they are all under a single root. If you change the files in any way in the folder structure the policy will be automatically reloaded, allowing you to change authroization policy while the application is running.
You can read more about using the file system policy store here.
Embedded in the Application
It may be important to you that for a particular version of the application that it's authorization policy is fixed. You can achieve this my including your policy files as embedded resources within your application. All of the files must be under a single root resource directory but can have further resource folder structure under that root. The policy is loaded when requested but cannot be changed without deplopying the application.
You can read more about using the embedded policy store here.
You can store your authorization policy files in a git repository on eith er Azure Devops or GitHub. The repository is assumed to be private and you will have to provide authentication information for the policy store to be able to access it. Storing your authorization policy in git has a number of benefits:
- You can track the changes that have been made to policy over time, comparing different versions.
- You can see who made which change and at which point it became active.
- You can rollback a change that once released is discovered to be causing issues.
- You can use the platforms' Pull Request features to ensure that policy changes are reviewed before they go live.
- You can migrate policy from one environment to another, as a release is scheduled, by simply merging to a predefined branch.
For both platforms you must supply repository name, the branch that is going to contain the policy for this environment (e.g. develop, release, master) and the folder within the repository that is the root folder of the policy documents. The policy store will poll the repository at a configurable interval to see if any policy changes have been commited and, if they have, will load the new policy.
You can read more about using git to store your policy files here.
The ALFA Compiler
Enforcer ships with a compiler for the ALFA language. This means that, at runtime, your ALFA policies are turned into executable code which make policy evaluation fast and efficient. The compiler will report any compilation issues into log files so any problems can be caught and diagnosed effectively.