Policy-based Access Control (PBAC)

Unlike static forms of authorization, such as role-based access control (RBAC), PBAC enables you to rapidly change entitlements based on new regulations or new corporate policies without auditing and changing roles throughout the organization. This ensures assets cannot be compromised and regulations are met.

Using policies to govern authorization also empowers business owners as they can ensure data, resources, etc, are securely used as a core asset. The Axiomatics Policy Server is the centralized hub for storing and enforcing access control policies.

What is the difference between PBAC and attribute-based access control (ABAC)?

PBAC and ABAC are essentially interchangeable in that they enforce policies using attributes. The key difference in this sense is which “end” of the access control model stack you look at: policies that inform the authorization engine what to do and attributes that inform the authorization engine how to do it.

Standardized vs non-standardized

Policy-based access control from Axiomatics comes as standard with support for a standardized approach to expressing policies. Our ABAC solutions are developed in the standard-based language of eXtensible access control markup language (XACML) which has been approved by the organization for the advancement of structured information.

Policy-based access control solutions that do incorporate the ABAC model – i.e., non-standardized solutions – can expose you to vendor lock-in for authorization management.

Can PBAC be used to support large and complex organizations?

Standards-based PBAC is designed specifically to support organizations that have complex authorization requirements. Typically, larger organizations have areas of their business where roles will not suffice as a secure method for securing sensitive data. Administrating roles becomes a major drain on resources while proving virtually impossible to ensure compliance. Using policy-based authorization simplifies and strengthens organization-wide access control for developers, auditors, business owners, and IT security teams.

Key considerations for PBAC

Policy-based access control is not a quick fix. It takes time and resources to get it right, but once deployed will provide savings and deliver the data security you need.

1. Start small and expand: Unless you are starting from scratch, you will already have an advanced authorization solution in place. Ripping it all out and starting again is a major undertaking, and unrealistic for most. Identify those areas most in need of secure data sharing and deploy a solution here first. Then you can expand your policy-driven authorization solution.
2. Don’t take shortcuts: PBAC is not a silver bullet. You can’t write a policy without identifying the attributes that will be used to enforce authorization. Map your authorization requirements thoroughly according to regulations and data-sharing requirements.
3. Externalize PBAC: Keep policies in an externalized server, such as the Axiomatics Policy Server, rather than directly in an application. This will enable policies to be applied organization-wide, in databases and data lakes, application programming interfaces (APIs), and microservices, basically wherever they are required.
4. Utilize automated reporting: Regulations change, business policies change, and so do authorization needs. When authorization policies are edited you want reports to be automatically generated, otherwise you will lose control of who has access to what. An automated reporting tool can also provide data on who is accessing or has access to which data and under what conditions, should a policy rewrite be required.

Axiomatics and PBAC

No matter where your critical assets are stored or how complex or distributed your architecture is, we can help you safeguard and securely share them. Our team has experts in defining requirements and tailoring our ABAC solution to meet your policy-driven authorization needs.

FAQ

How is PBAC implemented?

PBAC is implemented through a combination of components that work together to enforce dynamic, context-aware access decisions. At the heart of PBAC is the Policy Decision Point (PDP), which evaluates access requests against a set of defined policies to determine whether access should be allowed or denied. The Policy Enforcement Point (PEP) acts on the PDP’s decision, granting or blocking access to the requested resource. Policies themselves are created and managed through a Policy Administration Point (PAP), which allows administrators to define rules based on attributes of the user, resource, action, and environmental context. Many implementations leverage standards like XACML or cloud-native policy engines, enabling fine-grained, flexible, and auditable access control without requiring hardcoded permissions in applications

How do PBAC policies differ from hardcoded permissions?

PBAC policies differ from hardcoded permissions in that they are centralized, and dynamic, rather than being fixed directly in the application code. Hardcoded permissions require developers to manually assign access rights in the program, making updates slow, error-prone, and difficult to scale. In contrast, PBAC policies are externalized and managed separately, allowing administrators to define, update, or revoke access rules without changing the underlying code. This approach also makes auditing and compliance easier because all access rules are documented and centrally controlled.