Integration and delivery
Integrating APD into your environment means delivering the authorization domain: getting the domain you built and tested in your APD project to the ADS instances that use it. In a CI/CD pipeline, every change to policies, attributes, or attribute connectors is tested with ./gradlew test, and the tested domain is then delivered to ADS, through Authorization Hub, in a container image, or to your own storage.
Choose a delivery model
APD supports three delivery models. The right one depends on how your ADS is deployed and how often your policies change.
| Delivery model | Best for | How policy updates reach ADS | Details |
|---|---|---|---|
| Authorization Hub integration | Teams using Axiomatics Authorization Hub as a control plane | Push from APD to Authorization Hub: ADS loads the domain from Authorization Hub at start and, with refreshInterval, polls for new versions without a restart | Authorization Hub integration |
| Container image | Teams with containerized ADS and standard CI/CD pipelines | APD stages the build context: pipeline builds and pushes the image - redeployment required per change | Container image |
| Custom delivery | Teams that need policy updates without image rebuilds, using storage they already have | APD builds domain.yaml: the pipeline delivers it to a shared drive, a Kubernetes volume, a server or a repository - ADS loads the file at start and, with refreshInterval, reloads it when it changes | Custom delivery |
The delivery models can also be combined. For example, use Authorization Hub for development and test environments while using image-based deployment for production.