Introducing XACML - the standard for Attribute-Based Access Control
In the previous article, we talked about what Attribute-Based Access Control is and what are its advantages compared to the most common Role-Based Access Control today. It's time to review ABAC in more detail, through an existing standard called XACML .
The standard is experiencing the third and, most likely, not the last edition, its history dates back to 2003. He oversees and supports the standard organization of OASIS . This standard describes the necessary system components, their purpose, the way they interact and use. In fact, it covers everything you need, to the smallest detail.
This article will look at how to express business rules in the form of security policies, the main components of a security system, its integration and other aspects that are not affected by the standard, but are equally important and interesting. I invite all readers to get acquainted with these issues in more detail. Any comments, comments, questions and criticisms are also welcome.
Security policies
Rule
Policy
Policy set
The main components of the system
Policy Administration Point
Policy information point
Policy decision point
Policy Enforcement Point
Example
What's left overs
Outside the standard
Attribute can be any
Interface and Authorization Check
Data filtering
Admin panel concept
Editing policies
Editing a policy set
Policy search
Actions available in the specified context
Testing policy execution
Application Integration
Afterword
')
We will begin our review of the standard with an overview of changes in business rules and continue with an overview of the tools and ways to handle these business rules.
Any business rule that is responsible for the possibility of performing an action or access to an object answers the question “Is there access?” And gives one of two answer options: “Yes” or “No”. And the condition of such a business rule is reduced to a set of logical expressions, the calculation of which gives one of two possible answers. Therefore, security policies are a logical expression that operates on attributes and constant values.
Let's start with a closer look at the security policies themselves and how the standard describes them.
Although this scheme from the standard may look a bit intimidating at first glance, everything is quite simple in it. The picture shows the hierarchy of basic XACML objects used to express business rules. The elementary particle of hierarchy is the rule ( rule ). Rules are combined into policies ( policy ), which, in turn, are combined into sets of policies ( policy set ).
As described in the standard, a rule cannot live by itself, it must necessarily be included in the policy . This means that the mechanism for calculating access rights operates with rules only in the composition of policies and nothing else. Nevertheless, the rule is the most saturated element in terms of business sense.
The rule itself consists of several parts:
The goal is the same for both rules , policies and policy groups . Therefore, the description here is true for them. A goal is a logical expression that should consist only of attributes and constants. The goal is usually made that part of the business rule that meets this requirement. The main point of dividing a business rule into parts is to quickly sift out inappropriate rules , policies, or groups of policies . For what it is needed - will be discussed in more detail in the description of the PDP .
The rest of the business rule (if there is one) containing a more complex, dynamically calculated logical expression must be placed in another part of the rule - the condition ( condition ). Those elements that can be specified in the condition , their format and everything connected with them are also described in detail in the standard, but their analysis is beyond the scope of this article.
Business rules can be either permissive or prohibitive. To indicate this, there is another part in the rule - the effect. It can be either “ permit ” or “deny” ( deny ). The most important thing to know is that the effect of the rule works only in the case of a positive calculation ( evaluate ) of this rule . That is, the effect is applied only in the case when the result of the calculation of the logical condition in the target and in the condition is “true” ( true ). In the case when the result of evaluating a logical expression of a goal or condition is false , the result of the rule evaluation will be “not applicable” ( not applicable ). If in the process of calculating the logical condition of the goal or condition an error occurred, the result of the rule evaluation will be “ indeterminate ”. Thus, the result of the rule calculation can be one of four values: “ allow ”, “ prohibit ”, “ not applicable ”, “ not defined ”.
Consider the example of the formation of a fairly simple rule .
The first logical condition is a comparison of an attribute with a constant, and it is better to place it in the target of the rule (although it is possible to put it in a condition ). The second logical condition is a comparison of two attributes. It can only be placed in the condition of the rule . Since the business rule is permissive, the effect will be defined as “ allow ”. As a result, we get this rule :
In addition to the function of deciding whether to grant access rights to the security system, additional functional requirements may be imposed. An example of such a function might be a security audit. To solve this kind of problems in the standard there are obligations and recommendations . By and large, the difference between them lies only in the fact that the obligations must necessarily be fulfilled, and the recommendations can be ignored. Both obligations and recommendations describe the effect of the rule to which they apply, the action to be performed, and the expressions for obtaining the parameters of this action based on the current context.
Consider the example of a simple commitment. If there is a requirement for the security system to send an email to the owner of the object when someone interacts with it, then for this you can make a commitment that will look like this:
As a recommendation , for example, a description of the action of logging some information for debugging purposes can be specified.
A policy is used to merge a set of rules . Typically, a set of such rules is one business rule. Thus, several tasks are solved at once. First, small portions of the logical conditions expressed in the rules can be easily reused without duplicating these conditions. Secondly, such a division into parts facilitates the understanding of the entire business rule and simplifies its maintenance.
The policy consists of:
As mentioned earlier, the goal is needed to quickly screen out inappropriate policies . For what it is needed - will be discussed further in the PDP review.
The rule set simply lists all the rules included in this policy . The result of the policy calculation is one particular value, as is the case with the rules . This means that from the results of the evaluation of all the rules included in the policy it is necessary to obtain only one of the four available values. To obtain such a value from the results of the calculation of all rules , the policy combination algorithm applied for the policy is applied. The standard defines several different algorithms that may be useful in different situations. For example, "prohibited if not allowed" ( deny-unless-permit ). This algorithm will return the value " allow " only if the result of the calculation of at least one rule is " allow ". If the result of the evaluation of all the rules was a set of other values (“ prohibit ”, “ not applicable ”, “ not defined ”), this combination algorithm will return “ prohibit ”.
The standard also lists much more complex combination algorithms that introduce additional notions of the results of rule evaluation. Such an example would be the result that sounds like “not determined, but could be resolved” ( indeterminate {D} ), which refers to those rules during the evaluation of which an error occurred, and their effect in the case of a successful evaluation would be “ prohibit ” .
Consider an example of a policy based on a simple business rule.
This business rule can be broken into pieces and form from it two simple rules that can be combined into a policy .
Obligations and recommendations are discussed a little higher in the description of the rule .
A set of policies is needed to merge a group of policies for the purpose of their faster filtering based on a general purpose specified in the policy group goal . It can also be applied when there are extremely complex business rules for additional division into components. A set of policies in their constituent parts is very similar to ordinary politics . The only difference is that in the case of a set of policies , policies , not rules , are combined, and that the standard offers a slightly different set of combination algorithms for policies than for rules .
A set of policies consists of:
The only thing that should be noted is that the standard describes both the same and different combination algorithms for policies and groups of policies .
Let's look at an example of a set of policies using a set of business rules.
Three similar policies will be formed from these three business rules.
All of these rules have something in common: they describe the availability of actions on the same type of object and, moreover, at a certain time. Therefore, we can combine them with complete confidence in a set of policies .
Obligations and recommendations are discussed a little higher in the description of the rule .
So, we figured out how the standard proposes to turn business rules into elements that are understandable to the security system. Now consider what components the security system itself consists of and how it handles these business rules.
The policy calculation mechanism is the central component of the system and is referred to as the Policy Decision Point ( PDP ) in the standard.
In order to calculate security policies, they need to be created somewhere. Another component of the system is responsible for this — the policy administration mechanism, called the Policy Administration Point ( PAP ) in the standard. Another source of data needed by the PDP for computing is the source of attribute values, called the Policy Information Point ( PIP ). Last but not least, the component is the mechanism responsible for calling the PDP and correctly processing its response, which is called the Policy Enforcement Point ( PEP ).
This is the component in which the security policies are managed. As a rule, it is a kind of interface that allows the system administrator to turn business rules into policies and make them accessible to the PDP . In order to be able to manage policies with PAP , he needs to know the following things:
About the structure of policies already mentioned above, and a more detailed description of them is given in the standard. As for the functions, some of their list is already described in the standard, as described and the logic of their behavior. In addition, the standard implies the ability to add your own arbitrary functions. Therefore, if necessary, to form a final list of functions available for use, you may have to receive part of this list from somewhere.
Regarding the attributes in the standard also says a lot. The issue of typing and naming attributes is mainly addressed. Attributes themselves, as a rule, represent something specific for a business, therefore for each system this list will be its own. This means that the system must somehow be able to provide the necessary information. It is also good to provide information on what values may be available to certain attributes in order to be able to check the constants specified in the rules . It is worth remembering that attribute names may require localization. This means that in addition to the name of the attribute and its type, you must also provide a display name that can be localized. This will allow you to display policies in different languages without modifying the policies themselves.
From a security point of view, PAP does not play a key role. But from a security management point of view, this is one of its most important places. Now we have touched only the purpose of this component. We will look at its potential for managing the security system later .
As mentioned above, two things are needed for a PDP to work: the source of security policies and the source of attribute values. We have just talked about the first, and now let's talk about the second. The principle of operation of the PIP , at first glance, is quite simple. At the input it receives the name of the attribute, and at the output it gives all the values that it can find for it in the current execution context. The whole complexity of PIP lies in its internal structure, in how and where it is able to search for attribute values.
If the access control system is built into the application itself, and the PIP is able to search for attribute values among the current objects of the application, then it can, for example, translate the attribute name to the path to the object property and extract the value of this property. If the access control system is located as a separate service and accepts external calls, the PIP may be able to extract attribute values from this call. Or, the PIP can be able to retrieve current environment settings such as time, date, ip-addresses, etc. Also, PIP can be able to “walk” to any storage and look for attribute values there. In general, everything here is limited only by the imagination of the developers of the access control system.
For access control systems, this is probably the central component. This is where policies are calculated based on the current call context. It is very important to understand that the PDP operates on attributes only. An attribute from the point of view of a PDP is a common key by which it is necessary to find a value and substitute it in a calculated expression. He does not know anything and should not know about the fact that there are actions, users, environment, objects. Understanding this will allow you to use the full power of the access control system correctly and with maximum efficiency.
Most likely, the question may immediately arise: how does the PDP understand what security policy it needs to calculate in the context of the current action if it does not make any distinction? The answer is quite simple: no way. He simply calculates all available policies and on the basis of this forms his decision. This may seem like a crazy idea, at least in terms of performance, but if you look at this in more detail, everything falls into place.
First of all, it’s terrible to compute thousands of rules every time you check access rights. Thinking in categories of thousands is caused by the fact that in large systems the number of roles is usually calculated by such orders. But politicians are not roles. Dozens of well-designed policies can replace thousands of roles. So you need to think here in other ways. In addition, as already mentioned when considering the structure of policies , the goal envisaged in their structure is intended for quick filtering of policies that are not suitable for the current context. In fact, only policy units will be calculated. In general, various optimization methods can be applied here, which also depends on the vastness of imagination and resources.
In order to understand which policies are applicable at the moment, the PDP must calculate the goal of each of them, substituting the current values of the specified attributes there. PDP uses PIP to find them. Since the search logic in PIP can be different, the whole PIP collection can be used at the same time, where each PIP will look for the values of the specified attribute, guided by its own logic. The PDP simultaneously polls all its PIPs to find the desired attribute, and from the responses it forms an array of received values. In the standard, everything is focused on the fact that for each attribute an array of values of a previously unknown size can return. In the case when several policies or groups of policies are calculated in the current context, the result of their calculations is also combined with the combination algorithm predefined for PDP .
Along with other elements, rules , policies, or groups of policies may have obligations or recommendations . They consist of expressions that calculate the values of some attributes that will be passed to the PEP as part of the response. And their calculation can affect the result of the calculation of the rule itself , policy or group of policies .
Only those obligations and recommendations are calculated , the purpose of which coincides with the effect obtained from the calculation of their rules and policies.or policy groups . If the calculation of the attribute value of the commitment or recommendation ended with an undefined result, the result of the calculation of the corresponding rule , policy, or group of policies will also become undefined .
The result of all calculations should be a response that contains a decision on access, which can take one of the four values already described above: “ allow ”, “ deny ”, “ not applicable ”, “ not determined ”. In addition, the response may contain a list of obligationsor recommendations . It should be noted that the standard describes all the conditions under which the final list of obligations or recommendations should be formed .
The PEP is both the starting point and the ending point for all access control actions. The duties of the PEP as a starting point include preparing the request and calling the PDP . In essence, the PEP is responsible for transferring the current execution context to the PDP . The current context may include attributes related to the entity performing the action (name, title, department, branch), to the action (name of the action), to the action object (type, number, owner), to the environment (day of the week, date, ip-address). All of these attributes are aggregated and transmitted to the PDP .
As a final point, the PEP is responsible for receiving the response from the PDP., its interpretation and correct execution. Since the decision to grant access can take one of four values, the PEP must be able to turn them into two (“ allow ” or “ deny ”). Depending on the algorithm for interpreting values, PEP is divided into two types. Enable ( Permit based ) the PEP operates on the principle "everything that is not explicitly forbidden." This means that only in case of a negative decision will access be denied. In the other three cases, access will be allowed. Forbidding ( Deny based ) PEPacts according to the principle “Everything that is not explicitly permitted” is prohibited. This means that only in case of a positive decision will access be allowed. In the other three cases, access will be denied.
In addition to the decision to grant access, the response from the PDP may contain a list of obligations and recommendations that the PEP must comply with. As mentioned above, the obligations and obligations that their application is necessary. And this leaves an imprint on the execution of the decision received from the PDP . If the PEP does not understand how to fulfill the obligation , then, depending on the type of PEP, it will either cancel the ban, or cancel the permission. If the PEP is resolving , the decision to “ deny ” has come from the PDP , and it is impossible to fulfill the obligation , then the PEP will allow execution. It works the way it would have worked if it received an “ undefined ” solution . Conversely, if the PEP is prohibiting , the value of the decision coming from the PDP is “ allow ”, and the obligation cannot be fulfilled , the PEP will prohibit the execution. It works as if the decision from the PDP was “ undefined ”. Recommendations , in turn, may not be implemented, and this will not affect the decision to grant access.
Consider an example of an access control system in the case of an application consisting of a client, an application server and the main components of an access control system.
As the standard covers every detail, in this article small details were omitted. In the standard, much attention is paid to the description of those expressions that can be specified as a condition of the rule. What features should be? What types of data can be? How should these functions be calculated? What are the categories of attributes? What are some combination algorithms? All this - the details that should not affect the understanding of the overall picture. Yes, and a detailed analysis of them already has little concern with ABAC itself, rather with technical details of the implementation.
The standard describes a lot, down to the smallest details, but some moments still remain unlit. Then I would like to touch on these interesting moments and talk about them in more detail.
I would like to note once again that the attribute can be anything. All divisions of attributes into different categories are made for more comfortable perception by people. A PDP does not distinguish a subject attribute from an object attribute or an action attribute. The name of the attribute, its category, owner, and so on. For a PDP, it is just a key by which to find values for an unknown variable in a certain logical expression. So the possibility of using any attributes in the system is, in fact, limited only by the imagination of developers and, probably, technical resources. The main thing is that any PIP can return values for such attributes.
For example, business rules can often be found in which restrictions are imposed on both the current values of attributes of an entity and new ones at the same time. In other words, when trying to make changes to an entity, it is necessary to check the values of the attributes being modified before and after the intended change. Such a check can be embedded in the application logic where we know what entity and what attributes we want to change, what new values they will change. It will only be necessary to create a special PIP , which will be able to extract the old or new attribute value, based, for example, on the prefix in the attribute name (old or new). If the old entity values are missing in the current context, such a PIPmay be able to retrieve them from the repository based on the values of key attributes. Fortunately, all the necessary meta-information in the system should be.
For the convenience of the user, it is much better not to give him the opportunity to perform any action on the interface than after the fact to notify him of the impossibility of such implementation. If the user cannot perform any action, then it would be nice to deactivate the "forbidden" controls on the interface or hide them altogether. To do this, you can also use the access control system. It will be necessary to transfer the current context to it and, based on the solution obtained, to understand what to do with the controls.
The standard describes well the possibility of limiting the execution of an action, using rules of any complexity for this. But nothing is said about solving problems in which it is necessary to restrict access to viewing part of the data, that is, in fact, to filter this data. The solution to this problem falls on the shoulders of security system developers. If you look at an example of such business rules, you can see that they are the same logical expression as the business rules for accessing objects. Well, since this is a logical expression, it can be used as a predicate for querying data.
The first thing that comes to mind: PDP learning how to form a predicate from business rules for passing it, for example, to an ORM that can use it to get the right list of data. Difference from ordinarypolicies will be that the policies that describe the possibility of an action, are calculated in the presence of the values of all necessary attributes. While the values of all attributes for policies that describe data filtering will be known only during the filtering itself and the predicate applied to each specific object.
Of course, to make a predicate out of all business rules is excessive and, in principle, not necessary, since some attributes are still known before the formation of the predicate. So, it is possible, as in the standard case, to filter part of the business rules, leaving only the necessary ones. However, even one selected policy can be quite large. And given that the result of the policy calculationIt can take not two, but four values, the fact that PEP can be both resolving and forbidding , and the fact that there are different combination algorithms, you need to understand: from all this a giant predicate can form. Such a predicate will consist of a set of expressions combined by conditional AND and OR .
You can also try to solve this problem in several stages. At the first stage, you can substitute the values of all known attributes into the resulting predicate and calculate what happened. This can significantly reduce the predicate, since the values of all attributes must be known, except for the attributes of the object itself. At the second stage, you can try to simplify the remaining predicate using minimization of Boolean functions, for example, using the Quine – Mac Klaski method. After that, the predicate will be as compact as possible. And then everything will depend, for example, on the ability of the ORM to form a request and the ability of the database to process this request.
So, for example, a business rule:
Forms a predicate:
This predicate, after the substitution of values from the context, takes the form:
After simplification of which there will be only:
As noted above, for the access control system, the admin panel is the most important component. And this is not surprising.In addition to the task of creating and editing policies, it can solve a number of other equally important problems.
Let's start by editing the policy . If you look at the standard and examples of policies , it becomes clear that even fairly simple business rules written in XACML are difficult to understand and modify, especially without preparation. Even with some training, to change any more or less complex business rule in this form is rather problematic.
The admin panel can make life easier for the user in terms of editing policies , if he lets him set business rules in a simpler form, which he himself later turns into XACML. Also, the admin panel can solve a number of other equally important tasks.
A convenient and thoughtful policy editing interface plays an important role in the access control system. The closer to the human language the rules are set, the better they will be managed and supported. The interface should be as simple as possible, understandable and at the same time functional. This can mean the maximum possible abandonment of AND and OR constructs, as well as expressions in brackets, explicit indication of the type of attributes, etc. Everything that can be calculated or determined based on meta-information about attributes or policy structure can and should be removed from the interface , leaving only the necessary minimum for entering business rules, which should be as close as possible to the human language. For ease of entry, you can use technologies like IntelliSense, convenient drop-down lists, various hints. The main goal is to create an intuitive and user-friendly interface.
The conceptual illustration below shows the editing of the Order Creation policy. At the top of the window, the goal is indicated - to which this policy will be applied. The following is the algorithm for combining the rules - “ prohibited if not allowed ”. Below are three rules , consisting of the conditions that will be checked, and the effect that will be the result of each rule .
As mentioned above, sets of policies are needed for more convenient management and filtering. In this window, there is nothing particularly remarkable, but you should not forget about its existence.
The conceptual illustration below, in the left part of the window, shows a list of already created policies and sets of policies . Policy sets can be nested. In the right part of the window, the editing itself takes place For a set of policies, you can also set a goal - what the whole set will be applied to. Below is a list of what is included in the set. Below you can see an example of specifying the obligation - actions to send an e-mail message to the administrator in the event of a positive decision on granting access rights to the object. As you can see from the layout, existing attributes can be used for commitments , be it a user name or an object type. This provides ample opportunity to use commitments .
One of the problems that may arise may be the need to search for the policies or attributes involved in them. You can create a universal search box that will search in several categories at once, such as goal , rules and policies . Accordingly, without additional instructions, the search will occur in all categories and provide the result in the form shown in the conceptual figure below. In the displayed results, the searched words will be highlighted and that part of the rule ( goal ) in which the searched text is displayed.
One of the important tasks of the access control system is to search for actions available to the user. Such functionality can be claimed by security officers or administrators. Since the verification of access rights occurs dynamically and it is not known in advance exactly which policies are calculated positively, displaying such information may seem difficult. But this is not such a serious problem as it seems at first glance. After all, we already have the values of user attributes, and we can, at a minimum, select those policies that correspond to these values. In addition, for a clearer understanding or more accurate search, you can set the values of any other attributes of interest: specify the necessary context or part of the context and see what is available for such attribute values. Moreover, it is possible to display those policies that have come up partially. For them, you can show the remaining conditions necessary for their implementation.
Another important problem may be misunderstanding why this or that policy is calculated in this way, and not otherwise, despite the fact that, in the opinion of the administrator, everything had to be executed differently. The situation when the policy is set, all attributes are specified correctly, but there is still no access, it can be very unpleasant. Given that politicians or groups of policies can consist of many logical conditions, manual analysis of this problem can be tedious and fraught with errors. Since policies consist of many conditions that are calculated gradually, the process of this calculation can be visualized. The administrator can specify the desired context, select policies and step through the calculation process using a user-friendly interface.
Integration can be performed with both existing and new applications.
Integration with new applications should be fairly straightforward. Since the developers will initially know about the attribute model, think in its terms, they will be able to immediately develop as needed. In order for everything to work well, you need to implement two basic things. First, it is necessary that the system has all the necessary meta-information about the attributes. This meta information may include the name, type, available values, localization.
Secondly, it is necessary that the PEPs are properly embedded in the application. Typically, a PEP is embedded in the application logic, somewhere before calling a business logic. If it is good to fill the system with meta-information and correctly place the PEP, then if the business rules change and, accordingly, the politician, no involvement of programmers will be required. Even for previously unknown and unplanned business rules.
Integration with existing applications may occur in different ways. Most applications now use a role-based, one-dimensional access model and switching to an attribute, multi-dimensional model can be difficult. Going directly from the role model to the attribute model can be very difficult, expensive, or even impossible for a number of reasons. If such a transition is still possible, then the principle of action will be the same as for integration from scratch. We'll have to fill the attribute model with meta-information and embed PEP in all the necessary places.
If such a transition is not possible, you can try to act in several stages. At the first stage, it is necessary to build an attribute model over the role model. The point is that the add-in transforms the role model into an attribute model, allowing you to set business rules in an attribute style and turn it back into a role model. Yes, at first it may seem strange. But this approach can bring a number of advantages of the attribute model and remove a number of minuses of the role model. And at the second stage, it will be possible to slowly, in some places, abandon the extra layer in the form of a role model and fully switch to the attribute model.
A detailed analysis of both cases is quite extensive and is beyond the scope of the current article.
I hope that an introduction to the problematics and familiarity with the XACML standard will help readers to take a closer look at ABAC and better understand how it works, and the points touched upon outside the standard will take into account various aspects of this area that can provide support in the transition to ABAC.
The standard is experiencing the third and, most likely, not the last edition, its history dates back to 2003. He oversees and supports the standard organization of OASIS . This standard describes the necessary system components, their purpose, the way they interact and use. In fact, it covers everything you need, to the smallest detail.
This article will look at how to express business rules in the form of security policies, the main components of a security system, its integration and other aspects that are not affected by the standard, but are equally important and interesting. I invite all readers to get acquainted with these issues in more detail. Any comments, comments, questions and criticisms are also welcome.
Security policies
Rule
Policy
Policy set
The main components of the system
Policy Administration Point
Policy information point
Policy decision point
Policy Enforcement Point
Example
What's left overs
Outside the standard
Attribute can be any
Interface and Authorization Check
Data filtering
Admin panel concept
Editing policies
Editing a policy set
Policy search
Actions available in the specified context
Testing policy execution
Application Integration
Afterword
')
We will begin our review of the standard with an overview of changes in business rules and continue with an overview of the tools and ways to handle these business rules.
Security policies
Any business rule that is responsible for the possibility of performing an action or access to an object answers the question “Is there access?” And gives one of two answer options: “Yes” or “No”. And the condition of such a business rule is reduced to a set of logical expressions, the calculation of which gives one of two possible answers. Therefore, security policies are a logical expression that operates on attributes and constant values.
Let's start with a closer look at the security policies themselves and how the standard describes them.
Although this scheme from the standard may look a bit intimidating at first glance, everything is quite simple in it. The picture shows the hierarchy of basic XACML objects used to express business rules. The elementary particle of hierarchy is the rule ( rule ). Rules are combined into policies ( policy ), which, in turn, are combined into sets of policies ( policy set ).
Rule
As described in the standard, a rule cannot live by itself, it must necessarily be included in the policy . This means that the mechanism for calculating access rights operates with rules only in the composition of policies and nothing else. Nevertheless, the rule is the most saturated element in terms of business sense.
The rule itself consists of several parts:
- target ( target );
- effect
- condition;
- obligation ( obligation );
- recommendations ( advice ).
The goal is the same for both rules , policies and policy groups . Therefore, the description here is true for them. A goal is a logical expression that should consist only of attributes and constants. The goal is usually made that part of the business rule that meets this requirement. The main point of dividing a business rule into parts is to quickly sift out inappropriate rules , policies, or groups of policies . For what it is needed - will be discussed in more detail in the description of the PDP .
The rest of the business rule (if there is one) containing a more complex, dynamically calculated logical expression must be placed in another part of the rule - the condition ( condition ). Those elements that can be specified in the condition , their format and everything connected with them are also described in detail in the standard, but their analysis is beyond the scope of this article.
Business rules can be either permissive or prohibitive. To indicate this, there is another part in the rule - the effect. It can be either “ permit ” or “deny” ( deny ). The most important thing to know is that the effect of the rule works only in the case of a positive calculation ( evaluate ) of this rule . That is, the effect is applied only in the case when the result of the calculation of the logical condition in the target and in the condition is “true” ( true ). In the case when the result of evaluating a logical expression of a goal or condition is false , the result of the rule evaluation will be “not applicable” ( not applicable ). If in the process of calculating the logical condition of the goal or condition an error occurred, the result of the rule evaluation will be “ indeterminate ”. Thus, the result of the rule calculation can be one of four values: “ allow ”, “ prohibit ”, “ not applicable ”, “ not defined ”.
Consider the example of the formation of a fairly simple rule .
The first logical condition is a comparison of an attribute with a constant, and it is better to place it in the target of the rule (although it is possible to put it in a condition ). The second logical condition is a comparison of two attributes. It can only be placed in the condition of the rule . Since the business rule is permissive, the effect will be defined as “ allow ”. As a result, we get this rule :
In addition to the function of deciding whether to grant access rights to the security system, additional functional requirements may be imposed. An example of such a function might be a security audit. To solve this kind of problems in the standard there are obligations and recommendations . By and large, the difference between them lies only in the fact that the obligations must necessarily be fulfilled, and the recommendations can be ignored. Both obligations and recommendations describe the effect of the rule to which they apply, the action to be performed, and the expressions for obtaining the parameters of this action based on the current context.
Consider the example of a simple commitment. If there is a requirement for the security system to send an email to the owner of the object when someone interacts with it, then for this you can make a commitment that will look like this:
As a recommendation , for example, a description of the action of logging some information for debugging purposes can be specified.
Policy
A policy is used to merge a set of rules . Typically, a set of such rules is one business rule. Thus, several tasks are solved at once. First, small portions of the logical conditions expressed in the rules can be easily reused without duplicating these conditions. Secondly, such a division into parts facilitates the understanding of the entire business rule and simplifies its maintenance.
The policy consists of:
- targets ( target );
- rules;
- rule combination algorithm ;
- obligations ( obligation );
- recommendations ( advice ).
As mentioned earlier, the goal is needed to quickly screen out inappropriate policies . For what it is needed - will be discussed further in the PDP review.
The rule set simply lists all the rules included in this policy . The result of the policy calculation is one particular value, as is the case with the rules . This means that from the results of the evaluation of all the rules included in the policy it is necessary to obtain only one of the four available values. To obtain such a value from the results of the calculation of all rules , the policy combination algorithm applied for the policy is applied. The standard defines several different algorithms that may be useful in different situations. For example, "prohibited if not allowed" ( deny-unless-permit ). This algorithm will return the value " allow " only if the result of the calculation of at least one rule is " allow ". If the result of the evaluation of all the rules was a set of other values (“ prohibit ”, “ not applicable ”, “ not defined ”), this combination algorithm will return “ prohibit ”.
The standard also lists much more complex combination algorithms that introduce additional notions of the results of rule evaluation. Such an example would be the result that sounds like “not determined, but could be resolved” ( indeterminate {D} ), which refers to those rules during the evaluation of which an error occurred, and their effect in the case of a successful evaluation would be “ prohibit ” .
Consider an example of a policy based on a simple business rule.
This business rule can be broken into pieces and form from it two simple rules that can be combined into a policy .
Obligations and recommendations are discussed a little higher in the description of the rule .
Policy set
A set of policies is needed to merge a group of policies for the purpose of their faster filtering based on a general purpose specified in the policy group goal . It can also be applied when there are extremely complex business rules for additional division into components. A set of policies in their constituent parts is very similar to ordinary politics . The only difference is that in the case of a set of policies , policies , not rules , are combined, and that the standard offers a slightly different set of combination algorithms for policies than for rules .
A set of policies consists of:
- targets ( target );
- politician ( policies );
- the policy combination algorithm ( policy-combine algorithm );
- obligations ( obligation );
- recommendations ( advice ).
The only thing that should be noted is that the standard describes both the same and different combination algorithms for policies and groups of policies .
Let's look at an example of a set of policies using a set of business rules.
Three similar policies will be formed from these three business rules.
- Document creation policy.
- Document change policy.
- Document deletion policy
All of these rules have something in common: they describe the availability of actions on the same type of object and, moreover, at a certain time. Therefore, we can combine them with complete confidence in a set of policies .
Obligations and recommendations are discussed a little higher in the description of the rule .
So, we figured out how the standard proposes to turn business rules into elements that are understandable to the security system. Now consider what components the security system itself consists of and how it handles these business rules.
The main components of the system
The policy calculation mechanism is the central component of the system and is referred to as the Policy Decision Point ( PDP ) in the standard.
In order to calculate security policies, they need to be created somewhere. Another component of the system is responsible for this — the policy administration mechanism, called the Policy Administration Point ( PAP ) in the standard. Another source of data needed by the PDP for computing is the source of attribute values, called the Policy Information Point ( PIP ). Last but not least, the component is the mechanism responsible for calling the PDP and correctly processing its response, which is called the Policy Enforcement Point ( PEP ).
Policy Administration Point
This is the component in which the security policies are managed. As a rule, it is a kind of interface that allows the system administrator to turn business rules into policies and make them accessible to the PDP . In order to be able to manage policies with PAP , he needs to know the following things:
- policy structure to be able to control the correctness of input;
- a list of functions that can be specified in logical conditions;
- a list of attributes that can be specified as function arguments in logical conditions.
About the structure of policies already mentioned above, and a more detailed description of them is given in the standard. As for the functions, some of their list is already described in the standard, as described and the logic of their behavior. In addition, the standard implies the ability to add your own arbitrary functions. Therefore, if necessary, to form a final list of functions available for use, you may have to receive part of this list from somewhere.
Regarding the attributes in the standard also says a lot. The issue of typing and naming attributes is mainly addressed. Attributes themselves, as a rule, represent something specific for a business, therefore for each system this list will be its own. This means that the system must somehow be able to provide the necessary information. It is also good to provide information on what values may be available to certain attributes in order to be able to check the constants specified in the rules . It is worth remembering that attribute names may require localization. This means that in addition to the name of the attribute and its type, you must also provide a display name that can be localized. This will allow you to display policies in different languages without modifying the policies themselves.
From a security point of view, PAP does not play a key role. But from a security management point of view, this is one of its most important places. Now we have touched only the purpose of this component. We will look at its potential for managing the security system later .
Policy information point
As mentioned above, two things are needed for a PDP to work: the source of security policies and the source of attribute values. We have just talked about the first, and now let's talk about the second. The principle of operation of the PIP , at first glance, is quite simple. At the input it receives the name of the attribute, and at the output it gives all the values that it can find for it in the current execution context. The whole complexity of PIP lies in its internal structure, in how and where it is able to search for attribute values.
If the access control system is built into the application itself, and the PIP is able to search for attribute values among the current objects of the application, then it can, for example, translate the attribute name to the path to the object property and extract the value of this property. If the access control system is located as a separate service and accepts external calls, the PIP may be able to extract attribute values from this call. Or, the PIP can be able to retrieve current environment settings such as time, date, ip-addresses, etc. Also, PIP can be able to “walk” to any storage and look for attribute values there. In general, everything here is limited only by the imagination of the developers of the access control system.
Policy decision point
For access control systems, this is probably the central component. This is where policies are calculated based on the current call context. It is very important to understand that the PDP operates on attributes only. An attribute from the point of view of a PDP is a common key by which it is necessary to find a value and substitute it in a calculated expression. He does not know anything and should not know about the fact that there are actions, users, environment, objects. Understanding this will allow you to use the full power of the access control system correctly and with maximum efficiency.
Most likely, the question may immediately arise: how does the PDP understand what security policy it needs to calculate in the context of the current action if it does not make any distinction? The answer is quite simple: no way. He simply calculates all available policies and on the basis of this forms his decision. This may seem like a crazy idea, at least in terms of performance, but if you look at this in more detail, everything falls into place.
First of all, it’s terrible to compute thousands of rules every time you check access rights. Thinking in categories of thousands is caused by the fact that in large systems the number of roles is usually calculated by such orders. But politicians are not roles. Dozens of well-designed policies can replace thousands of roles. So you need to think here in other ways. In addition, as already mentioned when considering the structure of policies , the goal envisaged in their structure is intended for quick filtering of policies that are not suitable for the current context. In fact, only policy units will be calculated. In general, various optimization methods can be applied here, which also depends on the vastness of imagination and resources.
In order to understand which policies are applicable at the moment, the PDP must calculate the goal of each of them, substituting the current values of the specified attributes there. PDP uses PIP to find them. Since the search logic in PIP can be different, the whole PIP collection can be used at the same time, where each PIP will look for the values of the specified attribute, guided by its own logic. The PDP simultaneously polls all its PIPs to find the desired attribute, and from the responses it forms an array of received values. In the standard, everything is focused on the fact that for each attribute an array of values of a previously unknown size can return. In the case when several policies or groups of policies are calculated in the current context, the result of their calculations is also combined with the combination algorithm predefined for PDP .
Along with other elements, rules , policies, or groups of policies may have obligations or recommendations . They consist of expressions that calculate the values of some attributes that will be passed to the PEP as part of the response. And their calculation can affect the result of the calculation of the rule itself , policy or group of policies .
Only those obligations and recommendations are calculated , the purpose of which coincides with the effect obtained from the calculation of their rules and policies.or policy groups . If the calculation of the attribute value of the commitment or recommendation ended with an undefined result, the result of the calculation of the corresponding rule , policy, or group of policies will also become undefined .
The result of all calculations should be a response that contains a decision on access, which can take one of the four values already described above: “ allow ”, “ deny ”, “ not applicable ”, “ not determined ”. In addition, the response may contain a list of obligationsor recommendations . It should be noted that the standard describes all the conditions under which the final list of obligations or recommendations should be formed .
Policy Enforcement Point
The PEP is both the starting point and the ending point for all access control actions. The duties of the PEP as a starting point include preparing the request and calling the PDP . In essence, the PEP is responsible for transferring the current execution context to the PDP . The current context may include attributes related to the entity performing the action (name, title, department, branch), to the action (name of the action), to the action object (type, number, owner), to the environment (day of the week, date, ip-address). All of these attributes are aggregated and transmitted to the PDP .
As a final point, the PEP is responsible for receiving the response from the PDP., its interpretation and correct execution. Since the decision to grant access can take one of four values, the PEP must be able to turn them into two (“ allow ” or “ deny ”). Depending on the algorithm for interpreting values, PEP is divided into two types. Enable ( Permit based ) the PEP operates on the principle "everything that is not explicitly forbidden." This means that only in case of a negative decision will access be denied. In the other three cases, access will be allowed. Forbidding ( Deny based ) PEPacts according to the principle “Everything that is not explicitly permitted” is prohibited. This means that only in case of a positive decision will access be allowed. In the other three cases, access will be denied.
In addition to the decision to grant access, the response from the PDP may contain a list of obligations and recommendations that the PEP must comply with. As mentioned above, the obligations and obligations that their application is necessary. And this leaves an imprint on the execution of the decision received from the PDP . If the PEP does not understand how to fulfill the obligation , then, depending on the type of PEP, it will either cancel the ban, or cancel the permission. If the PEP is resolving , the decision to “ deny ” has come from the PDP , and it is impossible to fulfill the obligation , then the PEP will allow execution. It works the way it would have worked if it received an “ undefined ” solution . Conversely, if the PEP is prohibiting , the value of the decision coming from the PDP is “ allow ”, and the obligation cannot be fulfilled , the PEP will prohibit the execution. It works as if the decision from the PDP was “ undefined ”. Recommendations , in turn, may not be implemented, and this will not affect the decision to grant access.
Example
Consider an example of an access control system in the case of an application consisting of a client, an application server and the main components of an access control system.
- Each application has its own unique business model. This model is filled with objects, their attributes, etc. These attributes are the source of data for the attribute model of the access control system.
- Based on this model, policies and groups are created in PAP that use these attributes.
- Policies and groups of policies created in PAP are stored in a repository that the PDP will access.
- () - , . , -, .
- PEP , (, , . .) PDP.
- PDP .
- PDP PIP , .
- PIP, , , , PEP. PIP - , ( , ).
- PIP PDP.
- , PDP , . , PDP .
- PEP .
- The PEP analyzes the response received, fulfills obligations and recommendations and, in the event of a positive decision, passes the call to the business logic.
What's left overs
As the standard covers every detail, in this article small details were omitted. In the standard, much attention is paid to the description of those expressions that can be specified as a condition of the rule. What features should be? What types of data can be? How should these functions be calculated? What are the categories of attributes? What are some combination algorithms? All this - the details that should not affect the understanding of the overall picture. Yes, and a detailed analysis of them already has little concern with ABAC itself, rather with technical details of the implementation.
Outside the standard
The standard describes a lot, down to the smallest details, but some moments still remain unlit. Then I would like to touch on these interesting moments and talk about them in more detail.
Attribute can be any
I would like to note once again that the attribute can be anything. All divisions of attributes into different categories are made for more comfortable perception by people. A PDP does not distinguish a subject attribute from an object attribute or an action attribute. The name of the attribute, its category, owner, and so on. For a PDP, it is just a key by which to find values for an unknown variable in a certain logical expression. So the possibility of using any attributes in the system is, in fact, limited only by the imagination of developers and, probably, technical resources. The main thing is that any PIP can return values for such attributes.
For example, business rules can often be found in which restrictions are imposed on both the current values of attributes of an entity and new ones at the same time. In other words, when trying to make changes to an entity, it is necessary to check the values of the attributes being modified before and after the intended change. Such a check can be embedded in the application logic where we know what entity and what attributes we want to change, what new values they will change. It will only be necessary to create a special PIP , which will be able to extract the old or new attribute value, based, for example, on the prefix in the attribute name (old or new). If the old entity values are missing in the current context, such a PIPmay be able to retrieve them from the repository based on the values of key attributes. Fortunately, all the necessary meta-information in the system should be.
Interface and Authorization Check
For the convenience of the user, it is much better not to give him the opportunity to perform any action on the interface than after the fact to notify him of the impossibility of such implementation. If the user cannot perform any action, then it would be nice to deactivate the "forbidden" controls on the interface or hide them altogether. To do this, you can also use the access control system. It will be necessary to transfer the current context to it and, based on the solution obtained, to understand what to do with the controls.
Data filtering
The standard describes well the possibility of limiting the execution of an action, using rules of any complexity for this. But nothing is said about solving problems in which it is necessary to restrict access to viewing part of the data, that is, in fact, to filter this data. The solution to this problem falls on the shoulders of security system developers. If you look at an example of such business rules, you can see that they are the same logical expression as the business rules for accessing objects. Well, since this is a logical expression, it can be used as a predicate for querying data.
The first thing that comes to mind: PDP learning how to form a predicate from business rules for passing it, for example, to an ORM that can use it to get the right list of data. Difference from ordinarypolicies will be that the policies that describe the possibility of an action, are calculated in the presence of the values of all necessary attributes. While the values of all attributes for policies that describe data filtering will be known only during the filtering itself and the predicate applied to each specific object.
Of course, to make a predicate out of all business rules is excessive and, in principle, not necessary, since some attributes are still known before the formation of the predicate. So, it is possible, as in the standard case, to filter part of the business rules, leaving only the necessary ones. However, even one selected policy can be quite large. And given that the result of the policy calculationIt can take not two, but four values, the fact that PEP can be both resolving and forbidding , and the fact that there are different combination algorithms, you need to understand: from all this a giant predicate can form. Such a predicate will consist of a set of expressions combined by conditional AND and OR .
You can also try to solve this problem in several stages. At the first stage, you can substitute the values of all known attributes into the resulting predicate and calculate what happened. This can significantly reduce the predicate, since the values of all attributes must be known, except for the attributes of the object itself. At the second stage, you can try to simplify the remaining predicate using minimization of Boolean functions, for example, using the Quine – Mac Klaski method. After that, the predicate will be as compact as possible. And then everything will depend, for example, on the ability of the ORM to form a request and the ability of the database to process this request.
So, for example, a business rule:
Forms a predicate:
This predicate, after the substitution of values from the context, takes the form:
After simplification of which there will be only:
Admin panel concept
As noted above, for the access control system, the admin panel is the most important component. And this is not surprising.In addition to the task of creating and editing policies, it can solve a number of other equally important problems.
Let's start by editing the policy . If you look at the standard and examples of policies , it becomes clear that even fairly simple business rules written in XACML are difficult to understand and modify, especially without preparation. Even with some training, to change any more or less complex business rule in this form is rather problematic.
An example of a very simple rule in & nbsp; XACML format
<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" PolicyId="urn:oasis:names:tc:xacml:3.0:example:SimplePolicy1" Version="1.0" RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides"> <Description>Medi Corp access control policy</Description> <Target/> <Rule RuleId= "urn:oasis:names:tc:xacml:3.0:example:SimpleRule1" Effect="Permit"> <Description> Any subject with an e-mail name in the med.example.com domain can perform any action on any resource. </Description> <Target> <AnyOf> <AllOf> <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">med.example.com</AttributeValue> <AttributeDesignator MustBePresent="false" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"/> </Match> </AllOf> </AnyOf> </Target> </Rule> </Policy> The admin panel can make life easier for the user in terms of editing policies , if he lets him set business rules in a simpler form, which he himself later turns into XACML. Also, the admin panel can solve a number of other equally important tasks.
Editing policies
A convenient and thoughtful policy editing interface plays an important role in the access control system. The closer to the human language the rules are set, the better they will be managed and supported. The interface should be as simple as possible, understandable and at the same time functional. This can mean the maximum possible abandonment of AND and OR constructs, as well as expressions in brackets, explicit indication of the type of attributes, etc. Everything that can be calculated or determined based on meta-information about attributes or policy structure can and should be removed from the interface , leaving only the necessary minimum for entering business rules, which should be as close as possible to the human language. For ease of entry, you can use technologies like IntelliSense, convenient drop-down lists, various hints. The main goal is to create an intuitive and user-friendly interface.
The conceptual illustration below shows the editing of the Order Creation policy. At the top of the window, the goal is indicated - to which this policy will be applied. The following is the algorithm for combining the rules - “ prohibited if not allowed ”. Below are three rules , consisting of the conditions that will be checked, and the effect that will be the result of each rule .
Editing a policy set
As mentioned above, sets of policies are needed for more convenient management and filtering. In this window, there is nothing particularly remarkable, but you should not forget about its existence.
The conceptual illustration below, in the left part of the window, shows a list of already created policies and sets of policies . Policy sets can be nested. In the right part of the window, the editing itself takes place For a set of policies, you can also set a goal - what the whole set will be applied to. Below is a list of what is included in the set. Below you can see an example of specifying the obligation - actions to send an e-mail message to the administrator in the event of a positive decision on granting access rights to the object. As you can see from the layout, existing attributes can be used for commitments , be it a user name or an object type. This provides ample opportunity to use commitments .
Policy search
One of the problems that may arise may be the need to search for the policies or attributes involved in them. You can create a universal search box that will search in several categories at once, such as goal , rules and policies . Accordingly, without additional instructions, the search will occur in all categories and provide the result in the form shown in the conceptual figure below. In the displayed results, the searched words will be highlighted and that part of the rule ( goal ) in which the searched text is displayed.
Actions available in the specified context
One of the important tasks of the access control system is to search for actions available to the user. Such functionality can be claimed by security officers or administrators. Since the verification of access rights occurs dynamically and it is not known in advance exactly which policies are calculated positively, displaying such information may seem difficult. But this is not such a serious problem as it seems at first glance. After all, we already have the values of user attributes, and we can, at a minimum, select those policies that correspond to these values. In addition, for a clearer understanding or more accurate search, you can set the values of any other attributes of interest: specify the necessary context or part of the context and see what is available for such attribute values. Moreover, it is possible to display those policies that have come up partially. For them, you can show the remaining conditions necessary for their implementation.
Testing policy execution
Another important problem may be misunderstanding why this or that policy is calculated in this way, and not otherwise, despite the fact that, in the opinion of the administrator, everything had to be executed differently. The situation when the policy is set, all attributes are specified correctly, but there is still no access, it can be very unpleasant. Given that politicians or groups of policies can consist of many logical conditions, manual analysis of this problem can be tedious and fraught with errors. Since policies consist of many conditions that are calculated gradually, the process of this calculation can be visualized. The administrator can specify the desired context, select policies and step through the calculation process using a user-friendly interface.
Application Integration
Integration can be performed with both existing and new applications.
Integration with new applications should be fairly straightforward. Since the developers will initially know about the attribute model, think in its terms, they will be able to immediately develop as needed. In order for everything to work well, you need to implement two basic things. First, it is necessary that the system has all the necessary meta-information about the attributes. This meta information may include the name, type, available values, localization.
Secondly, it is necessary that the PEPs are properly embedded in the application. Typically, a PEP is embedded in the application logic, somewhere before calling a business logic. If it is good to fill the system with meta-information and correctly place the PEP, then if the business rules change and, accordingly, the politician, no involvement of programmers will be required. Even for previously unknown and unplanned business rules.
Integration with existing applications may occur in different ways. Most applications now use a role-based, one-dimensional access model and switching to an attribute, multi-dimensional model can be difficult. Going directly from the role model to the attribute model can be very difficult, expensive, or even impossible for a number of reasons. If such a transition is still possible, then the principle of action will be the same as for integration from scratch. We'll have to fill the attribute model with meta-information and embed PEP in all the necessary places.
If such a transition is not possible, you can try to act in several stages. At the first stage, it is necessary to build an attribute model over the role model. The point is that the add-in transforms the role model into an attribute model, allowing you to set business rules in an attribute style and turn it back into a role model. Yes, at first it may seem strange. But this approach can bring a number of advantages of the attribute model and remove a number of minuses of the role model. And at the second stage, it will be possible to slowly, in some places, abandon the extra layer in the form of a role model and fully switch to the attribute model.
A detailed analysis of both cases is quite extensive and is beyond the scope of the current article.
Afterword
I hope that an introduction to the problematics and familiarity with the XACML standard will help readers to take a closer look at ABAC and better understand how it works, and the points touched upon outside the standard will take into account various aspects of this area that can provide support in the transition to ABAC.
Source: https://habr.com/ru/post/258861/
All Articles