Core Security Patterns: Identity Management Standards and Technologies

This chapter is from the book

Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Learn More Buy

This chapter is from the book

This chapter is from the book 

Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Learn More Buy

Introduction to XACML

eXtensible Access Control Markup Language (XACML) version 2.0 (refer to [XACML2] for details) is an approved security policy management standard under OASIS (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml). It is both a policy language and an access-control decision request/response _language encoded in XML. It defines a standard format for the expression of authorization rules and policies along with a standard way of evaluating rules and policies to produce authorization decisions. In addition, XACML defines an optional format for making authorization decision requests and responses.

There are many similarities between XACML and the other policy management initiatives discussed previously. XACML can handle both XML documents and non-XML systems, though it can also handle non-XML objects using a custom context handler. It uses a declarative data model similar to CIM policy. It is generic to all industry sectors, but flexible enough to include new functionalities. XACML is complementing SAML 2.0 by providing functionality that handles complex policy sets and rules.

There are a few business problems related to security access control today. Many customer environments have their own security policy governing which resources a service requester can access. To be flexible and adaptive to customer IT security requirements, commercial off-the-shelf vendor products intend to be “generic” enough to support different security access control requirements in heterogeneous or customized environments. For example, some vendor products choose to provide “maximum possible privilege” by default for accessing data and executing business functions and actions. In other words, every user can access all functions unless the access control policies are customized. Once these vendor products are implemented, customers can customize local administrative security policy and configure policy enforcement points. Unfortunately, customized security access control implementations are fairly expensive, and they are unreliable for modifying security policies manually due to their complexity. In addition, they are not scalable and timely if the number of applications or policy enforcement points is large. Thus, a flexible policy system for access control is required to address these problems.

Isn’t SAML authorization decision assertion used in determining access rights for a service request? SAML provides a very basic assertion format and protocol between policy enforcement point and policy decision point. However, it does not specify any action or how a policy decision point should get information on which its decision will depend.

One major technology driver for creating XACML is the need to access partial content of XML documents. The current security method is to use encryption to control access to the entire XML document. Users are either authorized to view the entire XML document or denied access to any part of it. An example is an XML document containing a credit card payment transaction, where user A (call center personnel) is authorized to access the entire payment transaction except the full credit card number, while user B (claims department) is able to read the entire payment transaction. This is undesirable and very often this access control mechanism does not meet local business requirements.

In a typical application environment, a user wants to make request to access certain resources. The Policy Enforcement Point (PEP) is a system or application that protects the resources. The PEP needs to check whether the service requester is eligible to access the resources. It sends the resources request to the Policy Decision Point (PDP), which looks up the security access control policies. XACML provides both a policy language and an access-control decision request/response language to meet the security access control requirements. With XACML, the PEP forms a query language to ask the PDP whether or not a given action should be allowed. The PDP responds by returning the value of either Permit, Deny, Indeterminate (decision cannot be made due to some errors or missing values), or Not Applicable (the request cannot be answered by this service).

XACML provides a rich policy language data model that is able to define sophisticated and flexible security policies. Figure 7–7 shows the full hierarchy of components of an XACML policy extracted from the XACML schema, which may be too complex for novice readers. The following are the key components that may be of interest to most readers:

• Policies. A Policy represents a single access control policy, expressed through a set of Rules. Policies are a set of rules together with a rule-combining algorithm and an optional set of obligations. Obligations are operations specified in a policy or policy set that should be performed in conjunction with enforcing an authorization decision. Each XACML policy document contains exactly one Policy or PolicySet root XML tag.
• Policy Set. A Policy Set is a set of policies or other Policy Sets and a policy-combining algorithm, along with a set of optional obligations.
• Rules. Rules are expressions describing conditions under which resource access requests are to be allowed or denied. They apply to the target (<Target>), which can specify some combination of particular resources, subjects, or actions. Each rule has an effect (which can be “permit” or “deny”) that is the result to be returned if the rule’s target and condition are true. Rules • can specify a condition (<Condition>) using Boolean expressions and a large set of comparison and data-manipulation functions over subject, resource, action, and environment attributes.
• Target. A Target is basically a set of simplified conditions for the Subject, Resource, and Action that must be met for a PolicySet, Policy, or Rule to apply to a given request. These use Boolean functions (explained more in the next section) to compare values found in a request with those included in the Target. If all the conditions of a Target are met, then its associated PolicySet, Policy, or Rule applies to the request. In addition to being a way to check applicability, Target information also provides a way to index policies, which is useful if you need to store many policies and then quickly sift through them to find which ones apply.


Figure 7–7 XACML policy language model

• Attributes. Attributes are named values of known types that may include an issuer identifier or an issue date and time. Specifically, attributes are characteristics of the Subject, Resource, Action, or Environment in which the access request is made. For example, a user’s name, their group membership, a file they want to access, and the time of day are all attribute values. When a request is sent from a PEP to a PDP, that request is formed almost exclusively of attributes, and they will be compared to attribute values in a policy in order to make the access decisions.

The XML Schema definition for XACML describes the input and output of policy decision points in an XACML context. A context denotes a canonical representation of a decision request and an authorization decision. Figure 7–8 shows the XACML context [XACML11] where a policy decision point makes reference to the attributes of a policy or identifies the attribute by subject, resource, action, or environment. The XACML context handler for requests converts the input format from domain-specific input, say, using XPath or any XSLT transformation mechanism. Upon processing the policy rules by the policy decision point, the XACML context handler for responses converts the authorization decision to a domain-specific output format. The shaded area that covers the XACML policy, policy decision point, and the XACML context handlers are the scope of XACML.

Figure 7–8 XACML context

Sun’s XACML kit (http://sunxacml.sourceforge.net) is an open source implementation of XACML 1.1. There is also a C# implementation of XACML under http://mvpos.sourceforge.net/. Parthenon Computing’s JiffyXACML (http://www.parthenoncomputing.com) is a free binary release that provides some specific functionality. A list of XACML implementations appears on the OASIS XACML TC home page (http://www.oasis-open.org/committees/tc_home.php?wg_ abbrev=xacml), along with an XACML reference list that includes publicly announced adoptions of XACML.

XACML 2.0

XACML 2.0 [XACML2] does not have major functional changes. There are a few syntactic changes to make the policy language more flexible in its support of complex security requirements. Apart from the syntactic changes, the major change in XACML 2.0 is the introduction of six profiles:

• SAML Profile. The SAML profile defines how to use SAML 2.0 to protect, transport, and request XACML schema instances and other information needed by an XACML implementation. It supports six types of queries and statements: AttributeQuery, AttributeStatement, XACMLPolicyQuery, XACMLPolicyStatement, XACMLAuthzDecisionQuery, and XACMLAuthzDecisionStatement.
• RBAC Profile. The role-based access control profile allows policies to be specified in terms of subject roles instead of individual subject identities. Roles can be nested so that more senior roles inherit the privileges of junior roles.
• Privacy Profile. The privacy profile supports specifying data privacy requirements by using two attributes: resource purpose and action purpose. The resource purpose, which has a type “urn:oasis:names:tc:xacml:2.0:resource: purpose,” indicates the purpose for which the data resource is collected. The action purpose, which has a type “urn:oasis:names:tc:xacml:2.0:action:purpose,” indicates the purpose for which access to the data resource is requested.
• Multiple Resource Profile. This profile describes three ways in which a PEP can request authorization decisions for multiple resources in a single request context and how the result of each such authorization decision is represented in the single response context that is returned to the PEP. It also describes two ways in which a PEP can request a single authorization decision in response to a request for all the nodes in a hierarchy.
• Hierarchical Resource Profile. This profile specifies how XACML can provide access control for a resource (including files, XML documents, or organizations) that is organized as a hierarchy. For example, if the administrator wants to restrict certain segments of an XML document for access, he or she may want to treat the resource (in this case, the XML document) as a hierarchy in order to allow or deny access to particular nodes in the document.
• DSIG Profile. This profile uses XML Signature to provide authentication and integrity protection for XACML schema instances.

There are some new features to the policy language. For details, refer to [XACML2]. The following are new features that allow more flexibility in expressing policies and rules.

• The element <CombinerParameters> carries the parameters for use by the combining algorithms.
• A new optional attribute <Version> was added with default value “1.0” to denote the version of the Policy and PolicySet. Policy referencing allows developers to put constraints on the policy version.
• The element <VariableReference> is used to refer to a value by its <VariableDefinition> within the same policy.
• The element <EnvironmentMatch> was added to match the environment, similar to the elements <SubjectMatch>, <ResourceMatch>, and <ActionMatch>.
• A new substitution group called <Expression> was added, which contains the elements <Apply>, <AttributeSelector>, <AttributeValue>, <Function>, <VariableReference>, and all <FooAttributeDesignator>.
• There is a <RuleCombinerparameters> element, and likewise a <PolicyCombiner-Parameters> element, which are used to pass parameters to the combining algorithms. They are not used as a substitution model.

Some changes in XACML 2.0 are syntactical. They do not have a major impact on the core policy definition functionality. However, some changes are semantic changes. The following highlight the major syntactic changes in the context schema and the policy schema. For details, refer to [XACML2changes].

• The version number of XACML in the namespace has been updated as 2.0. For example, xmlns=“urn:oasis:names:tc:xacml:2.0:context:schema:cd:04.”
• The element <Status> in a <Result> statement is now optional in XACML 2.0.
• It is mandatory in XACML 2.0 to specify an <Environment> in a <Request> statement.
• For the elements <PolicySetIdReference> and <PolicyIdReference>, XACML 2.0 uses “type=xacml:IdReferenceType.”
• The data type for “RuleId” attribute is now changed to “xs:String.”
• Two syntactic changes are made to support SAML 2.0: The <Request> can contain more than one resource. The element <Attribute> can contain more than one <AttributeValue>.
• Two items are obsolete in XACML 2.0: the attribute <IssuesInstant> in the <Attribute> statement, and the elements <AnySubject>, <AnyResource>, and <AnyAction>.
• <VariableDefinition> and <VariableReference> elements support reuse of portions of a policy, which provides a macro capability.