Rules In Xacml | Web Services Security

XACML uses a lot of terminology, and often the meaning of English language words in XACML is not exactly the same as their use in the vernacular. We will start with the definition of a rule and work from there.

Definition of a Rule in XACML: Target, Effect, and Conditions

A rule in XACML is defined as “A target, an effect, and a set of conditions.” To understand this definition, we have to understand the specific meanings of “target,” “effect,” and “conditions.” A target is defined as the space of decision requests that refer to actions on resources (documents, services, or systems) by subjects (people or computers). An example target would be “Read access to documents in the C Drive by Marketing Personnel.” An effect is either “permit” or “deny.” Because it is often inappropriate to have a rule fixed to always be enforced the same way, “conditions” can be applied to the rule, which can make the rule dynamic. These conditions involve the calculation of “attributes” of either the subject (if the subject has a management role), the resource (if the document is a PDF document), the action (if a local copy of the file must be made), or the environment (if it is after 5.30 P.M.).

By using this definition of rules, XACML can accommodate complex scenarios involving access to widely different resources by people or machines, depending on aspects of not just the requestor and the resource in question, but also of other conditions. The ability to query an attribute is called a “predicate” of a rule. All of this fits with the architecture of SAML, because the ability to issue an authorization decision assertion may depend on the content of certain attribute assertions. This can be mapped to the situation in XACML where the predicate of a rule is the evaluation of an attribute (such as the time of day or the role of a user).

An Example Rule

Consider the following rule adapted from the XACML draft specification. This rule grants read access to patient medical records on the example.com site only if the requestor (that is, the SAML subject) is the patient:

 <?xml version="1.0" encoding="UTF-8"?>  <Rule Rule Effect="Permit"  xmlns="urn:oasis:names:tc:xacml:0.15i:policy"  xmlns:function="urn:oasis:names:tc:xacml:0.15i:function"  xmlns:identifier="urn:oasis:names:tc:xacml:0.15i:identifier"  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="urn:oasis:names:tc:xacml:0.15i:policy  http://www.oasis-open.org/tc/xacml/v15/  draft-xacml-schema-policy-15i.xsd">    <Description>A person may read any record for which he or she is the  designated patient</Description>    <Target>  <Subjects Match DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Subject/Attribute  [@DataType='identifier:rfc822Name']"DataType="identifier:rfc822Name"/>    <Attribute DataType="identifier:rfc822Name">@</Attribute>  </Subjects>    <Resources Match DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>  <Attribute DataType="xs:anyURI">//example.com/record.*</Attribute>  </Resources>    <Actions Match DataType="xs:boolean">  <AttributeDesignator Designator="//xacmlContext/Action[@Namespace=]"  DataType="xs:string"/>    <Attribute DataType="xs:string">read</Attribute>  </Actions>  </Target>    <Condition Function DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/patientName" DataType="xs:string"/>  </Condition>  </Rule>

Look at the preceding example rule. You can see that it has a target, effect, and conditions, which is the definition of a rule in XACML. The effect of the rule is “permit”—meaning that if the rule is granted, the access (defined as an action on a resource) is permitted. The other type of effect would be “deny.”

The target of the rule is identified by the RFC 822 name of the domain “example.com”. This is the site where the medical records are being stored in this hypothetical example. Further down the rule, we see the condition of the rule. The condition states that the SubjectId and the patientName must be equal; that is, people can only access their own medical records.

Use of Functions in Rule Conditions

XACML has formalized the use of mathematic statements for rules processing. Notice the condition in the following rule, which uses the function:date-subtract operation to ensure that the age of the requestor is greater than 16:

 <Condition Function DataType="xs:boolean">  <Function Function DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/guardianName" DataType="xs:string"/>  </Function>    <Function Function        DataType="xs:boolean">  <Function Function  DataType="xs:dayTimeDuration">    <AttributeDesignator Designator=  "//xacmlContext/Other/OtherAttribute/Attribute  [@DataType='identifier:today'sDate']" DataType="xs:date"/>  <AttributeDesignator  Designator="//xacmlContext/Request/Resource/patient/patientDoB"  DataType="xs:date"/>  </Function>    <Attribute DataType="xs:dayTimeDuration">16-0-0</Attribute>  </Function>  </Condition>

XACML includes definition of arithmetical operations (add, subtract, multiply, and divide) on integers, decimal numbers, and dates, rounding, greater than/less than, and matching. Together, these allow for complex rules to be constructed.

An Obligation in a Rule

The following example, when included in an XACML rule, indicates that the enforcer of the rule must send an e-mail to the subject of the decision when permission to the protected resource is granted:

 <Obligations>  <Obligation Obligation FulfilOn="Permit">  <AttributeDesignator Designator="//xacmlContext/Request/Resource/patient/email"  DataType="xs:string"/>    <AttributeAssignment DataType="xs:string" Attribute>  Your medical record has been accessed by:</AttributeAssignment>    <AttributeDesignator Designator="//xacmlContext/Request/Subject/SubjectId"  DataType="xs:string"/>  </Obligation>  </Obligations>

Note that the implementation of the e-mail is dependent on the environment that is implementing the policy decision.

An Example of a “Deny” Rule

So far, we have seen rules that, if granted, allow access. Let’s look at the converse, a rule whose effect is “deny” for the assigned target. The target of this rule is administrator read/write access to patient records. Again, we see that the target includes the subject’s role (administrator), the resource (identified by the XPath “//example.com/record/ medical.*”), and the action (read or write). Notice the use of a function (function: stringmatch) to match the name “administrator” to the subject of the requestor. If a SAML authentication assertion is being used to identify the subject, an XSL transformation can be used to convert from the SAML syntax to the XACML “//xacmlContext/ Request/Subject/Attribute[@DataType=‘identifier:role’]” syntax.

<?xml version="1.0" encoding="UTF-8"?>  <Rule Rule Effect="Deny"  xmlns="urn:oasis:names:tc:xacml:0.15i:policy"  xmlns:function="urn:oasis:names:tc:xacml:0.15i:function"  xmlns:identifier="urn:oasis:names:tc:xacml:0.15i:identifier"  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="urn:oasis:names:tc:xacml:0.15i:policy  http://www.oasis-open.org/tc/xacml/v15/draft-xacml-schema-policy-15i.xsd">  <Description>An administrator shall not be permitted to read  or write medical elements of a patient record</Description>    <Target>  <Subjects Match DataType="xs:boolean">  <AttributeDesignator Designator="//xacmlContext/Request/Subject/Attribute  [@DataType='identifier:role']" DataType="xs:string"/>    <Attribute DataType="xs:string">administrator</Attribute>  </Subjects>    <Resources Match DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>  <Attribute DataType="xs:anyURI">//example.com/record/medical.*  </Attribute>  </Resources>    <Actions Match DataType="xs:boolean">  <AttributeDesignator Designator="//xacmlContext/Action[@Namespace=]"  DataType="xs:string"/>    <Attribute DataType="xs:string">read write</Attribute>  </Actions>  </Target>  </Rule>

A “Policy” in XACML

The definition of policy in XACML is perhaps the most important aspect of the specification. It means that an organization can use a single policy to enforce access to many different devices and systems. XACML uses the element name “policyStatement” to express information about a policy in XML format. A policy Statement element includes the following content:

PolicyID
MetaPolicy
Effect
Target
Rules
Rule-combining algorithm
Obligations

Each policy may reference one or more rules, linked together using a rule-combining algorithm. XACML formalizes the algorithms used to link rules together to make policies, and, as we’ll see later, the algorithms to link together policies to make metapolicy.

The target of a policy statement is used by the PDP to determine where the policy is applicable for a particular request. If the target is already identified in the rules, it does not need to be included in the policy statement. An obligation is defined as an action to be performed once the authorization decision is complete. An example of an obligation would be the creation of a digitally signed record each time a person’s medical records are accessed.

The following is an example of a policy that includes the four rules we saw in the rules section of this chapter. Each rule is referenced in a <RuleDesignator> element. Notice that two of the rules are referenced by their RuleID value, one is included as a base64-encoded digest, and one rule is included in its entirety.

The target of the policy is defined in the subelements of the <Target> element. The target specifies the subjects (who), resources (what), and actions (for example, read, write) of the policy. Because the individual rules that make up the policy will already have subjects, resources, and actions, a decision must be made about how to combine these into a target space for an overall policy.

The target of a policy must include all the decision requests that it is intended to evaluate. The target may be declared by the writer of the policy or computed from the targets of its component rules.

If the target of the policy statement is to be determined from the targets of the component rules, two approaches are allowed:

The target of the policy may be the union of the target definitions for resource, subject, and action that are contained in the component rules.
The target of the policy may be the intersection of the target definitions for resource, subject, and action that are contained in the component rules.

The rule-combining algorithm, specified by the RuleCombiningAlgId identifier, indicates the algorithm by which the results of evaluating the component rules are combined when evaluating the policy. In the case of the following example, “denyOverrides” means that a deny decision from a rule overrides a permit decision from another rule. The alternative would be “permitOverrides.”

 <?xml version="1.0" encoding="UTF-8"?>  <PolicyStatement Policy RuleCombiningAlgId=  "urn:oasis:names:tc:XACML:identifier:ruleCombiningAlgorithms:denyOverrides"  xmlns="urn:oasis:names:tc:xacml:0.15i:policy"  xmlns:function="urn:oasis:names:tc:xacml:0.15i:function"        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=  "urn:oasis:names:tc:xacml:0.15i:policy draft-xacml-schema-policy-15i.xsd">  <Target>    <Subjects Match DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Subject/Attribute[@DataType='identifier:role']"  DataType="xs:string"/>    <Attribute DataType="xs:string"></Attribute>  </Subjects>    <Resources Match DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>  <Attribute DataType="xs:anyURI">//example.com/record/medical.*  </Attribute>  </Resources>    <Actions Match DataType="xs:boolean">  <AttributeDesignator Designator="//xacmlContext/Action[@Namespace=]"  DataType="xs:string"/>    <Attribute DataType="xs:string">read</Attribute>  </Actions>  </Target>    <RuleSet>  <RuleDesignator>  <RuleId>//example.com/rules/rule1</RuleId>  </RuleDesignator>    <RuleDesignator>  <RuleDigest Base64Digest="H7jiE0+jwkn63k/JhB3+D9aI4V3J9z/o0"/>  </RuleDesignator>    <Rule Rule Effect="Permit">  <Description>A physician may write any medical element for  which he or she is the designated primary care physician</Description>  <Condition Function DataType="xs:boolean">    <Function Function DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/physicianName" DataType="xs:string"/>  </Function>    <Function Function DataType="xs:boolean">  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/patient/email" DataType="xs:string"/>  </Function>  </Condition>  </Rule>    <RuleDesignator>  <RuleId>//example.com/rules/rule4</RuleId>  </RuleDesignator>  </RuleSet>        <Obligations>  <Obligation Obligation FulfilOn="Permit">  <AttributeDesignator Designator=    "//xacmlContext/Request/Resource/patient/email" DataType="xs:string"/>  <AttributeAssignment DataType="xs:string" AttributeId=    "//medico.com/text">Your medical record has been accessed  by:</AttributeAssignment>    <AttributeDesignator Designator=  "//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>  </Obligation>  </Obligations>  </PolicyStatement>

The Definition of Metapolicy in XACML

As we’ve seen, a policy can refer to a metapolicy. A metapolicy combines policies and allows for a hierarchy-based resolution of policy conflicts (for example, if two policies differ on their decision). When policies are combined, similar rule-combining algorithms (for example, “DenyOverrides” or “PermitOverrides”) are used to determine the composite policy. When multiple policies are used, multiple policy administration points (PAPs) may be in operation. Metapolicies are important new features that were impossible before XACML.

XACML Architecture: PIPs, PEPs, PRPs, PAPs, and PDPs

XACML shares architectural concepts and jargon with SAML. There are many entities whose three-letter acronyms begin with a P and end with a P. The first P always stands for policy, which is a set of rules that may be combined. The third P always stands for point, and indicates that this XACML component occupies a place in the XACML architecture. Note that although each of these entities is called a “point,” there is no reason why they all have to be on different computers.

Figure 7-1 shows an XACML architectural diagram. This chain of XACML entities shown in the diagram uses the context of a Web Service request. A SOAP request is received and intercepted by a policy enforcement point, and the allow/deny decision involves the collaboration of many other XACML entities. The response of the Web Service depends on the results of XACML policy effect.

The steps in Figure 7-1 are numbered in the order of execution. Information from the incoming SOAP request is intercepted by the policy enforcement point (PEP) in step 1 and used to construct a SAML authorization decision query. The results of this query determine if the request is to be granted access to the Web Service. The authorization decision query sends details of the resource requested (that is, the Web Service) to the policy decision point (PDP), along with details of the identity of the requestor. The identity information is taken from the Web Service request. This identity information may come from an X.509 certificate used for SSL authentication or contained in the SOAP message itself (for example, a WS-Security BinarySecurityToken element), or from the NameIdentifier element in a SAML authentication assertion.

click to expand
Figure 7-1: XACML architectural diagram

Tip

Although Figure 7-1 shows a single PEP talking to the PDP, when multiple SOAP endpoints must be protected, it is more efficient to distribute the XACML architecture so that multiple PEPs talk to one PDP. A distributed architecture means that a policy can be enforced across multiple XML gateways into an organization. It also has clear benefits for policy version control, because multiple policies do not have to be synchronized between multiple PDPs.

The policy is retrieved by the PDP from the policy retrieval point (PRP). This is shown in steps 3 and 5. In most cases, the PRP will be located on the same physical machine as the PDP, meaning that the policy request (step 3) does not have to travel across the network and be subjected to network latency. The PDP may cache the policy information that it receives (step 5) from the policy retrieval point.

If the policy information for the resource is not available at the PRP, it may be retrieved from a policy store. That situation would occur if the resource has never been accessed before, or if the policy is being refreshed. The policy store is shown on the right in Figure 7-1. It must be capable of importing or exporting XACML. Rules are combined into policies by an administrator using a policy administration point (PAP). This would generally take the form of a console that allows the administrator to create rules, tying together subjects (users or computers that require access), resources (data and systems to which access will be required), and attributes (predicates for rules). These rules may then be combined together. Rules may also be imported or exported as XACML.

Although XACML may be used to import and export rules, it is not a requirement that the policies actually are stored as XACML in the policy store. An XML database, such as Software AG’s Tamino, may be used for storage of XACML in its native format. Alternatively, a relational database with an XML interface—for example, Oracle 9i or Microsoft SQL Server 2000—may be used.

Steps 6 and 7 show a policy information point being used to calculate a predicate of a rule. Remember that a predicate in XACML is defined as “the ability to query an attribute.” The attribute may be an attribute of the subject or an “environmental” attribute. An example of an attribute of the subject would be their role in a Role-Based Access Control (RBAC) system. An example environmental attribute would be the time of day (for example, access to a service may only be allowed during normal working hours). The attribute information is returned as a SAML attribute assertion (step 7).

Once the PDP has received all the information it needs in order to make a decision, it evaluates the rule and, if the result is that access is granted, then it returns a SAML authorization decision assertion to the PEP. This may be inserted into the SOAP message that is forwarded to the target Web Service (step 9).

Rules are enforced by a policy enforcement point (PEP). An example of a PEP would be a Web Service that receives incoming requests for resources and connects to a PDP in order to query authorization decisions for these resources. Although the authorization decision may be made elsewhere (that is, at the PDP), the rule is enforced at the Web Service that is receiving the request.

Tip

Although a policy enforcement point must, by definition, be capable of receiving incoming SOAP requests, it is important that other pieces of SAML and XACML architecture are not exposed to untrusted communications. For example, the policy administration point should not be contactable from the “outside world,” which would carry the danger that an intruder could change the policy or launch a denial of service attack on the policy store. It is recommended that the only portion of the XACML architecture to sit outside the firewall should be the policy enforcement point.

Let’s look at an example of an authorization decision query that is sent by a PEP to a PDP, referencing the resource where access is being attempted. For the purposes of this example, we will assume that the SOAP message indicates to the Web Services whose medical records are being requested by using an XPath expression. For example, the records of Joe User may be requested by passing the following XML fragment in a SOAP message:

 <RequestedPatientDetails>//medicalRecord/patient/Joe User  …    </RequestedPatientDetails>

Note that an XML-style hierarchical structure is used to represent the information. This does not mean that XACML can only be used for access control to XML-based information. The hierarchical structure can be applied to other data—for example, the contents of a file system.

The PEP searches the incoming SOAP message for this element and constructs an authorization decision query targeted at the PDP. The authorization decision query might look like the following:

 <AuthorizationDecisionQuery Resource="//medicalRecord/patient/Joe  User">  </AuthorizationDecisionQuery>

A policy retrieval point (PRP) receives the policy for a particular decision request. The PDP connects to the PRP to retrieve the policy for a particular decision request.

Combining these together, the PDP issues an authorization decision—the decision is based on the policy rules, such as the “patient name = name of the requester” rule that we’ve discussed, and may also depend on a PIP (say, to query the role of a patient). Policy is configured by a PAP, and retrieved by the PDP from a PRP. If a rule has no predicate, meaning that no attributes need to be queried for this rule (for example, “ no access whatsoever is allowed to this resource”), no information request to a PIP is necessary.

If the outcome of the decision is to permit access to the patient medical records, the following authorization decision statement would be sent back to the PEP:

 <Response xmlns:="urn:oasis:names:tc:SAML:1.0:protocol"  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">    <saml:Assertion>  <saml:AuthorizationDecisionStatement Resource=  "//medicalRecord/patient/Joe User" Decision="Permit">  <saml:Subject>    <saml:NameIdentifier SecurityDomain="example.com"  Name="MedicalRecords"/>  </saml:Subject>    <saml:Actions>  <saml:Action>Read</saml:Action>  </saml:Actions>  </saml:AuthorizationDecisionStatment>  </saml:Assertion>  </Response>

Processing SOAP Requests

We see in Figure 7-1 that our example rule applies to access to a Web Service, and the rule is enforced by a PEP. The PEP receives SOAP requests and makes an authorization decision query to a PDP. In this scenario, we need to enforce the rule that states that the identity of the party requesting the medical records must be the same as the identity of the subject of the medical records. Therefore, we need to find out the identity of the person on whose behalf the SOAP request is being made, so that we can check this against the name of the person whose medical records are being accessed.

Using a SAML Attribute in an Authorization Decision Request

Recall from Chapter 3 that the identity of the SOAP requestor is not necessarily the same as the identity of the end user on whose behalf the SOAP request is being made. To find out who is actually running the Web Service, we can look into the SOAP request to find a security token. An example of a security token is a SAML authorization assertion. This contains information about the authentication act of the end user (for example, “Joe User authenticated using a password at 9 A.M. on December 1”). In addition, an attribute assertion in the SOAP message can indicate attributes of the end user—for example, their role as defined in an RBAC system.

The following is an example of an authorization decision request to a PDP that uses a SAML authentication assertion and also a SAML attribute assertion:

 <?xml version="1.0" encoding="UTF-8"?>  <Request xmlns="urn:oasis:names:tc:xacml:0.15i:context"  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  xmlns:identifier="urn:oasis:names:tc:xacml:identifier"  xmlns:xacml="urn:oasis:names:tc:xacml:0.15i:policy"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="urn:oasis:names:tc:xacml:0.15i:context  http://www.oasis-open.org/tc/xacml/v15/draft-xacml-schema-context-15i.xsd">  <Subject>    <SubjectId Format="xsi:string">Joe User</SubjectId>  </Subject>    <Resource>  <ResourceSpecifier Format="xsi:anyURI" Scope="Descendants"  Resource/>  </Resource>    <Action Namespace="">read</Action>  <Environment>    <EnvironmentAttribute AttributeId=  "urn:oasis:names:tc:SAML:1.0:Assertion" DataType="xsi:string">  <saml:Assertion Assertion    Issuer="example.com" IssueInstant="2002-03-08T08:23:47-05:00"  MajorVersion="0" MinorVersion="28"  xmlns="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=  "http://www.oasis-open.org/committees/security/docs/  cs-sstc-schema-assertion-01.xsd">    <saml:AuthenticationStatement AuthenticationInstant=        "2002-03-08T08:23:45-05:00" AuthenticationMethod="http://www.  oasisopen.org/committees/security/docs/draft-sstc-core-28/password-sha1">  <saml:Subject>    <saml:NameIdentifier NameQualifier="\\medico.com">  Joe User  </saml:NameIdentifier>    <saml:SubjectConfirmation>  <saml:ConfirmationMethod>  http://www.oasis-open.org/committees/security/docs/  draft-sstc-core-24/artifact  </saml:ConfirmationMethod>  </saml:SubjectConfirmation>  </saml:Subject>    <saml:SubjectLocality IPAddress="1.2.3.4"/>  </saml:AuthenticationStatement>  </saml:Assertion>  </EnvironmentAttribute>    <EnvironmentAttribute Attribute  DataType="xsi:string">    <saml:Assertion MajorVersion="0"  MinorVersion="28" Assertion  Issuer="example.com" IssueInstant="2000-06-15T15:02:39-05:00"  xmlns="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=  "http://www.oasis-open.org/committees/security/docs/  cs-sstc-schema-assertion-01.xsd">    <saml:AttributeStatement>  <saml:Subject>    <saml:NameIdentifier NameQualifier=  "\\example.com">Joe User</saml:NameIdentifier>  </saml:Subject>    <saml:Attribute AttributeName="role"  AttributeNamespace="//example.com">  <saml:AttributeValue>Patient</saml:AttributeValue>  </saml:Attribute>  </saml:AttributeStatement>  </saml:Assertion>  </EnvironmentAttribute>  </Environment>  </Request>

In this example, we can see that Joe User authenticated using a password credential, which was verified against a SHA-1 digest. We can also see when Joe User authenticated. Below the authentication assertion, we see the attribute assertion. This indicates that Joe User has the role of Patient. All of this information is used by the PDP to produce an authorization decision assertion.

Digital Rights Management

Digital Rights Management (DRM) provides a compelling use case for XACML. DRM distinguishes between the content provider, content clearinghouse, customer, and content distributor. In DRM, content distributors make digital works available over the Internet. Customers purchase rights to these works—for example, the right to download and view them. The customer must be authenticated, so that the customer pays. Payment is handled by a content clearinghouse. This may be the same entity as the content provider, or they may be separate entities. The content provider is the owner of the legal rights to the work. An example of a content provider is a record company, which owns the legal rights to songs.

DRM Policy Using XACML

We have seen how XACML allows the creation of rules, which are consolidated into policies. In the case of DRM, it is a useful exercise to think about how access control rules for online content can be expressed, taking into account that the content provider must be paid.

The payment of the content provider maps to the use of obligations in XACML. If the content provider is also acting as a content clearinghouse, then after the work is issued to the customer, the PEP must execute payment to the content provider. If the content provider and content clearinghouse are not the same entity, an obligation can be defined such that the PEP must notify the content clearinghouse of the purchase.

The authentication of the end user is important if payment enforcement requires information about the end user. However, the policy may require that the information about the content provider is also required. This would be required if it must be proved that the content provider is indeed legally allowed to confer rights to this work. An example would be a video-on-demand service, which must be able to prove that it is allowed, by the movie publisher, to offer a movie for download.

DRM policy may be required to be dynamic, in which case information requests from a PIP to a PEP can be used to find out attributes of the work (such as the number of downloads permissible).

Security Considerations When Using XACML

XACML, as we have seen, is a powerful method for defining rules, policies, and metapolicies. The architecture of XACML with PEPs, PDPs, and so forth has important security requirements that influence implementation decisions. XACML applies the advantages of XML to access control, but the XML communications involved in a XACML architecture must also be secure. As with all security discussions in this book, we will concentrate on the high-level principles of security and see how they apply.

Authentication

It is important for a PEP to authenticate the identity of the PDP to which it sends decision requests. Furthermore, the PDP must trust the identity of PIPs to which it sends information requests.

It is equally important for a PDP to authenticate the identity of its clients and assess the level of trust to determine what, if any, sensitive data should be passed.

The authentication techniques that we encountered in Chapter 2 may be used to provide this authentication, including signature-based authentication, transport-level or session-level authentication, or the use of a private network.

Confidentiality

In Chapter 3, we saw that confidentiality means that the contents of a message can be read only by the desired recipients and not by anyone else who intercepts the message while it is in transit. There are two areas in which confidentiality should be considered: one is confidentiality during transmission, and the other is confidentiality within a <policyStatement> itself. Confidentiality during transmission can be achieved by using encryption on the transport that is used—say, a VPN or IPSec. Confidentiality within the policy statement can be used, for example, to hide details of payment amounts that are to be enforced as an obligation of a rule. When the policy is being stored, or sent, the payment details can be selectively encrypted using XML Encryption (see Chapter 5 for details on how this can be achieved).

Integrity

Because processing of policy statement documents by a PDP is at the core of the XACML architecture, it is important that these documents cannot be changed without detection. In many cases, this can be achieved at the system level by ensuring the integrity of the systems, including PAPs and PRPs, and implementing confidentiality between parties.

However, when policy is distributed between organizations to be acted on at a later time, or when the policy travels with data, it is appropriate to have a digital signature of the policy included with the policy statements. XML Signature is the ideal candidate to provide this (see Chapter 4 for more information about XML Signature).

Trust Model

Although beyond the scope of XACML, a trust model must be in place for a XACML architecture to be enabled. The use of keys for digital signatures and encryption assumes that the identity of an entity can be linked to the keys. Various forms of a trust model can be used, including PKI (hierarchical trust) and PGP (a web of trust).

Privacy

XACML enables access control, but ironically the system itself requires access control for various reasons, including privacy. Information about the role of a user (for example, their membership in a certain group or their credit status) is private information and should not be disclosed to third parties. This means that when the information is stored, processed, or sent, it should be kept confidential.

Checklist

Remember that XACML defines both architecture and syntax. The syntax is a means of defining access control rules, policies, and metapolicies. The architecture defines how various entities process these XACML documents to perform access control.

Ensure that a XACML architecture only exposes the policy enforcement point (PEP) to incoming XML traffic.
Consider organizing non-XML data into a hierarchical XML-like structure.
When choosing a SAML or XACML product, ensure that the product can support policy enforcement at multiple entry points into the organization, but with centralized policy administration.