Unifying RBAC and ABAC in a Dynamic Authorization Framework

Dynamic authorization is a central challenge in identity and access management for large enterprises running diverse portfolios of custom, commercial off-the-shelf (COTS), and SaaS applications across heterogeneous infrastructure. Inconsistent authorization models (ACLs, groups, roles) and siloed administration create policy fragmentation, especially in organizations with many legacy applications whose authorization logic has devolved into “spaghetti code.” Downstream systems (data warehouses and BI) often cannot replicate the original access controls, compounding risk and inconsistency. The resulting “combinatorial explosion” can require billions of entitlements when thousands of subjects interact with millions of data elements, producing negative impacts such as degraded data quality, user confusion in requesting access, inconsistent customer experiences, and elevated risk of sensitive-data exposure.

A future-state approach requires a business-driven, data-driven authorization discipline that balances discretionary access needs with strong governance. Authorization is framed across three architectural dimensions: governance/admin-time authorization (policy setting, access requests/reviews, provisioning, certification), policy models (groups, RBAC, ABAC, entitlements, rules), and runtime authorization (real-time enforcement via applications, gateways, or centralized decision services). ABAC can unify policy thinking but is only effective with high-quality, consistently defined attributes and robust governance; it is best combined with RBAC and groups rather than treated as a standalone “secret sauce.”

The recommended path is a unified authorization framework that typically uses roles and groups for coarse-to-medium decisions, with rules and ABAC concepts added selectively for fine-grained needs. Runtime patterns include application-specific decisions, enterprise applications using policy information points, API gateways, externalized authorization managers with centralized policy decision points, data filters, federated access, OAuth-based API access, and IDaaS-mediated SaaS access. Organizations should implement a hybrid, loosely coupled architecture that evolves over time, starting simple and escalating complexity only when necessary.

• Large organizations commonly run a mix of custom-built, COTS, and SaaS applications across diverse operating systems and cloud IaaS environments.
• Different systems frequently use different authorization models, including ACLs, groups, and roles.
• Even when systems support groups, they often do not structure, store, or use groups consistently.
• Many application suites dating from the 1990s remain in production while documentation has been lost and authorization logic has become difficult to analyze.
• Data from legacy applications is often fed into downstream data warehouses and BI systems where original access control policies may not be replicable.
• Authorization complexity can reach billions of entitlements when thousands of subjects interact with millions of data elements.
• Initial authorization can incorporate device identity, location, and health information collected at authentication enforcement points.
• XACML defines a declarative, fine-grained, ABAC-based policy language, architecture, and processing model for evaluating access requests.
• Runtime authorization patterns include API gateways, externalized authorization managers, federated web access, OAuth 2.0 API access, and SaaS access via IDaaS.
• Distributed authorization decision-making in the cloud is described as not highly evolved due to missing shared profiles and dictionaries for attributes, roles, and entitlements.

• “Dynamic authorization in complex enterprise IT environments is one of the most challenging parts of identity and access management (IAM) and information security alike.”
• “Admin time policy management and runtime policy enforcement must meet in the middle with policy model for groups, RBAC, ABAC, entitlements, and policy expressions (or rules).”
• “Group over-proliferation is endemic in the industry and probably impossible to avoid without following the good practices below.”
• “Most enterprise RBAC deployments fail due to a lack of business engagement, role proliferation, or a failure of lifecycle management.”
• “ABAC is only as good as the data quality of the attributes and the consistency of their definitions.”
• “Rules must be governed and must prohibit discretionary definition.”
• “In practice, it is not RBAC vs. ABAC, but rather a sort of continuum.”
• “Don’t bite off more than you can chew by creating overly complex policy models using ABAC for fine-grained authorization with complex rules where simpler approaches may suffice.”
• “Make things as simple as possible, but no simpler.”
• “A dynamic authorization architecture combines RBAC, ABAC, and multiple admin time and runtime authorization patterns to create a flexible platform for business growth, risk management, and compliance.”