Trust, Access Control, and Rights for Web Services, Part 2

Web services themselves provide a powerful new approach to PKI that prevents each Web service requestor and provider from having to build their own PKI: accessing a trusted PKI as a service. XKMS aims to do just that. This is part 2 of chapter 9 from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, SAMS, 2004).

Note: Click this link to see part one of this chapter.

Securing Web Services with WS-SecurityXML Key Management Specification (XKMS)

The XML Key Management Specification is built on top of and complements the XML standards for Digital Signature and Encryption. XKMS reached version 2.0 W3C working draft in April 2003.

By now, you see that Web services need end-to-end message integrity and confidentiality, which means that they need XML Digital Signature and XML Encryption. Those technologies, in turn, scale best when they use public key cryptography. Public key cryptography needs a supporting infrastructure, PKI, to handle distribution, certification, and life-cycle management (for example, revocation) of keys. PKI has proven to be very difficult and expensive to build and maintain in practice, and many failures have given it a bad reputation as an almost “failed” technology. Web services themselves provide a powerful new approach to PKI that prevents each Web service requestor and provider from having to build their own PKI: accessing a trusted PKI as a service. XKMS aims to do just that.

Origins of XKMS

XKMS specifies protocols for distributing and registering public keys suitable for use in conjunction with the XML Digital Signature standard and the XML Encryption standard. XKMS is composed of two parts:

  • XML Key Information Service Specification (X-KISS)

  • XML Key Registration Service Specification (X-KRSS)

X-KISS is a protocol to support the creation of a service to which an application delegates the processing of Key Information. Thus, applications needing keys for use with an XML Signature, XML Encryption, or other use of the <ds:KeyInfo> element can handle the necessary complex key management by calling a shared service.

X-KRSS is a protocol to support the registration and management of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure such as X.509 or PKIX.

Goals of XKMS

XKMS’s first goal is to support a simple client’s capability to use sophisticated key management functionality. Such a simple client is not concerned with the details of the infrastructure required to support the public key management but may choose to work with X.509 certificates if it is able to manage the details. This ties back to the biggest impediment for PKI, which has been the lack of client support. This goal does not directly impact the discussion of PKI for Web services, but the second goal does.

The second goal is to provide public key management support to XML applications. In particular, it is a goal of XML key management to support the public key management requirements of XML Encryption, XML Digital Signature, and to be consistent with SAML.

One sample use of XKMS is for implementing “transaction accountability.” When a Web service embeds trust in electronic transactions using digital signatures, digital receipts, and notary services based on business policies, XKMS can, when needed, transparently link to a trust Web service to affix and validate digital signatures, notary stamps, and digital receipts to XML documents.

In this scenario, XKMS represents a strong tangible benefit of XML Signature. The presence of XKMS means that use of XML Signature can be independent of PKI vendor implementations and enables Web services to offer a wider range of options for trust relationships. In particular, access to an XKMS service makes it easier to add attribute-bindings to messages than it would be to add X.509 certificate extensions that require a tight relationship with a PKI vendor.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The XKMS Services}

The XKMS protocol follows a request/response mechanism. Each request is followed by a response message. Apart from the Authenticate message, all other messages can be grouped under one of the following message types:

Locate

This message provides name resolution.

Validate

This message provides key validation.

Register

Information is bound to a public key pair through a key binding.

Reissue

A previously registered key binding is reissued.

Recover

A previously registered key binding that may have been lost is recovered.

Revoke

A previously registered key binding is revoked.


The relationship of these messages to the requesting XKMS client and the responding Trust Service is shown in Figure 9.6.

X-KISS

The X-KISS Locate service resolves a <ds:Keyinfo> element. It is a name resolution service. The service may resolve the <ds:Keyinfo> element using local data or may relay the request to other servers. For example, the XKMS service might resolve a <ds:RetrievalMethod> element or act as a gateway to an underlying PKI based on a non-XML syntax.

Trust, Access Control, and Rights for Web Services

Figure 9.6  XKMS message types and their relationship to the
XKMS client and the Trust Service.

Here’s a sample scenario: A Web service receives a signed document that specifies the sender’s X.509v3 certificate but not the key value (which is embedded in the X.509 certificate). The Web service is not capable of processing X.509v3 certificates but can obtain the key parameters from the XKMS service by means of the Locate service. The Web service sends the <ds:Keyinfo> element to the Locate service and requests that the <KeyName> and <KeyValue> elements be returned, as shown in Listing 9.7. When it has these elements, it has the information needed to decode the XML Digital Signature it just received.

Listing 9.7 X-Kiss Request to XKMS Locate Service to Process X.509 Certificates to Obtain Key Parameters

<?xml version=”1.0″ encoding=”utf-8″?>
<LocateRequest xmlns:ds=”
http://www.w3.org/2000/09/xmldsig#”
   xmlns:xenc=”
http://www.w3.org/2001/04/xmlenc#”
   Id=”I4593b8d4b6bd9ae7262560b5de1016bc”
   Service=”
http://test.xmltrustcenter.org/XKMS
   xmlns=”
http://www.w3.org/2002/03/xkms#”>
 <RespondWith>KeyValue</RespondWith>
 <QueryKeyBinding>
  <ds:KeyInfo>
   <ds:X509Data>
    <ds:X509Certificate>MIICAjCCAW+gAwIBAgIQlzQov
IEbLLhMa8K5MR/juzAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc3QgQ0EwHhcNMDIwNjEzMjEzMzQ
xWhcNMzkxMjMxMjM
1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFsaWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJK
oZIhvcNAQEBBQADg
Y0AMIGJAoGBAMoy4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctC
WbeqR5a40JCQmvN
mRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr4fSYpP
ELOH5PDJEBAgMBA
AGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAwDgYDVQQDEwdUZXN0IENBghBy
sVHEiNFiiE2lxWv
mJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIbooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfm
p9GoN08Jkurx/gF
18RFB/7oLrVY+cpzRoCipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0Xktmv
NzcJDes9PMNxrVt
ChzjaFAE=</ds:X509Certificate>
   </ds:X509Data>
  </ds:KeyInfo>
  <KeyUsage>Signature</KeyUsage>
 </QueryKeyBinding>
</LocateRequest>

When the Locate service receives the X.509v3 certificate from the <LocateRequest> in Listing 9.7, it extracts the key information from the certificate and constructs the elements it needs to return from the requesting service, as shown in Listing 9.8.

Listing 9.8 Response from XKMS Locate Service to Preceding Request

<?xml version=”1.0″ encoding=”utf-8″?>
<LocateResult xmlns:ds=”
http://www.w3.org/2000/09/xmldsig#”
   xmlns:xenc=”
http://www.w3.org/2001/04/xmlenc#”
   Id=”I46ee58f131435361d1e51545de10a9aa”
   Service=”
http://test.xmltrustcenter.org/XKMS” ResultMajor=”Success”
   RequestId=”#I4593b8d4b6bd9ae7262560b5de1016bc”
   xmlns=”
http://www.w3.org/2002/03/xkms#”>
 <UnverifiedKeyBinding Id=”I36b45b969a9020dbe1da2cb793016117″>
  <ds:KeyInfo>
   <ds:KeyValue>
    <ds:RSAKeyValue>

<ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbS
hPMRp1qFrAfF13L
MmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNlqM2Ph9XWMc
c7qbjNHw8=</ds
:Modulus>
     <ds:Exponent>AQAB</ds:Exponent>
    </ds:RSAKeyValue>
   </ds:KeyValue>
  </ds:KeyInfo>
  <KeyUsage>Signature</KeyUsage>
  <KeyUsage>Encryption</KeyUsage>
  <KeyUsage>Exchange</KeyUsage>
 </UnverifiedKeyBinding>
</LocateResult>

The X-KISS Validate service performs this function, and in addition, the client may obtain an assertion from the X-KISS service specifying the status of the binding between the public key and other data—for example, a name or a set of extended attributes. Furthermore, the service represents that the status of each data element returned is valid and that all are bound to the same public key. The client sends to the XKMS service a prototype containing some or all of the elements for which the status of the key binding is required. If the information in the prototype is incomplete, the XKMS service may obtain additional data required from an underlying PKI Service, as depicted in Figure 9.7. After the validity of the Key Binding has been determined, the XKMS service returns the status result to the client.

Trust, Access Control, and Rights for Web Services

Figure 9.7  The Validate service provides key validation usually
sitting on top of a PKI at a trusted third party.

No single set of validation criteria is appropriate to every circumstance. Applications involving financial transactions are likely to require the application of very specific validation criteria that ensure certain contractual and/or regulatory policies are enforced. The Locate service provides a key discovery function that is neutral with respect to the validation criteria that the client application may apply. The Validate service provides a key discovery and validation function that produces results that are specific to a single set of validation criteria.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=X-KRSS}

From a Web services point of view, Locate and Validate will be the most common form of XKMS service requested. Depending on the nature of the Web service provided and the security policy in place, X-KRSS messages such as Register, Recover, Revoke, and Reissue may be processed only under a much more stringent environment.

In the registration phase, as shown in Figure 9.8, an XML application key pair holder registers its public key with a trusted infrastructure via a registration server. The public key is sent to the registration server using a digitally signed request specified by KRSS using the <Register> tag. The registration server responds with an XML formatted confirmation response using the <RegisterResponse> tag, which indicates status of the registration (accepted, rejected, or pending) and a confirmation of name and attribute information registered with the public key. Except in the case of rejection, a key pair identifier is returned in the <RegisterResponse> tag for subsequent referencing purposes. The registration is typically preceded by generation of the key pair in the key pair holder system.

Trust, Access Control, and Rights for Web Services

Figure 9.8  X-KRSS key registration.

A sample X-KRSS <Request> is shown in Listing 9.9.

Listing 9.9 X-KRSS Request to XKMS Registration Service for Key Registration

<?xml version=”1.0″?>
 <soap:Envelope xmlns:soap=”
http://schemas.xmlsoap.org/soap/envelope/
 xmlns:soapenc=”
http://schemas.xmlsoap.org/soap/encoding/
 xmlns:xsi=”
http://www.w3.org/1999/XMLSchema-instance
 xmlns:xsd=”
http://www.w3.org/1999/XMLSchema
xmlns:ds=”
http://www.w3.org/2000/09/xmldsig#”>
  <soap:Body>
   <Register xmlns=”
http://www.xkms.org/schema/xkms-2001-01-20“>
    <Prototype>
     <Status>Valid</Status>
     <KeyID>mailto:Alice@cryptographer.test</KeyID>
      <ds:KeyInfo>
       <ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>
      </ds:KeyInfo>
     <ValidityInterval>
      <NotBefore>2000-09-20T12:00:00</NotBefore>
      <NotAfter>2001-09-20T12:00:00</NotAfter>
     </ValidityInterval>
     <PassPhrase>qfarJIsfcVKLo</PassPhrase>
    </Prototype>
    <AuthInfo>
     <AuthUserInfo>
      <ProofOfPossession>
       <Signature>2PUN8HQlnhf9YI</Signature>
      </ProofOfPossession>
      <AuthKeyBinding>
       <Signature>EfdxSXAidruAszN</Signature>
      </AuthKeyBinding>
     </AuthUserInfo>
    </AuthInfo>
    <Respond>
     <string>KeyName</string>
     <string>KeyValue</string>
    </Respond>
   </Register>
  </soap:Body>
 </soap:Envelope>

The X-KRSS <RegisterResult> response to this request is shown in Listing 9.10.

Listing 9.10 X-KRSS Response from the XKMS Registration Service

<?xml version=”1.0″?>
 <soap:Envelope xmlns:soap=”
http://schemas.xmlsoap.org/soap/envelope/
 xmlns:soapenc=”
http://schemas.xmlsoap.org/soap/encoding/
 xmlns:xsi=”
http://www.w3.org/1999/XMLSchema-instance
 xmlns:xsd=”
http://www.w3.org/1999/XMLSchema
xmlns:ds=”
http://www.w3.org/2000/09/xmldsig#”>
  <soap:Body>
   <RegisterResult xmlns=”
http://www.xkms.org/schema/xkms-2001-01-20“>
    <Result>Success</Result>
    <Answer soapenc:arrayType=”KeyBinding[1]“>
     <KeyBinding>
      <Status>Valid</Status>
      <KeyID>mailto:Alice@cryptographer.test</KeyID>
       <ds:KeyInfo>
        <ds:KeyValue>
         <ds:RSAKeyValue>
<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJ
IsfcVKLob1hGnQ/l6xw==</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
         </ds:RSAKeyValue>
        </ds:KeyValue>
        <ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>
       </ds:KeyInfo>

      <ValidityInterval>
       <NotBefore>2000-09-20T12:00:00</NotBefore>
       <NotAfter>2001-09-20T12:00:00</NotAfter>
      </ValidityInterval>
     </KeyBinding>
    </Answer>
    <Private/>
   </RegisterResult>
  </soap:Body>
 </soap:Envelope>

Revocation is handled via a similar protocol. The use of desktop (that is, file system) private key storage—as well as more broad XML client encryption applications—mandates some form of key recovery provision. Key recovery provides a way to recover a lost private key so that corporate-owned data encrypted with the lost private key is not lost forever. For historical reasons, key recovery is not supported by standardized protocols. In X-KRSS, such support is built in.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=eXtensible Access Control Markup Language (XACML) Specification}

eXtensible Access Control Markup Language is an XML Schema for representing authorization and entitlement policies. The XACML 1.0 specification was ratified as an OASIS Open Standard by the OASIS eXtensible Access Control Markup Language Technical Committee in February 2003. Version 1.1 was released in August 2003.

XACML represents the rules that specify the who, what, when, and how of information access. Access control, which is often called rights management, determines who can look at something, what they can do with it, the type of device they can look at it on, and so on.

A set of access control issues has created the need for XACML. First, computing systems are extremely general. Computing platforms have been made as broad and general as possible for the widest possible set of applications that can be run on those platforms. These computing systems also have the broadest possible set of privileges for accessing data and applications, so they can be used in the widest possible set of applications, including those with very permissive (that is, no) security policies.

Second, access control policy enforcement is handled at many different points. In cases of reasonably strict security policy, systems are access controlled at the point of deployment. Enterprise security policy has many elements and points of enforcement, including HR, Finance, Legal, and others.

The third condition that sets up the need for XACML is the plethora of different access control enforcement mechanisms. Each point of enforcement is typically managed independently to make sure the policy is implemented accurately. This makes it prohibitively expensive to modify security policy. It is impossible to obtain a consolidated view of the overall security situation in an enterprise. Despite this fact, pressures increase to demonstrate and prove best practices when protecting information assets.

On top of these three conditions come the machine-to-machine interactions of Web services, which dramatically exacerbate these issues. Combined, these conditions create the need for a common language for expressing information system security policy.

The target of an XACML specification can be any object that is referenced using XML; this gives XACML very fine-grained control. XACML has three top-level policy elements: Policy, PolicySet, and Rule.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The XACML Data Model}

At the root of XACML is a concern with access policies—what XACML refers to as a Policy or a PolicySet. When XACML refers to “policy,” it specifically means authorization policy. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. A Policy represents a single access-control policy, expressed through a set of Rules. A Policy is intended to form the basis of an authorization decision. A PolicySet contains a set of Policy or other PolicySet elements and a specified procedure for combining the results of their evaluation. This is the standard means for combining separate policies into a single combined policy. A Rule contains a Boolean expression that can be evaluated in isolation as the basic unit of management; it can be reused in multiple policies.

A few more critical terms used in XACML need to be understood as well. A Target defines a set of resources, subjects, and actions to which a Rule is intended to apply. It is the set of decision requests that a Rule, Policy, or PolicySet is intended to evaluate. An Obligation is an operation specified in a Policy or PolicySet that should be performed in conjunction with the enforcement of an authorization decision. A Condition is an expression that evaluates to True or False or Indeterminate. The Effect is the intended consequence of a satisfied Rule—either Permit or Deny.

Figure 9.9 shows these XACML concepts.

Trust, Access Control, and Rights for Web Services

Figure 9.9  Core XACML constructs and their interrelationships.

XACML Operation

XACML defines a very granular set of “layers” to:

  1. Create policy.

  2. Collect the data required for policy evaluation.

  3. Evaluate policy.

  4. Enforce policy.

This much granularity enables interoperability for a wide variety of access control approaches. It is an architecture that maximizes flexibility.

Because a generic Policy or PolicySet may contain multiple policies or Rules, each of which may evaluate to different access control decisions, XACML needs some way of reconciling the decisions each makes. In XACML, this is done through a collection of Combining Algorithms. Each algorithm represents a different way of combining multiple decisions into a single decision to build up increasingly complex policies. XACML utilizes Policy Combining Algorithms (used by PolicySet) and Rule Combining Algorithms (used by Policy). The set of Combining Algorithms takes the form of deny-overrides, permit-overrides, first-applicable, and only-one-applicable. These are just a few examples, but an arbitrary set can be created from basic primitives.


XACML Not Really Ready for Prime Time Yet - XACML is intended primarily to be generated by tools. Its verbose syntax makes it hard to read and tedious to edit for other than very simple policies.

These tools, however, aren’t available yet. Nonetheless, a few brave groups have provided a template and sample code for using XACML with Java.

Not many applications will actually require the kind of dynamic discovery provided by XACML. XACML experts suggest that developers think of XACML in relation to wire-formats such as WS-Security just as they do WSDL in relation to SOAP.

The home we expect XACML to find is as the tool to create SAML Policy Decision Points (PDP). PDPs will most likely communicate to back-end policy stores using the XACML access control/policy language.


SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XACML Policy Example}

Following in Listing 9.11 is a simple example to illustrate implementation of an XACML Policy. The Target says that the Policy applies only to requests for the server called “SampleServer”. The Policy has a Rule with a Target that requires an action of “login” and a Condition that applies only if the Subject is trying to log in between 9 a.m. and 5 p.m.

Listing 9.11 -XACML for SamplePolicy on SampleServer for Login Only Between 9 and 5

 <Policy PolicyId=”SamplePolicy”
     RuleCombiningAlgId=”urn:oasis:names:tc:xacml:1.0:
      rule-combining-algorithm:first-applicable”>

  <!– This Policy only applies to requests on the SampleServer –>
  <Target>
   <Subjects>
    <AnySubject/>
   </Subjects>
   <Resources>
    <ResourceMatch MatchId=”urn:oasis:names:tc:xacml:1.0:
      function:string-equal”>
     <AttributeValue DataType=”
http://www.w3.org/2001/XMLSchema#string“>
       SampleServer</AttributeValue>
     <ResourceAttributeDesignator DataType=”
http://www.w3.org/2001/
       XMLSchema#string”
                    AttributeId=”urn:oasis:names:tc:xacml:
                     1.0:resource:resource-id”/>
    </ResourceMatch>
   </Resources>
   <Actions>
    <AnyAction/>
   </Actions>
  </Target>

  <!– Rule to see if we should allow the Subject to login –>
  <Rule RuleId=”LoginRule” Effect=”Permit”>

   <!– Only use this Rule if the action is login –>
   <Target>
    <Subjects>
     <AnySubject/>
    </Subjects>
    <Resources>
     <AnyResource/>
    </Resources>
    <Actions>
     <ActionMatch MatchId=”urn:oasis:names:tc:xacml:1.0:
       function:string-equal”>
      <AttributeValue DataType=”
http://www.w3.org/2001/XMLSchema#string“>
       login</AttributeValue>
      <ActionAttributeDesignator DataType=”
http://www.w3.org/2001/
        XMLSchema#string”
                    AttributeId=”ServerAction”/>
     </ActionMatch>
    </Actions>
   </Target>

   <!– Only allow logins from 9am to 5pm –>
   <Condition FunctionId=”urn:oasis:names:tc:xacml:1.0:function:and”>
    <Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:
     function:time-greater-than-or-equal”
     <Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:function:
       time-one-and-only”>
      <EnvironmentAttributeSelector DataType=”
http://www.w3.org/2001/
        XMLSchema#time”
                     AttributeId=”urn:oasis:names:tc:
                     xacml:1.0:environment:current-time”/>
     </Apply>
     <AttributeValue DataType=”
http://www.w3.org/2001/XMLSchema#time“>
       09:00:00</AttributeValue>
    </Apply>
    <Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:
     function:time-less-than-or-equal”
     <Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:
      function:time-one-and-only”>
      <EnvironmentAttributeSelector DataType=”
http://www.w3.org/2001/
        XMLSchema#time”
                     AttributeId=”urn:oasis:names:tc:
                     xacml:1.0:environment:current-time”/>
     </Apply>
     <AttributeValue DataType=”
http://www.w3.org/2001/XMLSchema#time“>
      17:00:00</AttributeValue>
    </Apply>
   </Condition>

  </Rule>

  <!– We could include other Rules for different actions here –>

  <!– A final, “fall-through” Rule that always Denies –>
  <Rule RuleId=”FinalRule” Effect=”Deny”/>

 </Policy>

XACML will probably affect the way security policy is built into applications, making less work for developers. XACML would do that by taking implicit policy that today is often spread across multiple applications in the form of executable code and bringing it to a central point of administration where it can be more easily created, modified, made consistent, and analyzed for effect by individuals other than developers responsible for security policy.

The following are some XACML resources:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

http://sunxacml.sourceforge.net/guide.html#xacml

http://www.idevnews.com/TipsTricks.asp?ID=57

http://www.entrust.com/resources/standards/xacml.htm

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=eXtensible Rights Markup Language (XrML) Management Specification}

The eXtensible Rights Markup Language specifies rights to control access to digital content and services. XrML is part of the effort to create an infrastructure to manage digital rights on copyright and for-fee content that is moved across the public networks.

XrML is a rights language that supports a wide variety of business models from free content that still must control who accesses it (for example, real estate home listings) to valuable content that must be purchased by the end user (for example, digital music). It can specify simple and complex rights. It is designed to handle any type of digital content or service. It gives precise meaning to all components of the system. A couple of its critical early design goals were that it be interoperable with other standards and specifications and that it be platform neutral.

The XrML Data Model

The data model for XrML consists of four entities and the relationship between those entities. The most important relationship is the XrML assertion Grant. A Grant is structured as follows:

  • The Principal to whom the Grant is issued

  • The Right that the Grant specifies

  • The Resource that is the direct object of the “rights” verb

  • The Condition that must be met for the right to be exercised

A Principal is an individual who must present identification credentials such as an X.509 certificate or a digital signature. If the authentication of this individual is successful, that person may be granted some Rights to the digital content. The Right is a verb that a Principal can be granted to exercise agaist some content. For example, the Right might be to read, view, print, forward, or even grant rights to others. The Resource is the object to which a Principal can be granted a Right. It might be an e-book, an audio or video file, or an image. It can also be a service such as email or a Web service. A Condition specifies the terms, conditions, and obligations under which the Rights can be exercised. This might be a time interval, or it might require that someone else has also granted some Rights first, such as a trusted third party. The relationships of the four key XrML constructs are shown in Figure 9.10.

Trust, Access Control, and Rights for Web Services

Figure 9.10  Core XrML constructs and their interrelationships.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XrML Use Case Example}

The following use case illustrates how to use XrML in a service-centric business model, which focuses on specifying Rights, Conditions, and metadata for services, such as Web services. In this use case, Alice pays $2 each time she uses a Web service to receive stock quotes. Figure 9.11 illustrates this use case.

Trust, Access Control, and Rights for Web Services

Figure 9.11  Alice may use the content from a Stock Quote
Web service if she pays $2 for such use.

To specify this information in XrML, you need to

  1. Identify Alice as the person to whom the Rights are granted.

  2. Specify the Right that Alice is granted—the right to use the stock service.

  3. Identify the Resource (the Web service) to which Alice is being granted rights.

  4. Specify the Condition (the fee) that applies when Alice exercises her right to use the stock service.

Figure 9.12 illustrates the structure of Alice’s license.

Trust, Access Control, and Rights for Web Services

Figure 9.12  The XrML license for Alice’s use case.

The license in Listing 9.12 illustrates how Alice’s right to use a stock quote service subject to a fee could be expressed in XrML. In this example, the prefix sx: identifies elements from the standard extension. The prefix service: identifies elements from the sample service extension. The prefix stocks: refers to the WSDL definition namespace. The prefix dsig: refers to the namespace that defines XML signatures. All other elements are defined in the XrML core.

Listing 9.12 XrML Specifying Alice’s Rights to Use a Fee-Based Stock Quote Service

<license>
 <grant>

<!- -
 Alice is represented as the holder of a particular key
 – ->
  <keyHolder licensePartId=”Alice”>
   <info>
    <dsig:KeyValue>
     <dsig:RSAKeyValue>
      <dsig:Modulus>4hre4NP7R…</dsig:Modulus>
      <dsig:Exponent>AQABAA==</dsig:Exponent>
     </dsig:RSAKeyValue>
    </dsig:KeyValue>
   </info>
  </keyHolder>

<!- -
 Alice is granted the right to use the stock quote service
 – ->
  <service:use/>

<!- -
 The stock quote service is represented with a service reference that contains
  a WSDL file
 – ->
   <serviceReference>
    <wsdl>
     <xml>
      <wsdl:definitions name=”StockQuote” targetNamespace=”http://
       
http://www.xrml.org/examples/2001/11/wsdl-stocks/stockquote.wsdl“>
       <wsdl:types>
        <xsd:schema targetNamespace=”
http://www.xrml.org/examples/2001/
         11/wsdl-stocks/stockquote.xsd”>
         <xsd:element name=”TradePriceRequest”>
          <xsd:complexType>
           <xsd:all>
            <xsd:element name=”tickerSymbol” type=”xsd:string”/>
           </xsd:all>
          </xsd:complexType>
         </xsd:element>
         <xsd:element name=”TradePrice”>
          <xsd:complexType>
           <xsd:all>
            <xsd:element name=”price” type=”xsd:float”/>
           </xsd:all>
          </xsd:complexType>
         </xsd:element>
        </xsd:schema>
       </wsdl:types>
       <wsdl:message name=”GetLastTradePriceInput”>
        <wsdl:part name=”body” element=”stocks-xsd:TradePriceRequest”/>
       </wsdl:message>
       <wsdl:message name=”GetLastTradePriceOutput”>
        <wsdl:part name=”body” element=”stocks-xsd:TradePrice”/>
       </wsdl:message>
       <wsdl:portType name=”StockQuotePortType”>
        <wsdl:operation name=”GetLastTradePrice”>
         <wsdl:input message=”stocks:GetLastTradePriceInput”/>
         <wsdl:output message=”stocks:GetLastTradePriceOutput”/>
        </wsdl:operation>
       </wsdl:portType>
       <wsdl:binding name=”StockQuoteSoapBinding” type=”stocks:
         StockQuotePortType”>
        <soap:binding style=”document” transport=”http://
          schemas.xmlsoap.org/soap/http”/>
        <wsdl:operation name=”GetLastTradePrice”>
         <soap:operation soapAction=”
http://example.com/
           GetLastTradePrice”/>
         <wsdl:input>
          <soap:body use=”literal”/>
         </wsdl:input>
         <wsdl:output>
          <soap:body use=”literal”/>
         </wsdl:output>
        </wsdl:operation>
       </wsdl:binding>
       <wsdl:service name=”StockQuoteService”>
        <wsdl:documentation>My first service</wsdl:documentation>
        <wsdl:port name=”StockQuotePort” binding=
         “stocks:StockQuoteSoapBinding”>
         <soap:address location=”
http://example.com/stockquote”/>
        </wsdl:port>
       </wsdl:service>
      </wsdl:definitions>
     </xml>
    </wsdl>
    <service>stocks:StockQuoteService</service>
    <portType>stocks:StockQuotePortType</portType>
   </serviceReference>

<!- -
 Alice pays $2.00 each time she exercises her right to use the stock
  quote service
 – ->
   <sx:fee>
    <sx:paymentPerUse>
     <sx:rate>
      <sx:amount>2.00</sx:amount>
      <sx:currency>US</sx:currency>
     </sx:rate>
    </sx:paymentPerUse>
    <sx:to>
     <sx:aba>
      <sx:institution>13937151</sx:institution>
      <sx:account>4281938823</sx:account>
     </sx:aba>
    </sx:to>
   </sx:fee>
 </grant>
</license>

The following are some XrML resources:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=rights

http://www.xrml.org/

http://xml.coverpages.org/xrml.html

http://www.giantstepsmts.com/DRM%20Watch/xrml20.htm


SAML, XACML, XrML: Overlapping Standards? - XACML and XrML both deal with authorization. They share requirements from many of the same application domains. Both share the same concepts but use different terms. Both are based on XML Schema.

Both SAML and XrML have the concept of attribute assertion. In SAML it’s just an Attribute, whereas in XrML it’s based on the PossessProperty construct.

Both XACML and XrML deal with an authorization policy. In XACML it’s just Policy, whereas in XrML its part of the License construct.

XrML operates in terms of licenses and rights. XACML operates in terms of policies. But attributes can seem like rights.

XACML is consistent with and builds on SAML. XrML may be focused more tightly on the specific issues of Digital Rights Management. In the meantime, however, the overlap is confusing; OASIS knows this and claims to be trying to make sense of it.

Because it is trivial to write an XSLT transform for an SAML:Request into XACML:Context, it follows that the two are closely related.

It is also interesting to note that SAML’s PDP is implemented with XACML. Figure 9.13 shows how SAML depends on XACML.

Trust, Access Control, and Rights for Web Services

Figure 9.13  How SAML PDPs communicate policy using XACML.

What does all of this overlap portend? It’s hard to say, but OASIS is trying to simplify matters. There are always the politics of standards with territories that need to be protected, so expect this situation to take quite some time to settle.


SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Summary}

This chapter augmented the chapters on WS-Security and WS-Policy by covering the rest of the WS-Security family. We presented a conceptual model of a triangle of security; this model is addressed by a set of standards that builds on what we have developed to this point in the book. The apexes of the triangle are trust, interoperability, and integration.

The WS-* security specifications for trust relationships include WS-Trust and WS-Privacy. WS-Trust has a request/response protocol utilizing <RequestSecurityToken> and <RequestSecurityTokenResponse>, which are designed to allow a Web service requestor to obtain a security token to be used in WS-Security to project trust as it requests service from a Web service provider. WS-Privacy establishes a set of policies that will be enforced on Web service endpoints when dealing with personally identifiable information about human participants.

The WS-* security specifications for interoperability include WS-Policy and WS-SecureConversation. WS-Policy is itself a family of related specifications, which, in addition to WS-Policy, include WS-PolicyAssertions and WS-PolicyAttachments. WS-Policy is a framework to describe and communicate the policies of a Web service. WS-PolicyAssertions describe policy assertions that can be specified within a policy. WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expression within Web services.

The WS-* security specifications for integration include WS-Federation and WS-Authorization. WS-Federation deals with the issues when one entity with one trust model wants to use a Web service to communicate with a different entity with a different trust model. One might be using Kerberos, while the other uses X.509. Understanding federation will be important both because business-to-business Web services will provide a significant source of overall business productivity improvements and because major initiatives such as Passport and Liberty Alliance are based on the concept of federated identity.

Beyond the WS-* family of specification is a small set of vitally important Web services security specifications you need to learn and track. The XML Key Management Specification (XKMS) is one of them. It will be the way PKI is leveraged and becomes truly ubiquitous because it allows PKI to operate as a trusted Web service. XKMS specifies an X-KISS protocol for Locate and Validate operations on keys. It uses the X-KRSS protocol for registration, revocation, and recovery of keys.

The specification for XML Access Control is XACML. XACML is complicated and will probably become buried in development tools but is important because it allows fine-grained control over access to all sorts of resources from Web services.

The XML Rights Management Specification is XrML, which provides a rich digital rights management specification in XML for XML.


Footonotes
  1. IBM Corporation and Microsoft Corporation. ³Security in a Web Services World: A Proposed Architecture and Roadmap.² April 7, 2002. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp

  2. The P3P specification is available at http://www.w3.org/TR/P3P/. One of this book’s authors, Dave Remy, was a contributor to this specification.

  3. The WS-SecureConversation specification is available at http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/WS-secureconversation.asp.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan