...
...
...
...
Application-Centered Authorization System
The EmpowerID PBAC model strongly emphasizes applications, recognizing them as central to organizational security strategies. It supports a broad spectrum of security configurations, from straightforward RBAC frameworks to more complex systems that incorporate ABAC attributes and policy conditions. This flexibility ensures a comprehensive approach to security management tailored to each application's unique requirements.
Application-Centric Approach
Applications are fundamental to the EmpowerID PBAC model. The system caters to various security setups, integrating basic RBAC principles with advanced ABAC attributes and policy conditions. This model provides a versatile framework for securing applications by addressing their specific security needs.
Simplified Onboarding and Management
EmpowerID streamlines the process of onboarding and managing applications through intuitive web interfaces and wizard-based workflows. These tools, coupled with REST API support, facilitate efficient application setup and authorization model management. By treating applications as RBAC Resource Types, EmpowerID ensures they are each managed as distinct resource records, simplifying the governance of access rights.
...
During the application creation phase, EmpowerID allows for the designation of an application as a "PBAC Application" through the selection of an appropriate "Authorization Model." This model determines the types of authorization and features enabled, which can include roles and rights, solely rights, or Field Types—ABAC-style attributes used for granular access assignments. When an application is designated as a PBAC Application, EmpowerID creates a corresponding Resource System Module record. This record links the application to the PBAC data model, aligning its authorization settings with the PBAC framework. Notably, all Azure App Registrations inventoried or created using EmpowerID workflows are PBAC-enabled, with EmpowerID rights corresponding to Azure App Roles in the PBAC model.
PBAC Applications and Authorization Models
Applications in EmpowerID are initially categorized as RBAC Resource Types, subjecting them to basic RBAC policy governance. Once an application is designated as a PBAC Application, it transitions to being managed under the PBAC framework, allowing for the implementation of specific PBAC configurations that leverage ABAC-style attributes for more granular access control.
Authorization Model Examples:
Simple Rights Model: Suitable for environments where detailed role hierarchies are unnecessary, focusing on straightforward rights management.
Advanced Rights Configuration Using Field Types: Associates rights with field types like "Product" or "Department," enhancing dynamic permission management.
Integration with Universal PBAC
EmpowerID’s PBAC data model is structured as a "Universal PBAC," designed to integrate diverse permissions models of various systems, from internal PBAC apps to external platforms like Microsoft Entra ID and SAP S4/HANA. This integration aims for a unified and holistic approach to cross-application access and risk management.
For example, Microsoft Entra App Registrations are cataloged as PBAC applications and assigned their respective Resource System Modules within EmpowerID. Similarly, systems like SAP S4/HANA follow this model, with designations like "SAP-ECC" or "S4/HANA" for the Resource System Type and various Resource System Type Modules. Each client connected to EmpowerID features Resource System Modules for these services, reflecting the organized structure and management of services under the PBAC framework.
This universal structure allows EmpowerID to manage permissions coherently across diverse applications and platforms. Each application, whether simpler than Entra and SAP or similarly complex, is treated as a distinct system with its unique Resource System Module. These modules share a common Resource System Type Module designated as "PBAC Application," facilitating the organization and management of permissions across various applications.
By understanding and leveraging the Universal PBAC structure, application owners can ensure their application-specific objects are correctly integrated within the broader permissions landscape, enhancing security and functionality.
Managing Rights and Roles
EmpowerID provides a sophisticated model for managing rights and roles within custom PBAC applications, which operate differently from large commercial applications or infrastructures like Entra or SAP. This model distinguishes between Global Rights and Local Rights to effectively manage the diversity of permissions across various systems.
To manage this diversity, EmpowerID employs a model that distinguishes between Global Rights and Local Rights. Global Rights are consistent across all instances of a service or system, representing the uniform permissions set. On the other hand, Local Rights apply specifically to the permissions as they exist within a particular system, or Resource System.
For custom PBAC applications, the relationship between Global and Local Rights is straightforward: each right created within an application will have one Global Right, and this Global Right is mapped to its respective Local Right. These Local Rights are then utilized in policies and assignments within the PBAC model, enabling precise and tailored application-specific authorization.
Role Definitions
Some PBAC applications provide the option within their Authorization Model settings to incorporate Role Definitions. These Role Definitions adhere to the same Global and Local model that governs rights. For systems like Entra, Global Roles such as Global Admin, Contributor, and Groups Administrator are standardized across every tenant worldwide. These Global Roles consolidate identical Global Rights within their definitions, providing valuable data for risk analysis and reporting. However, it is only the "local" versions of these roles, which exist within specific tenants or Resource Systems, that can be assigned to users and groups.
Similarly, in custom PBAC Applications, Local Roles are composed of bundles of Local Rights. These Local Roles are utilized in assignment policies, allowing for tailored authorization that aligns with the specific needs and configurations of the application. Applications that opt to implement a straightforward RBAC-like model allow users to request or assign Local Rights and/or Local Roles.
PBAC Policies (“Assignments”)
EmpowerID supports two types of PBAC policies or assignments: the assignment of a Local Right or of a Local Role, also known as a Role Definition. Each policy or assignment is limited to selecting either one Right or one Role Definition for assignment. Furthermore, the assignment policies also restrict the selection to only one assignee, which can be any of the EmpowerID Assignee Types, including Person, Group, Management Role, Business Role, Location, or Query-Based Collection. This limitation of one assignee and one Right or Role definition per policy simplifies the auditing process and enhances risk analysis.
Assignment Points and Types
The concepts of AssignmentPoint and AssignmentPointType represent a critical aspect of the assignment process. These components are pivotal as the Universal PBAC model accommodates both custom PBAC Applications and established commercial systems, including SAP and Entra. EmpowerID integrates native assignments from these systems within the same database structures, highlighting its flexibility and comprehensive approach.
For SAP, the assignment mechanism predominantly utilizes ABAC-style Field Types. Conversely, Entra ID employs Directory Role and RBAC Role assignments cataloged under AzLocalRoleScope entries. This distinction underscores the use of AssignmentPoint and AssignmentPointType to delineate their scope and targets within the system's architecture. EmpowerID characterizes the structure of Entra ID Tenants—comprising Management Groups, Subscriptions, and Resource Groups—as External Locations. This classification allows for accurate scoping of Entra RBAC Role assignments, ensuring that rights are appropriately allocated to these locations and their respective resources.
EmpowerID logs this information, with the assignment point as the unique identifier for each location. The AssignmentPointType denotes the level of assignment, such as Tenant root, Management Group, Subscription, or Resource Group. Within this framework, Directory Roles may be assigned at the Tenant root or associated with an Entra ID Application Registration.
In the context of SAP’s method, assignment points are supplanted by contextual data encapsulated as Field Type values. Notably, SAP's application of Role Definitions deviates, treating SAP Roles more akin to groups designated for "role authorizations." Acknowledging these variances is imperative for effectively administrating roles and rights across platforms within EmpowerID, ensuring a robust and efficient approach to identity and access management.
Fine-Grained Authorization and Field Types
Many application requirements are adequately met using the simpler Rights and Roles model. However, some applications demand a more sophisticated, fine-grained authorization. Fine-grained authorization enhances security by enabling the addition of conditions or constraints to policies based on attribute values related to the Assignee (also known as the Subject), the Resource, or the Environment.
Field Type Scopes
In EmpowerID, attribute definitions are organized as Field Types, with their respective values known as Field Type Values. The application of these attributes within a policy is identified as the Scope Type. This structure enables a sophisticated and customized approach to permission and access right management, meeting complex security needs of applications.
Assignee Constraints: Policies apply to specific assignees through assignee constraints, refining their applicability.
Resource Constraints: Resource constraints are vital in scenarios where resources are too vast to catalog or inherently "unknown" within EmpowerID, preventing direct selection during policy creation. Such resources might be termed "intangible" and are represented by a set of descriptive attributes at the decision-making point. For example, in managing customer insurance policies by the millions, the Policy Decision Point (PDP) may consider attributes like country, policy type, originating agency, and dollar value. The PDP then uses these attributes and other conditions to make access decisions. Here, the focus is on managing access based on attribute values and conditions rather than identifiable resources.
Environmental Constraints: Environmental constraints, such as time, location, or Multi-Factor Authentication (MFA) type, are evaluated in real-time, with relevant data presented to the PDP at the access decision moment. This policy information can be communicated to applications at login via JWT or SAML claims, allowing the application to enforce policies based on dynamically received attributes.
Field Types in EmpowerID serve as the foundation for conditions within a PBAC policy and can be available universally or owned by specific applications. While all Field Types reside in the same data model, those created for a particular application are tagged with a CreatedForResourceSystemModule value. This tagging segregates them from the universal pool and prevents unauthorized alterations, giving application owners control and security over their Field Types.
However, some Field Types, such as those representing countries or corporate entities, are beneficial when shared across applications. Sharing these enhances consistency and minimizes redundancy in the system's data model.
Understanding the intricacies of ABAC and PBAC systems, and the relationship between Field Types and Rights in a detailed authorization framework, becomes easier by examining the architectural and operational frameworks of applications. Applications often center around databases that organize data into entities, such as customers, orders, and invoices, each defined by specific attributes (e.g., customer company, order type, order amount). This setup clarifies the role and importance of Field Types and Rights within application security and management.
The Role of Eligibility Policies
Eligibility policies in PBAC applications specify which users can see and request specific resources based on predefined criteria. These policies are crucial in ensuring compliance, enhancing security, and streamlining access management by restricting access to only those users who meet certain conditions.
For example, the right to "View Customer Records" might be restricted to users within the "Sales Department" who hold specific roles or statuses, such as "Senior Sales Manager." This ensures that only authorized personnel with a legitimate need can access sensitive customer data. By implementing such policies, organizations can prevent users who do not require access from inadvertently accessing applications or application data, thereby reducing the risk of unauthorized access and potential security breaches.
PBAC Resource Types
In the EmpowerID PBAC Model, entities can optionally be represented as PBAC Resource Types. This categorization allows application owners to specify which application entity a Right is associated with. These PBAC Resource Types are distinct from RBAC Resource Types and do not integrate into the RBAC framework.
Each entity’s attributes pertinent to authorization policies can be defined as Field Types, with the specific values for these attributes entered as Field Type Values. Once these Field Types are established, they can be linked to the Local Rights corresponding to that PBAC Resource Type, representing the specific application entity. This setup allows you to determine which Field Types—properties of the entity—can be utilized as ABAC-like constraints in a policy when assigning Rights specific to the PBAC Resource Type representing your application entity. This structured approach ensures that policy authors are constrained to selecting only those "Resource-Scoped Field Types" that align with the properties of the PBAC Resource Type for which the Right applies.
Conclusion and Next Steps
...