Cloudentity is frequently asked how our components and features align with those of the legacy XACML (eXtensible Access Control Markup Language), including Policy Administration Points (PAP), Policy Decision Points (PDP), Policy Information Points (PIP), and Policy Enforcement Points (PEP). In this article, we will describe what the Cloudentity components are and how they align with the XACML terminology as well as the decision processing between the two. Additionally, we will explain why Cloudentity's technology is superior to a solely policy engine based solution.
To get a refresher on XACML terminology, please refer to the OASIS spec page located at http://docs.oasis-open.org/xacml/3.0/errata01/os/xacml-3.0-core-spec-errata01-os-complete.html#_Toc489959470 and navigate to the Glossary section for descriptions.
First, let’s take a look at the Cloudentity Architecture
The two main components of the Cloudentity architecture are the centralized Identity and Authorization Services, which is offered via SaaS or deployed binaries and the distributed policy decision points called Authorizers, as described in the diagram below. Let's take the elements of this architecture and match them up with the corresponding XACML terminology:
Cloudentity:
- The “Policies” feature is the only place where policies can be authored and maintained, also known as the PAP. Cloudentity provides two types of policy editing environments: a graphical UI which outputs Javascript Object Notation (JSON) or YAML policy syntax or OPA editor which leverages Rego. Versioning of the policies from both options can easily be integrated with an external version control system. The Cloudentity Admin API can also be leveraged to migrate policies amongst workspaces in CI/CD recipes or playbooks, as well as cloud storage like AWS S3 buckets, Azure Files Storage, or GCP Cloud Storage.
- The "Clients" option is where client applications can be registered and maintained. It supports authorization using policies to restrict access to client applications and token minting. This is the PDP and PEP at the client application level only.
- The “Privacy and Consent Management” feature is a toggle option but acts a policy enforcement. When it is enabled, will enforce it like a PEP.
- The “Extensions” feature in allows for additional information to be injected into the authentication context and made available as claims in the minted token, either by making an API call or simply changing a value in an existing attribute. This can be viewed as the PIP, as the enriched data will be available in policies.
- Policies may contain syntax to execute external API calls to obtain additional information used to determine an authorization decision, thus policies provide PIP support.
Authorizer:
- The Authorizer is a lightweight runtime agent which enforces authorization and protects APIs either discovered by API Discovery via an API gateway or configured as standalone agent. The Authorizer consumes the policies synchronized from Cloudentity and produces an authorization decision, the API gateway receives the decision and responds back to the client either by executing the API or returning an error/forbidden response. Thus, the Authorizer acts as the PDP. The API gateway is then the PEP.
- If the Authorizer is deployed as a standalone component, it acts as a policy engine (PDP) and since the Authorizer is a runtime component, it does not provide policy authoring, which is supported in the Policies options within Cloudentity.
- If the policy to be executed by the Authorizer contains external call outs to obtain additional data for decision making, the Authorizer will also become a PIP.
Cloudentity Decision Model vs. XACML Decision Model
There are several reasons why Cloudentity's decision-making model is simpler than the XACML decision-making model. For example, Cloudentity is more forthcoming with either ALLOW or DENY, while XACML introduces three (3) layers of decisions: an individual policy decision, an aggregate policy decision, and the ultimate decision which compares the aggregate decision against the policy engine's decision criteria. Furthermore, XACML provides ALLOW, DENY, and INDETERMINATE decision outcomes. However, both Cloudentity and an XACML-based policy engine provide custom messaging to describe why an API call is being denied.
Let's consider the following scenarios to see how Cloudentity's and XACML's decision-making models compare:
- Only one condition is required to protect an API:
- Cloudentity: one policy implemented with such condition and attached to the API will produce the ultimate decision. This policy can also invoke other policies if necessary, this is the embedded policies feature inside Cloudentity’s visual policy builder.
- XACML: one policy implemented with just one condition and executed when calling the API will produce a policy decision. However, the ultimate decision is subject to the aggregate of all policies involved as well as the entire policy engine decision criteria (e.g. deny-unless-allow). Hence, since there is only one policy involved, all decisions are the same.
- Several conditions implemented in multiple policies are required to protect an API:
- Cloudentity: one policy is needed to call the required policies. The ultimate decision can be produced in said policies based on the decision from each policy being called.
- XACML: while there are several ways to achieve this, the most straightforward way would be to use a Policy Set which calls the policies. Inside the Policy Set, a decision must be produced for each policy called, then a decision needs to be in the Policy Set as the aggregate decision. However, the ultimate decision is still subject to comparing the aggregate (Policy Set decision) against the policy engine's criteria.
From these examples we are able to conclude that XACML adds levels of unneeded complexity for the end user—regardless of any sophisticated UI that may be placed in front of it. Using a complex authorization engine to model complex authorization requirements will not appeal to those who seek to simplify and provide authorization as a service for their business entities. In fact, such complexity actually reinforces company decisions to continue with their current approach, be it a homegrown or legacy entitlement system. Thus, Cloudentity differentiates by employing a simple, frictionless, and open-standards based approach to model complex fine-grained authorization requirements.
Why Cloudentity for fine-grained authorization?
We separate the PAP from the PDP and the PEP at the transaction level. The Cloudentity supports PAP and PIP functionality, while the Authorizer acts as the PDP and PEP, as well as PIP if the policy execution contains external call outs. Additionally, it is recommended to deploy the Authorizer in close proximity of either the API or an API gateway, as this will allow it to remain lightweight to churn and enforce decisions to the utmost performance.
Moreover, this separation of concern design—rather than a monolithic design—provides stability in both and the Authorizer, which in turn lowers maintenance cost and increases extensibility, thus allowing Cloudentity to release new features in an increasingly agile manner.
Not only can we perform API authorization at incredible speeds, we can also perform at scale. We have a proven throughput of 100,000s/second tokens minted by the Cloudentity Administrative Control Plane.
We are a multi-tenant, delegated admin platform with the capability to set up a platform in approximately one (1) minute. Additionally, our tenants allow for multiple workspaces to fulfill different business requirements.
Cloudentity is built on adopting and leveraging open standards like OIDC, OAuth, SPIFFE, and OPA. Thus, our technology easily integrates with existing identity providers and even data sources such as databases or LDAP via the Extensions feature.
We offer various deployment options, such as public or private SaaS, hybrid, or on-prem, and we are purposefully built to integrate easily with API gateway providers including Apigee X, AWS API Gateway, Azure APIM, Kong, Istio/Service Mesh, and more.
Cloudentity can help guide you in your authorization journey. Learn more about our Authorization as a Service and our approach to Zero Trust for APIs.