Friends who study rights management and access control implementation principles should know that RBAC (Organization for the Advancement Of Structured Information Standards) is one of the active organizations that drive RBAC-related standards. OASIS's Xacml (Extensible Access Control Markup Language), the extended access control high mark is important standard. Understand, and understand the mechanism of its design is very meaningful to us. This article is a draft for translation of OASIS "a brief introduction to xacml". Writing here, I hope to help others.
A brief introduction to Xacml
Introduction to a Xacml
Last updated: March 14, 2003
Summary:
This article makes a brief introduction to Xacml. For more information on Xacml, please visit Oasis's Xacml Technical Committee website.
Briefly, Xacml is a universal access control policy definition language. XACML provides a syntax (using XML definition) to manage access to system resources.
A brief introduction to Xacml
Introduction to Xacml
Xacml is an OASIS standard. This standard is a description (access control) policy language, and is also a language describing access control judgment request / response / response. Of course, it is use XML. Policy Description Language is used to define universal access control requirements, including several standard extensions to define new features, data types, combined logic, and more. (Access Control Judgment) Request / Response Description Language allows you to configure a query to determine if an action is allowed to execute, and interpret the results. Access requests typically include issues requested to be allowed, including four parameters: permit, deny, indeterminate (error occurrence or parameter values required, unable to judge) and NOT Applicable (this request cannot be subject to this server Respond)
Typical mechanisms is this: When someone tries to perform a resource action. A request that requests to act in fact protecting the resource (possibly a file system or web server), which is referred to as PEP (Policy Enforcement Point, Policy Force Perform Point). PEP will form a request based on the requester's properties, request resources, action, and other accessory information. The PEP then sends the request to the PDP (Policy Decision Point, Policy Judgment Point). The PDP will check the request and some (access control) policy information about the request and eventually answer whether the access is recognized. This answer returns to the PEP, which is allowed or rejected by the PEP. Note: PEP and PDP may be included in the same application presentation, or may be distributed to different services. In addition to the language as a request / response and policy description language, XACML also provides some other relationship description:
There are a lot of similar application definition languages to do this type of task. But Xacml has a few advantages:
Xacml is a standard. The standard has passed a large number of experts and users to review, and developers no longer need to reconsider each time, and do not need to consider many factors that need to define a definition language. In addition, the more deployment of XACML is largely deployed, the more you can easily interact with other application systems through standard languages. Xacml is common. This means that you can use in most environments, not just in some special environments or can be used for special resources. Once an access control policy is written, you can use many different types of applications. When using a more common language to implement, the management of access control policies has also become simple.
Xacml is distributed. This means that an access control policy can be written as other strategies that reference to other anywhere. The benefits of it can be within the respective business scope of different users or groups, or sub-strategies within the professional field, and finally merged into total policies, rather than centralizing an integrated access control policy. Handle how to correctly merge different sub-policy judgment results and make unified access controls by Xacml.
Xacml is powerful. Because of several basic language-based extension methods, it is no longer necessary for multi-environment considerations. Standard languages have supported a wide range of data types, functions, and rules that merge with the results of the policy judgment. In addition, there have been several standard teams to develop extensions and profiles to make XACML can work with other standards such as SAML and LDAP. This makes Xacml to get a wider range of applications.
To show how to cooperate with each other, the next is a discussion of the XACML access control policy and demonstrates several standard characteristics of the language. Note that XACML is a rich language, so there is only a few special features in this article. You can learn more about the XACML feature by browsing "Defining Documents".
Top-Level Constructions: Policy and Policyset
Top-level structure: policy and policyset (strategy and policy set)
The root of all XACML access control policies is Policy or PolicySet. A policyset is a container that can accommodate other Policy or PolicySet, which can be referenced to non-local Policy or PolicySet. A policy is a reference to a single access control policy, which is manifested by a set of rules. Each XACML Access Control Policy Document contains a unique policy or policyset root in its XML tag.
Because a policy or policyset can contain multiple policies or rules. Since these policies or rules have different access control judgment results, XACML requires a method of coordinated judgment results. This is achieved in XACML through a set of combining algorithms. Each algorithm represents a different method of combining multi-judgment results to a single judgment result. Xacml has "Policy Component / Policy Combining Algorithms" and "Rule Merge Algorithm / Rule Combining Algorithms". One of this is "Deny Overrides Algorithm", which represents the result of other policy determinations, as long as one of the policies or rules determine the return result DENY, the final judgment result is determined to be DENY. These merge algorithms can be used to construct complex strategies. In addition to the seven standard merge algorithms, you can construct your own merge algorithm to meet your needs.
Targets and rubes
Goals and rules
Some of the Xacml PDP to do is based on a request to find a corresponding policy. To achieve this, Xacml provides another feature called Target. A Target basically is a set of simplified POLICY, POLICYSET, and RULE, which must be encountered in a request. Subject, action, resource, and resource. These conditional restrictions use Boolean judgments (which will be described in the next section) to compare the parameter values in a request and the condition corresponding to the condition in Target. If all the conditions in a Target are compliant, the request is associated with the corresponding policy, policyset, and rule. As a method of checking the applicability, there is a method of policy index in the information of Target. This is useful when you need to store multiple policies in the same target and require quick review of these policies to select the most appropriate policy. For example, a policy may contain a target that is only available for a specific service. When a request to access the service occurs, the PDP knows where to find a strategy that is suitable for judging the request. Since the strategy is indexed by the restrictions based on their Target. Note that Target can also be defined as all requests. Once Policy is found and used to verify a request, the rule (Rule) acts. Policy can accommodate any number of Rule, which contains core logic of XACML policies. Most Rule performance is a conditional Boolean judgment. When the current condition is true, "the result of the rules / rule's effect" is returned. The judgment result of the condition can also be an error (ie "not clear / indeterminate") or the condition is not suitable for judging requests (ie "not suitable for / notApplicable"). One condition can be very complicated, as: judges from a series of nested non-Brooled functions or attributes.
Attributes, Attribute Values, And Functions
Property, attribute values, and functions
Xacml is processed attributes. Attributes are known types of values, which may include the identity of the attribute definition or definition date. Specific, attributes are the eigen values of the environment of Subject, Resource, Action, or access request. One user name, access to intermittent, tried accessible files, access date, etc. may become attribute values. When a request is sent from the PEP to the PDP, the request is constituted a attribute extension and is used to compare with attribute values in the policy and eventually generate access control results.
Policy analyzes the attribute values from the request or other source (other policy) in two mechanisms: AttributeSignator and AttributeSelector. AttributeDesignator allows policy definitions to define properties with a name and type while providing a publisher (Issuer) option. The PDP then looks for the value of the property in the request, or determines if the value value can be found in the request. A total of 4 indicators (Designator), four types of properties in requests: Subject, Resource, Action, and Environment. Because the Subject property can be split into a different directory, SubjectAttributeSignators can also define a directory to query. AttributeSelectors makes a policy query a property value in the form of XPath Query. As long as a data type and an XPath expression are provided, the attribute value in the request document can be parsed.
AttributeDesignator and AttributeSelector can return a multi-value (because there may be a case where a request matching multiple conditions), so XACML provides a special attribute called "Bag", and BAG is a disorderly collection and allows repetition. Usually Designator and Selector return BAG, even when only single value is returned, it is returned in BAG. When no match is an empty BAG. Of course, Designator and Selector can set a tag that generates an error when this condition occurs. When the attribute value BAG is acquired, it is necessary to compare it to obtain the expected access control license decision via a method. This feature is implemented by a powerful system function. The function set can be operated as a parameter in any attribute value, and can return any type of attribute value supported by the system. The function set also supports nested, so the additional function is called using the result of the function, so that nesting can be complicated. The secondary development function can provide a richer language to express access conditions.
Some functions are defined as a specific data type (eg String and Integer et al.). To deal with this problem, Xacml defines a set of standard constituent type unique functions ([type] -one-only function), uses these functions, if there is only one value in the BAG, the function accepts special in BAG Type value and return a single value, or when there is no value or more value in BAG. This is the most common class of functions in condition. The [Type] -one-And-ONLY function is not required in the Target, because the PDP automatically corresponds to each element of the BAG.
Putting it together: an esample policy
A policy example
The following is an example of a Policy using the features discussed above. Its Target specifies that Policy acts only on the Request to send access requests to the "SampleServer" service. Its Policy has a Rule with Target, which needs to be triggered by "login" action and a condition. This condition is suitable for "login" when Subject attempts at 9:00 AM to 5:00 PM. Note that this lychee can be extended to include other Rule of different actions. When the first Rule is not applicable, a default rule returns a DENY result. (Rule is in order)
Beegee:
