The specification defines an architecture (see image on the right) that relates the different components that make up an XACML-based system.
This post explores a variation on the standard architecture that is better suitable for use in the cloud.
Authorization in the Cloud
Since XACML implements Attribute-Based Access Control (ABAC), we can use an attribute to indicate the tenant, and use that attribute in our policies.
We could, for instance, use the following standard attribute, which is defined in the core XACML
This identifier indicates the security domain of the subject. It identifies the administrator and policy that manages the name-space in which the subject id is administered.
Using this attribute, we can target policies to the right tenant.
Keeping Policies For Different Tenants Separate
We don’t want to mix policies for different tenants.
First of all, we don’t want a change in policy for one tenant to ever be able to affect a different tenant. Keeping those policies separate is one way to ensure that can never happen.
We can achieve the same goal by keeping all policies together and carefully writing top-level policy sets. But we are better off employing the security best practice of segmentation and keeping policies for different tenants separate in case there was a problem with those top-level policies or with the Policy Decision Point (PDP) evaluating them (defense in depth).
Multi-tenant XACML Architecture
We can use the composite pattern to implement a PDP that our cloud PEP can call.
This composite PDP will extract the tenant attribute from the request, and forward the request to a tenant-specific Context Handler/PDP/PIP/PAP system based on the value of the tenant attribute.
In the figure on the right, the composite PDP is called Multi-tenant PDP. It uses a component called Tenant-PDP Provider that is responsible for looking up the correct PDP based on the tenant attribute.
Don’t forget to share!