Dynamic Authorization and DevOps

Joffry Ferrater   ·   Thursday, December 20th, 2018

Dynamic Authorization and DevOps work well together. I’ll give a quick overview of the process and then share a few things specific to Axiomatics dynamic authorization and the move to DevSecOps.
DevOps defines the process between development and IT for efficient collaboration to build, test and release software. These processes are improving the reliability and speed to get software to market.
Continuous Integration (CI) is the practice that development teams follow where small incremental changes are implemented, and with that code checked in to a code repository on a very frequent basis, which reduces the risk of large changes that are difficult to troubleshoot and handle.
As of late, the DevOps process has changed to also include the Security team in the process. We’re hearing of the evolution of the concept “DevSecOps”, which makes sure the security aspects of the architecture, application and code is not an afterthought and is fully integrated in the development flow from the very beginning.

Axiomatics from a DevSecOps perspective

Axiomatics Services Manager (ASM) exposes a rich management API that allows for full automation of procedures in the DevSecOps pipeline. These automations can be broken up in two categories:

Installation and deployment

This is where actions related to getting the environment deployed would be executed. An important distinction here is that these actions are not related to getting the underlying environment deployed. Things like installing Java, application container, etc. That also needs to be handled but is outside the scope of this post. Here we are talking about Axiomatics Services Manager (ASM) and Policy Decision Point (PDP) configuration-specific actions that need to take place as part of an automated deployment. Examples:

• Create a Project inside of ASM
• Create one or more Authorization Domains (DEV, QA, PROD)
• Have the PDP retrieve a Registration Package from ASM
• Assign the PDP to the previously created Domain
• Enable the Axiomatics Reverse Query (ARQ) on the Domain
• Make the PDP active and managed in ASM

Ongoing configuration management

These are activities related to the ongoing management and configuration of the authorization environment. Examples:

• Deploy policy – Example scenario is when policy is authored in ALFA and needs to be deployed to a PDP
• Create Attribute
• Create or modify Policy Information Point (PIP) configuration
• Promote policy from one Domain to another (DEV->QA->PROD)
• Move PIP configurations from one Domain to another (DEV->QA->PROD)
• Make PDP unmanaged (version upgrade scenario for example)

The second category fits well into the conversation around Continuous Integration/Continuous Deployment. It is fully possible to automate the entire flow all the way from authoring an Attribute Based Access Control authorization policy in ALFA to having that policy deployed in PROD.
In addition to the automations that are allowed by the ASM management API you could automate source control of the ALFA policy files and the full check-in check-out process of that. With the latest release of ALFA (1.2) it is even possible to automate the compilation of ALFA->XACML.
With the release of the Cloud Native PDP from Axiomatics this process gets even further simplified. The Cloud Native PDP is simply a .jar file that needs to be executed and is extremely easy to containerize. This fits well in with the CI/CD process and allows for an instance of the PDP to be quickly spun up for example automated test purposes in DEV or QA and then torn down when tests are done.
All of this allows for a change to be made to a policy (or other configuration) and with almost no effort the change will be live on a DEV or QA PDP in no time. Automated regression tests can be executed against the PDP to verify all configurations are correct and that no mistakes are introduced with the change and the dev team can focus on developing a great application rather than thinking about how to configure and test the authorization.