About EmpowerID PBAC
Organizations today require access control systems that can enforce precise, context-aware policies across diverse applications while maintaining clear governance and auditability. Traditional Role-Based Access Control (RBAC) provides the structure needed for governance but struggles with dynamic, context-sensitive decisions. Attribute-Based Access Control (ABAC) offers runtime flexibility but can be difficult to manage and audit without underlying structure.
EmpowerID's Policy-Based Access Control (PBAC) resolves this tension by integrating RBAC and ABAC into a unified framework. PBAC uses RBAC's organizational structures—roles, rights, and hierarchies—as the foundation, then layers ABAC's attribute-based conditions on top to enable dynamic, real-time authorization decisions. The result is an access control model that is both structured and adaptive, supporting fine-grained control while maintaining the governance capabilities organizations require.
EmpowerID's PBAC model extends beyond traditional approaches by unifying RBAC with ABAC principles. This results in a powerful, application-centric framework that dynamically adapts access decisions based on user attributes, resource classifications, and environmental conditions—all while integrating seamlessly with your existing governance structures.
What Is PBAC?
Policy-Based Access Control (PBAC) is an authorization model that determines permissions by evaluating policy conditions at the time of access. Rather than depending solely on fixed role assignments, PBAC allows policies to reference dynamic elements—user attributes, resource characteristics, environmental context—to grant or deny access based on current conditions.
In EmpowerID, PBAC does not replace RBAC—it enhances it. Administrators can define policies that start with role-based eligibility but add attribute-based conditions that must also be satisfied. For example, access to financial systems might be granted to users with the "Finance Analyst" role, but only during business hours, only from corporate devices, and only for resources within their assigned region.
This layered approach strengthens security by ensuring that access is limited to only what is appropriate given the current context. It also supports regulatory compliance by enforcing conditions that go beyond simple role membership, such as requiring stronger authentication for sensitive data or restricting access based on geographic boundaries.
How PBAC Integrates RBAC and ABAC
PBAC serves as the integration point between RBAC's structure and ABAC's flexibility. Understanding what each model contributes helps clarify how PBAC works.
RBAC Contributions: Structure and Governance
RBAC provides the foundational elements of EmpowerID's PBAC model:
Rights and Roles - RBAC defines discrete access capabilities (rights) and groups them into roles for efficient assignment. In PBAC, these rights and roles establish baseline eligibility for access. A user must have the appropriate role or right assignment before attribute-based conditions are evaluated.
Organizational Hierarchy - RBAC models organizational structure through Business Roles and Locations, Management Roles, and group memberships. PBAC leverages this structure to scope policies and determine which users are eligible for access based on their position within the organization.
Assignment Scoping - RBAC enables administrators to scope permissions by location, organizational unit, or other hierarchical boundaries. PBAC policies inherit this scoping capability, allowing rights to be granted with geographic, departmental, or system-specific boundaries.
Pre-Calculated Permissions - RBAC can pre-calculate which users have which permissions based on role assignments and organizational relationships. PBAC uses these pre-calculated results as inputs to policy evaluation, improving performance by avoiding complex hierarchy calculations at runtime.
ABAC Contributions: Dynamic Context and Attributes
ABAC extends RBAC with runtime evaluation of attributes and conditions:
Field Types as Attributes - ABAC principles are implemented in PBAC through Field Types, which represent attributes about users (assignees), resources, and environmental conditions. These Field Types enable policies to evaluate current context rather than relying solely on static assignments.
Runtime Evaluation - While RBAC assignments are relatively static, ABAC conditions are evaluated at the time of access. PBAC policies can check whether a user's authentication method meets requirements, whether the resource classification matches their clearance, or whether environmental conditions satisfy security policies.
Fine-Grained Conditions - ABAC enables policies to express nuanced requirements that would be impractical with roles alone. PBAC policies can combine multiple Field Types to create sophisticated rules: "Grant access if the user's department matches the resource's owning department AND the user authenticated with MFA AND the request originates from an approved network."
Relationship-Based Logic - ABAC supports evaluating relationships between users and resources. PBAC policies can enforce rules like "users can access reports for their direct reports" or "project members can access project documents," with these relationships evaluated dynamically based on current organizational data.
The PBAC Integration
PBAC policies bring these elements together. A typical PBAC policy:
- Grants a specific right or role (RBAC element)
- To a specific assignee (person, group, Business Role and Location, or Management Role—RBAC actors)
- Scoped to specific resources or locations (RBAC scoping)
- Subject to Field Type conditions (ABAC attributes)
This structure ensures that policies are both manageable and expressive. The RBAC elements provide clear governance—you can audit who has which rights and roles. The ABAC elements provide adaptability—access decisions consider current context and conditions.
The Application-Centric Model
At the heart of EmpowerID's PBAC framework is the concept of applications as first-class authorization entities. Every application onboarded into EmpowerID can be configured with its own access control model, ranging from basic RBAC to full PBAC with attribute-based policies and fine-grained resource targeting.
This flexibility allows each application to have a tailored security configuration based on its sensitivity, business impact, or integration requirements. A low-risk internal application may use simple role assignments, while a mission-critical HR system may require multi-layered PBAC with environmental constraints and approval workflows.
EmpowerID supports a progression of application authorization models that vary in complexity and integration:
- Not PBAC and not Azure - The application does not use PBAC features or Azure integration
- PBAC App: No App Resources, No Field Types - A basic PBAC application without additional resources or attributes
- PBAC App: Yes App Resources, No Field Types - A PBAC model with defined application resources but no attributes
- PBAC App: No App Resources, Yes Field Types - A PBAC model that uses attributes without specifying particular application resources
- PBAC App: Yes App Resources, Yes Field Types - A PBAC model with both resources and ABAC-style attributes for fine-grained control
- Azure App - An application integrated with Azure, utilizing Azure-specific features
- Azure Applications with PBAC - An Azure-integrated application that employs PBAC capabilities
- Azure Applications with App Resources and PBAC - A model that combines Azure integration, application resources, and PBAC attributes
Each model provides progressively richer control. Organizations can start with simpler models and adopt more sophisticated PBAC features as applications mature or requirements evolve.
Applications can be configured with varying levels of PBAC sophistication based on their requirements. To determine the appropriate authorization model for your application, see Onboarding PBAC Applications.
Field Types: The ABAC Foundation
Field Types in EmpowerID enable policies to consider real-world context by turning abstract conditions into evaluable attributes. They function as variables in access control logic, representing characteristics of users, resources, and environments.
Field Types are categorized into three types that align with ABAC principles:
Assignee Field Types reflect information about the user or entity requesting access. These might include department, job title, clearance level, employment status, or manager relationships. Assignee Field Types enable policies to make decisions based on who the user is and their current organizational context.
Resource Field Types describe properties of the resource being accessed. This could include classification level, owning department, geographic region, project association, or data type. Resource Field Types enable policies to treat resources differently based on their characteristics—applying stricter controls to confidential data or limiting access to resources owned by specific departments.
Environmental Field Types represent contextual elements at the time of access. These include time of day, day of week, network location, IP address, device type, authentication method, or system state. Environmental Field Types enable policies to adapt to risk—requiring stronger authentication from external networks or restricting access to sensitive systems outside business hours.
Using Field Types, administrators can define rules that reflect business requirements naturally. For example: "Allow access to documents classified as 'Confidential' only if the user's clearance level equals or exceeds the document's classification AND they are accessing from the corporate network." This rule combines Resource Field Types (document classification), Assignee Field Types (user clearance), and Environmental Field Types (network location) into a cohesive policy.
For detailed information on Field Types, including how to create and manage them, see Understanding Field Types in EmpowerID PBAC.
Assignment Points: Scoping Permissions
Granular control requires not only understanding what a user can do but also where they can do it. EmpowerID uses Assignment Points and Assignment Point Types to define the scope of permissions within applications and systems.
Assignment Points specify exact locations or entities within a system where permissions apply, while Assignment Point Types categorize the scope of these assignments. This hierarchical structure ensures precise control over permissions, preventing over-provisioning and maintaining clear boundaries for access rights.
Example: Microsoft Entra ID Assignment Points
In Microsoft Entra ID environments, EmpowerID recognizes several Assignment Point Types that correspond to Azure's resource hierarchy:
- Tenant Root - Rights applied globally across an entire tenant
- Management Group - Rights scoped to specific management groups
- Subscription - Assignments at the subscription level for resource provisioning
- Resource Group - Rights limited to specific resource groups
For instance, an administrator might assign a user the "Contributor" role at the Subscription level. This grants permissions within that specific subscription while preventing unintended access at the tenant level or to other subscriptions. This precise scoping ensures that permissions are granted only where needed.
Systems with different architectures implement Assignment Points according to their specific structures. In SAP systems, Assignment Points are represented through Field Type Values rather than explicit hierarchical entities, using organizational attributes like company code, cost center, or plant. This flexibility allows Assignment Points to adapt to different system architectures while maintaining precise permission control.
Projection: Extending PBAC to External Systems
While EmpowerID's PBAC model provides sophisticated policy-based authorization, many organizations need to enforce these policies in external systems that do not natively support PBAC concepts. These systems may rely on traditional groups or roles rather than dynamic policy evaluation. EmpowerID addresses this challenge through a capability called Projection, which extends PBAC policies to external systems while maintaining centralized policy management.
Projection works by mapping PBAC rights and roles to groups in external systems. When a user is granted a PBAC right or role that has been mapped to an external group, EmpowerID's projection engine automatically manages that user's membership in the corresponding external group. This ensures that access in the external system stays synchronized with PBAC policies defined in EmpowerID.
How Projection Works:
External groups are designated as Fulfillment Groups and mapped to specific PBAC rights or roles in EmpowerID. When PBAC policies grant or revoke rights, the projection engine evaluates whether users should be added to or removed from the corresponding Fulfillment Groups in the external system. This synchronization happens automatically, ensuring that access control remains consistent across all systems.
For example, a PBAC policy might grant the "Contributor" role to users in the Finance department for resources in the North America subscription, with conditions requiring MFA authentication. The Contributor role is mapped to an Azure AD group that grants actual permissions in Azure. When users satisfy the PBAC policy conditions, EmpowerID adds them to the Azure AD group automatically. If conditions are no longer met—such as a user transferring out of Finance—EmpowerID removes them from the group.
This projection capability enables organizations to leverage PBAC's dynamic, attribute-based policies even when working with systems that only understand traditional group-based permissions. It provides centralized governance while respecting the native authorization models of diverse systems.
Rights, Roles, and the RBAC Foundation
EmpowerID defines rights as discrete access capabilities within an application or system—such as "Read Reports," "Create Users," or "Manage Resources." These rights can be either global (applicable across multiple applications) or local (specific to a single application).
Roles group rights together for efficient assignment and lifecycle management. Like rights, roles can be global (providing standardized definitions across systems) or local (offering tailored groupings for specific applications). This hierarchy ensures that administrators can maintain both consistency and specificity in how access is granted.
In PBAC policies, rights and roles provide the RBAC foundation. A policy might grant a specific local right to users in a particular Management Role, then add Field Type conditions that must also be satisfied. This layered approach leverages RBAC's governance capabilities while adding ABAC's dynamic evaluation.
PBAC Policies: Composing Authorization Logic
PBAC policies are the mechanism through which RBAC and ABAC elements combine into executable authorization rules. Each policy is structured to be clear, auditable, and manageable.
A PBAC policy:
- Grants a single local right or local role - This provides clarity about what capability is being assigned
- To a single assignee - The assignee can be a person, group, Business Role and Location, Management Role, or query-based collection
- May include Field Type conditions - These attribute-based conditions must be satisfied for the policy to grant access
- May be scoped to specific resources or locations - This limits where the granted right can be exercised
This structure ensures that each policy has a clear purpose and can be understood independently. When multiple policies apply to a request, EmpowerID evaluates all relevant policies and their conditions to determine the final authorization decision.
Example: Combining RBAC and ABAC in a Policy
To illustrate how these components work together in practice, consider a policy that combines role-based assignments with attribute-based conditions and scoping. This is a conceptual example that demonstrates the pattern rather than a specific pre-configured policy:
A policy grants the "View Financial Reports" right to all users in the "Finance Department" Business Role and Location (RBAC assignment). However, the policy includes Field Type conditions requiring that access occur during business hours (Environmental Field Type) and that the user's clearance level be "Confidential" or higher (Assignee Field Type). Additionally, the policy is scoped to reports for the North America region (Assignment Point).
When a user requests access, EmpowerID first checks whether they have the Finance Department Business Role assignment (RBAC). If yes, it then evaluates whether the current time falls within business hours and whether the user's clearance meets requirements (ABAC). Finally, it ensures the report being accessed is within the North America scope (RBAC scoping). All conditions must be satisfied for access to be granted.
This example demonstrates how PBAC policies layer RBAC structure (roles, rights, scoping) with ABAC conditions (Field Types evaluated at runtime) to create sophisticated yet manageable authorization rules.
Managing Complexity Through Structure
While PBAC enables sophisticated policies, EmpowerID provides structure to keep complexity manageable. The application-centric model means that policies are organized by application, making it easier to understand and maintain access control for each system. The clear policy structure—right/role + assignee + conditions + scope—creates consistency across policies.
Field Types provide reusable attribute definitions that can be shared across applications, promoting consistency in how attributes are evaluated. When a Field Type like "Department" or "Classification" is defined once, it can be referenced in multiple policies, ensuring that these attributes are interpreted consistently throughout the system.
The integration of pre-calculated RBAC results with runtime ABAC evaluation balances performance with flexibility. Complex organizational hierarchies and role inheritances are calculated in advance, while dynamic conditions are evaluated only when needed. This hybrid approach ensures that PBAC can scale to large organizations without sacrificing the context-awareness that makes it valuable.
Summary
EmpowerID's Policy-Based Access Control (PBAC) unifies Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) into a comprehensive authorization framework. PBAC uses RBAC's organizational structures—roles, rights, hierarchies, and scoping—as the foundation, then enhances them with ABAC's attribute-based conditions evaluated at runtime. This integration provides the structure necessary for governance while enabling the dynamic, context-aware decisions that modern applications require.
Through Field Types, PBAC policies can evaluate user attributes, resource characteristics, and environmental conditions to make fine-grained access decisions. Through Assignment Points, policies can precisely scope permissions to specific locations within system hierarchies. Through Projection, PBAC policies can be enforced even in external systems that rely on traditional authorization models. Through rights, roles, and organizational modeling, PBAC maintains the clear audit trails and lifecycle management that compliance demands.
By bringing these capabilities together in an application-centric framework, EmpowerID enables organizations to implement sophisticated access control policies that adapt to changing conditions while remaining manageable and auditable. Organizations can start with simpler authorization models and progressively adopt more sophisticated PBAC features as their requirements evolve, ensuring that access control keeps pace with business needs.