...
ABAC relies on user attributes for authorization decisions. ABAC policies are rules that evaluate access based upon on the following four sets of attributes:
...
Figure 1: NIST SP 800-162 ABAC Definition
ABAC Benefits
The key primary advantage of ABAC is that it does not allow lies in preventing application developers to hardcode from hardcoding a static list of roles and oversimplify oversimplifying their authorization source code. RatherInstead, ABAC forces requires them to centralize all authorization decisions and make runtime calls for a decision based on the Subject, Resource, Action, and Environment request attributes. Another key significant benefit is the ABAC's simplicity of ABAC, which can make it easier to understand facilitate understanding how a rule grants access to a resource. In contrast, RBAC does can seem foreign to many users, and , especially during the its early adoption phase of its adoption, the levels of abstraction can be challenging pose challenges for an IT team.
One other ABAC's flexibility is another added advantage of ABAC is its flexibility. With ABAC, as . As long as the necessary data is available, almost anything can be represented as a rule-based query with ABAC. For exampleinstance, a rule evaluated at runtime in a login session can use contextual information—even information – even information passed in via SAML claims or JWT tokens. In contrast, a standard RBAC engine would not evaluate this type of information when delivering the role membership for a user to the application, a standard RBAC engine would not evaluate this type of information.
ABAC Primary Benefits
ABAC enforces centralized management of authorization policies.
ABAC makes it easy to specify access rules as simple queries.
ABAC rules can be extraordinarily fine-grained and contextual.
ABAC rules can evaluate attributes of Subjects and Resources
...
not inventoried by the authorization system.
ABAC rules
...
require less maintenance and overhead
...
since they do not
...
necessitate the creation or maintenance of the structure on which an RBAC model depends,
...
such as roles and resource locations.
Figure 2 below , shows an example of an actual ABAC policy implemented in an EmpowerID demonstration. Here, our application is asking asks if Alice can View Bob’s Bob's X-Ray. Our ABAC decision engine will base bases its decision on an elaborate a complex ABAC policy (labeled Policies in the figure). The first policy check, Rule1, is verifies that the action being taken is ‘View"View.’ " The next extended requirement for Rule1 is that the company is not in ‘Emergency "Emergency Mode,’i.e., " meaning it is not in the middle midst of a crisis. However, to further extend the increase rule flexibility during a crisis, some roles may be granted additional permissions to enable those who would not typically not be permitted allowed to perform those activities to assist. The next check is only to allow ‘View ‘if only allows "View" if the person is currently on the ‘Local "Local Network.’ " (Some sensitive activities might not be allowed if the person is outside the corporate network.) The next check confirms that the user performed a Multi-Factor Authentication (‘MFA’"MFA") with a Level of Assurance (‘LOA’"LOA") of at least ‘2’"2". This type of authentication refers to a stronger authentication method, like a physical token or mobile push. The policy also checks to see if the user is a member of the Doctors role and that their status is not currently set to out of office. Finally, the checks ensure that the X-Ray has neither been flagged as ‘Confidential’ "Confidential" nor the Subject has a relationship of the type Attending Physician.
...
ABAC Weaknesses
The first challenge encountered with implementing policies like this is the information needs to be obtained and evaluated the previously discussed example is obtaining and evaluating information at runtime. In the above policy example, if we needed to know if the user’s nationality was Swiss, then this information would likely reside in either the corporate Active Directory or HR system (Figure 3). Moreover, if we needed to know if the company was in Emergency Mode or not, this essential information might be difficult to obtain in a live corporate environment. Likewise, if we needed to ascertain their out of office status, this would reside in a corporate email system such as Office 365. Furthermore, to attain information for network login sessions or the MFA status would require a query to an Identity Provider such as Ping Federate.
...
Figure 3: Sources of attribute data for a complex runtime ABAC policy evaluation
It is easy to see that the information required to make a decision at runtime will be scattered across many different systems. With regards to your organization, if your ABAC system were to make a live call to retrieve this information from these systems, there are two prime questions:
...
how long would it take?
...
acquiring information such as user nationality, company status, out-of-office status, and network login sessions or MFA status would require queries to various systems (Figure 3). This raises two crucial questions for your organization regarding your ABAC system:
How long would it take to retrieve this information?
Would this delay be acceptable to your organization and its users?
...
Figure 3: Sources of attribute data for a complex runtime ABAC policy evaluation
For end-user applications, where even an additional delay of even half a -second delay can be considered unacceptable, such a lag is not only unacceptable but also presents an insurmountable challenge. (This also lag poses a significant challenge. Moreover, this assumes that all these systems present provide an API that can be called to retrieve this data, which many do not. ) It quickly becomes apparent clear that our extremely implementing a powerful but complex demo policy would be an impossibility extremely difficult in a real-world environment and is a puzzle that organizations need to solve.
With ABAC, a challenge Another challenge with ABAC is that the Just-In-Time (JIT) evaluations of its rules often results in lead to a disconnect or lack of an auditable link between the rule-based policies and the resources they protect. With access rules defined in text-based policies, ABAC policies are inherently non-relational. This model contrasts significantly with , unlike the relational nature of RBAC, where users are related to roles and , which, in turn, relate to permissions for resources. This lack of a relational concept is at the core of many of ABAC’s ABAC's weaknesses.
In terms of auditing, though answering the following standard questions should be straightforward, the reality is otherwise:
...
ABAC makes it difficult to answer standard questions such as:
How do I see which users have access to my application and how each was granted access?
How will application owners be trained to read and interpret the rules and
...
research all the source information?
Given that
...
attribute values' origin could come from another system or be contextual to a single login session, how would the application owner determine who matches the rule?
How would the application owner grant direct access to a user in an ABAC model?
As a delegated admin, who can add or remove users from specific groups that might be used in many ABAC rules?
How would a user know that adding someone to a group grants them access to Application A?
...
As an auditor, how would I audit how access is granted to the application and who is giving the access?
...
In a policy example with multiple unrelated checks, was the person who assigned the person’s Job Title in HR the grantor of the access or was it the person who flagged the user as having completed training?
...
What security weight should be associated with the Job Title and Training Status fields on a user?
...
From how many sources could this information be edited and by whom? Potentially many people could be unintentionally performing “Entitlement Management” on a day-to-day basis.
...
How does an auditor monitor the transitions when users are granted and revoked access to sensitive applications dynamically? No log would track persons who had access on a Monday versus a Friday because access would only be evaluated at runtime.
...
Figure 4: A Common Standard Auditor's Question
ABAC’s Primary Weaknesses
ABAC makes it extremely difficult to perform a
...
"before the fact
...
audit" and determine the permissions available to a specific user
...
In a comparable manner to how a “Role Explosion” can occur with RBAC, an explosion can also occur with ABAC where a system with N number of attributes would have 2N possible rule combinations.
...
.
ABAC systems can experience an explosion of possible rule combinations, similar to the "Role Explosion" in RBAC.
ABAC systems with complex rules from multiple attribute sources can be unacceptably slow to answer authorization queries, unless rules are kept simple and do not access data from various source systems.
ABAC Challenges
...
Figure 5: The Who, What, and How of ABAC Challenges
Another challenge Indeed, one of the significant challenges with ABAC is finding someone individuals within the an organization with who possess the required skills and knowledge to write effective authorization policies. To write Crafting rich, accurate, and effective policies requires both efficient policies demands a combination of solid business knowledge and a deep understanding of security.
XACML was , developed 18 years ago as a standards-based language built on XML to write , was designed for authoring authorization policies. The original idea with behind XACML was that business users would author be the ones creating these policies and, in vendor marketing and some analyst circles, this idea persists to this day. The notion that business users would know best how to determine who should be able to do what from a business activity perspective is, after all, entirely logical, as they would have the best understanding of who should have access to specific resources and activities from a business perspective. However, writing XACML policies is extremely a highly complex . task, and most business users lack the technical expertise or simply do not possess have the time to write IT policies.
This challenge highlights the need for a more user-friendly approach to writing authorization policies that can be accessible to business users without requiring in-depth technical expertise. One potential solution is to develop more intuitive policy authoring tools or languages that simplify the process of crafting and managing authorization policies. Alternatively, organizations could invest in training programs for business users to better understand the technical aspects of writing policies or provide support from IT teams to help bridge the gap between business requirements and technical implementation.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
...