Identify the purpose and benefits of Web services security oriented initiatives and standards such as Username Token Profile, SAML, XACML, XKMS, WS-Security, and the Liberty Project.




Security Assertions Markup Language effort, or SAML, which is being defined by the OASIS (Organization for the Advancement of Structured Information) security services technical committee. The committee aims to outline a standard XML framework for exchanging authentication and authorization information. In a nutshell, SAML is an XML-based framework for exchanging security information. As a framework, it deals with three things.

The security information for exchanging is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain.

Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes. Note that assertions containing authentication statements merely describe acts of authentication that happened previously.

Assertions are issued by SAML authorities, namely, authentication authorities, attribute authorities, and policy decision points. SAML defines a protocol by which clients can request assertions from SAML authorities and get a response from them. This protocol, consisting of XML-based request and response message formats, can be bound to many different underlying communications and transport protocols; SAML currently defines one binding, to SOAP over HTTP.

SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests, in creating their responses. Thus, while clients always consume assertions, SAML authorities can be both producers and consumers of assertions.

One major design goal for SAML is Single Sign-On (SSO), the ability of a user to authenticate in one domain and use resources in other domains without re-authenticating. However, SAML can be used in various configurations to support additional scenarios as well. Several profiles of SAML are currently being defined that support different styles of SSO and the securing of SOAP payloads.


XACML stands for Extensible Access Control Markup Language, and its primary goal is to standardize access control language in XML syntax. A standard access control language results in lower costs because there is no need to develop an application-specific access control language or write the access control policy in multiple languages. Plus, system administrators need to understand only one language. With XACML, it is also possible to compose access control policies from the ones created by different parties.

In a nutshell, XACML is a general-purpose access control policy language. This means that it provides a syntax (defined in XML) for managing access to resources.

XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML). The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed, and interpret the result. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can't be answered by this service).

The typical setup is that someone wants to take some action on a resource. They will make a request to whatever actually protects that resource (like a filesystem or a web server), which is called a Policy Enforcement Point (PEP). The PEP will form a request based on the requester's attributes, the resource in question, the action, and other information pertaining to the request. The PEP will then send this request to a Policy Decision Point (PDP), which will look at the request and some policy that applies to the request, and come up with an answer about whether access should be granted. That answer is returned to the PEP, which can then allow or deny access to the requester. Note that the PEP and PDP might both be contained within a single application, or might be distributed across several servers. In addition to providing request/response and policy languages, XACML also provides the other pieces of this relationship, namely finding a policy that applies to a given request and evaluating the request against that policy to come up with a yes or no answer.

There are many existing proprietary and application-specific languages for doing this kind of thing but XACML has several points in its favor:

Every enterprise has a need to secure resources accessed by employees, partners, and customers. For example, browser based access to portals which aggregate resources (web pages, applications, services, etc.) are typical in today's enterprises. Clients send requests to servers for resources, but before a server can return that resource it must determine if the requester is authorized to use the resource. This is where XACML fits in. XACML provides a policy language which allows administrators to define the access control requirements for their application resources. The language and schema support include data types, functions, and combining logic which allow complex (or simple) rules to be defined. XACML also includes an access decision language used to represent the runtime request for a resource. When a policy is located which protects a resource, functions compare attributes in the request against attributes contained in the policy rules ultimately yielding a permit or deny decision.

When a client makes a resource request upon a server, the entity charged with access control by enforcing authorization is called the Policy Enforcement Point. In order to enforce policy, this entity will formalize attributes describing the requester at the Policy Information Point and delegate the authorization decision to the Policy Decision Point. Applicable policies are located in a policy store and evaluated at the Policy Decision Point, which then returns the authorization decision. Using this information, the Policy Enforcement Point can deliver the appropriate response to the client.

An administrator creates policies in the XACML language. The key top-level element is the PolicySet which aggregates other PolicySet elements or Policy elements. The Policy element is composed principally of Target, Rule and Obligation elements and is evaluated at the Policy Decision Point to yield and access decision. Since multiple policies may be found applicable to an access decision, (and since a single policy can contain multiple Rules) Combining Algorithms are used to reconcile multiple outcomes into a single decision. Standard Combining Algorithms are defined for Deny-Overrides, Permit-Overrides, First Applicable, and Only-One Applicable outcomes. The Target element is used to associate a requested resource to an applicable Policy. It contains conditions that the requesting Subject, Resource, or Action must meet for a Policy Set, Policy, or Rule to be applicable to the resource. The Target includes a build-in scheme for efficient indexing/lookup of Policies. Rules provide the conditions which test the relevant attributes within a Policy. Any number of Rule elements may be used each of which generates a true or false outcome. Combining these outcomes yields a single decision for the Policy, which may be "Permit", "Deny", "Indeterminate", or a "NotApplicable" decision.

Attributes provide the typed values that represent both a resource requester and the Policy's condition predicates. When describing the requester, attributes may include an issue date and time, issuer identification, and optionally are contained in the Subject, Environment, Resource and Action elements of the access request. The Attribute Designator element is used to retrieve attribute values from a request by specifying the name, type, and issuer of attributes. The SubjectAttributeDesignator, ResourceAttributeDesignator, ActionAttributeDesignator, and EnvironmentAttributeDesignator each retrieves attributes from the respective elements in the request. An AttributeSelector element is used to locate request attributes using XPATH queries. Since queries can return collections of attributes (all of the same primitive type) they are placed in a Bag. Functions are then used to compare attributes contained within a Bag.

XKMS (XML Key Management Specification)

XKMS stands for the XML Key Management Specification and consists of two parts: XKISS (XML Key Information Service Specification) and XKRSS (XML Key Registration Service Specification). XKISS defines a protocol for resolving or validating public keys contained in signed and encrypted XML documents, while XKRSS defines a protocol for public key registration, revocation, and recovery. The key aspect of XKMS is that it serves as a protocol specification between an XKMS client and an XKMS server in which the XKMS server provides trust services to its clients (in the form of Web services) by performing various PKI (public key infrastructure) operations, such as public key validation, registration, recovery, and revocation on behalf of the clients. Now let's talk about why we need XKMS. To explain it, I must discuss PKI first. PKI proves important for e-commerce and Web services. However, one of the obstacles to PKI's wide adoption is that PKI operations such as public key validation, registration, recovery, and revocation are complex and require large amounts of computing resources, which prevents some applications and small devices such as cell phones from participating in PKI-based e-commerce or Web services transactions. XKMS enables an XKMS server to perform these PKI operations. In other words, applications and small devices, by sending XKMS messages over SOAP (Simple Object Access Protocol), can ask the XKMS server to perform the PKI operations. In this regard, the XKMS server provides trust services to its clients in the form of Web services.

[PKI refers to a set of security services for authentication, encryption and digital certificate management under which documents are encrypted with a private key and decrypted using a publicly available key accessible to the recipient via a network. PKI differs from private key technology, like Kerberos, in which a single key that is shared by the sender and receiver is used to encrypt and decrypt a message or document.]

XKMS defines a Web services interface to a public key infrastructure. This makes it easy for applications to interface with key-related services, like registration and revocation, and location and validation. Most developers will only ever need to worry about implementing XKMS clients. XKMS server components are mostly implemented by providers of public key infrasructure (PKI) providers, such as Entrust, Baltimore and VeriSign. VeriSign, for example, provides an XKMS responder that can be used to register and query VeriSign's certificate store. Even SSL server ID's can be validated in real-time using the XKMS interface.

XKMS is a foundational specification for secure Web services, enabling Web services to register and manage cryptographic keys used for digital signatures and encryption.

When combined with WS-Security, XKMS makes it easier than ever for developers to deploy enterprise applications in the form of secure Web services available to business partners beyond the firewall.

With XKMS, developers can integrate authentication, digital signature, and encryption services, such as certificate processing and revocation status checking, into applications in a matter of hours - without the constraints and complications associated with proprietary PKI software toolkits.

XKMS Functions

An XKMS-compliant service supports the following operations:

These services can be complimented by having cryptographic capabilities on the client, but client crypto is not required. For example, if a client must generate keys, then some crypto code, resident on the client, performs the key generation. However, the client can just as easily have the XKMS service generate the keys that are subsequently managed through the service. For security, however, most client applications generate a keypair, and then register the public key with the CA.

The Benefits of XKMS

XKMS provides many benefits. The most important benefits are that XKMS is:


The goal of WS-Security is to enable applications to construct secure SOAP message exchanges.

The WS-Security (Web Services Security) specification defines a set of SOAP header extensions for end-to-end SOAP messaging security. It supports message integrity and confidentiality by allowing communicating partners to exchange signed and encrypted messages in a Web services environment. Because it is based on XML digital signature and XML Encryption standards, you can digitally sign and encrypt any combination of message parts. WS-Security supports multiple security models, such as username/password-based and certificate-based models. It also supports multiple security technologies, including Kerberos, PKI, SAML, and so on. In addition, it supports multiple security tokens; for example, tokens that contain Kerberos tickets, X.509 certificates, or SAML assertions.

The following example illustrates a message with a username security token:

(001) <?xml version="1.0" encoding="utf-8"?>
(002)  <S:Envelope xmlns:S=""
(003)    <S:Header>
(004)       <m:path xmlns:m="">
(005)         <m:action></m:action>
(006)         <m:to></m:to>
(007)         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
(008)       </m:path>
(009)       <wsse:Security xmlns:wsse="">
(010)         <wsse:UsernameToken Id="MyID">
(011)             <wsse:Username>Mikalai</wsse:Username> 
(012)         </wsse:UsernameToken>
(013)         <ds:Signature>
(014)            <ds:SignedInfo>
(015)               <ds:CanonicalizationMethod  Algorithm="..."/>
(016)               <ds:SignatureMethod  Algorithm="..."/>
(017)               <ds:Reference URI="#MsgBody">
(018)                  <ds:DigestMethod Algorithm="..."/>
(019)                  <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
(020)               </ds:Reference>
(021)            </ds:SignedInfo>
(022)            <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
(023)            <ds:KeyInfo>
(024)                <wsse:SecurityTokenReference>
(025)                 <wsse:Reference URI="#MyID"/>
(026)                </wsse:SecurityTokenReference>
(027)            </ds:KeyInfo>
(028)         </ds:Signature>
(029)      </wsse:Security>
(030)   </S:Header>
(031)   <S:Body Id="MsgBody">
(032)     <tru:StockSymbol xmlns:tru="">
(033)   </S:Body>
(034) </S:Envelope>


The first two lines start the SOAP envelope. Line (003) begins the headers that are associated with this SOAP message. Lines (004) to (008) specify how to route this message (as defined in WS-Routing).

Line (009) starts the Security header that we define in WS-Security specification. This header contains security information for an intended receiver. This element continues until line (029).

Lines (010) to (012) specify a security token that is associated with the message. In this case, it defines username of the client using the UsernameToken. Note that here we assume the service knows the password - in other words, it is a shared secret.

Lines (013) to (028) specify a digital signature. This signature ensures the integrity of the signed elements (that they aren't modified). The signature uses the XML Signature specification. In this example, the signature is based on a key generated from the users' password; typically stronger signing mechanisms would be used.

Lines (014) to (021) describe the digital signature. Line (015) specifies how to canonicalize (normalize) the data that is being signed.

Lines (017) to (020) select the elements that are signed. Specifically, line (017) indicates that the S:Body element is signed. In this example only the message body is signed; typically additional elements of the message, such as parts of the routing header, should be included in the signature.

Line (022) specifies the signature value of the canonicalized form of the data that is being signed as defined in the XML Signature specification.

Lines (023) to (027) provide a hint as to where to find the security token associated with this signature. Specifically, lines (024) to (025) indicate that the security token can be found at (pulled from) the specified URL.

Lines (031) to (033) contain the body (payload) of the SOAP message.

Protecting the message content from being intercepted (confidentiality) or illegally modified (integrity) are primary security concerns. WS-Security specification provides a means to protect a message by encrypting and/or digitally signing a body, a header, an attachment, or any combination of them (or parts of them). Message integrity is provided by leveraging XML Signature in conjunction with security tokens to ensure that messages are transmitted without modifications. The integrity mechanisms are designed to support multiple signatures, potentially by multiple actors, and to be extensible to support additional signature formats. Message confidentiality leverages XML Encryption in conjunction with security tokens to keep portions of a SOAP message confidential. The encryption mechanisms are designed to support additional encryption processes and operations by multiple actors.

The Security header block provides a mechanism for attaching security-related information targeted at a specific receiver (SOAP actor). This MAY be either the ultimate receiver of the message or an intermediary. Consequently, this header block MAY be present multiple times in a SOAP message. An intermediary on the message path MAY add one or more new sub-elements to an existing Security header block if they are targeted for the same SOAP node or it MAY add one or more new headers for additional targets. As stated, a message MAY have multiple Security header blocks if they are targeted for separate receivers. However, only one Security header block can omit the S:actor attribute and no two Security header blocks can have the same value for S:actor. Message security information targeted for different receivers MUST appear in different Security header blocks. The Security header block without a specified S:actor can be consumed by anyone, but MUST NOT be removed prior to the final destination as determined by WS-Routing. As elements are added to the Security header block, they should be prepended to the existing elements. As such, the Security header block represents the signing and encryption steps the message sender took to create the message. This prepending rule ensures that the receiving application MAY process sub-elements in the order they appear in the Security header block, because there will be no forward dependency among the sub-elements. Note that WS-Security specification does not impose any specific order of processing the sub-elements. The receiving application can use whatever policy is needed. When a sub-element refers to a key carried in another sub-element (for example, a signature sub-element that refers to a binary security token sub-element that contains the X.509 certificate used for the signature), the key-bearing security token SHOULD be prepended subsequent to the key-using sub-element being added, so that the key material appears before the key-using sub-element. The following illustrates the syntax of this header:

        <Security S:actor="..." S:mustUnderstand="...">
             actor attribute is optional, however no two instances of the 
             header block may omit an actor or specify the same actor

The following sample message illustrates the use of security tokens, signatures, and encryption. For this example, we use a fictitious "RoutingTransform" that selects the immutable routing headers along with the message body:

(001) <?xml version="1.0" encoding="utf-8"?>
(002) <S:Envelope xmlns:S=""
(003)   <S:Header>
(004)      <m:path xmlns:m="">
(005)         <m:action></m:action>
(006)         <m:to></m:to>
(007)         <m:from></m:from>
(008)         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
(009)      </m:path>
(010)      <wsse:Security>
(011)         <wsse:BinarySecurityToken 
(012)         MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(013)         </wsse:BinarySecurityToken>
(014)         <xenc:EncryptedKey>
(015)             <xenc:EncryptionMethod Algorithm=
(016)             <ds:KeyInfo>
(017)               <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
(018)             </ds:KeyInfo>
(019)             <xenc:CipherData>
(020)                <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(021)                </xenc:CipherValue>
(022)             </xenc:CipherData>
(023)             <xenc:ReferenceList>
(024)                 <xenc:DataReference URI="#enc1"/>
(025)             </xenc:ReferenceList>
(026)         </xenc:EncryptedKey>
(027)         <ds:Signature>
(028)            <ds:SignedInfo>
(029)               <ds:CanonicalizationMethod
(030)               <ds:SignatureMethod 
(031)               <ds:Reference>
(032)                  <ds:Transforms>
(033)                     <ds:Transform 
(034)                     <ds:Transform 
(035)                  </ds:Transforms>
(036)                  <ds:DigestMethod 
(037)                  <ds:DigestValue>LyLsF094hPi4wPU...
(038)                   </ds:DigestValue>
(039)               </ds:Reference>
(040)            </ds:SignedInfo>
(041)            <ds:SignatureValue>
(042)                     Hp1ZkmFZ/2kQLXDJbchm5gK...
(043)            </ds:SignatureValue>
(044)            <ds:KeyInfo>
(045)                <wsse:SecurityTokenReference>
(046)                    <wsse:Reference URI="#X509Token"/>
(047)                </wsse:SecurityTokenReference>
(048)            </ds:KeyInfo>
(049)         </ds:Signature>
(050)      </wsse:Security>
(051)   </S:Header>
(052)   <S:Body>
(053)      <xenc:EncryptedData 
(054)         <xenc:EncryptionMethod         
(055)         <xenc:CipherData>
(056)            <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(057)            </xenc:CipherValue>
(058)         </xenc:CipherData>
(059)      </xenc:EncryptedData>
(060)   </S:Body>
(061) </S:Envelope>

Lines (003)-(051) contain the SOAP message headers.

Lines (004)-(009) specify the message routing information (as define in WS-Routing). In this case we are sending the message to the service requesting the "getQuote" action.

Lines (010)-(050) represent the Security header block. This contains the security-related information for the message.

Lines (011)-(013) specify a security token that is associated with the message. In this case, it specifies an X.509 certificate that is encoded as Base64. Line (012) specifies the actual Base64 encoding of the certificate.

Lines (014)-(026) specify the key that is used to encrypt the body of the message. Since this is a symmetric key, it is passed in an encrypted form. Line (015) defines the algorithm used to encrypt the key. Lines (016)-(018) specify the name of the key that was used to encrypt the symmetric key. Lines (019)-(022) specify the actual encrypted form of the symmetric key. Lines (023)-(025) identify the encryption block in the message that uses this symmetric key. In this case it is only used to encrypt the body (Id="enc1").

Lines (027)-(049) specify the digital signature. In this example, the signature is based on the X.509 certificate. Lines (028)-(040) indicate what is being signed. Specifically, Line (029) indicates the canonicalization algorithm (exclusive in this example). Line (030) indicate the signature algorithm (rsa over sha1 in this case).

Lines (031)-(039) identify the parts of the message that are being signed. Specifically, Line (033) identifies a "transform". This fictitious transforms selects the immutable portions of the routing header and the message body. Line (034) specifies the canonicalization algorithm to use on the selected message parts from line (033). Line (036) indicates the digest algorithm use on the canonicalized data. Line (037) specifies the digest value resulting from the specified algorithm on the canonicalized data.

Lines (041)-(043) indicate the actual signature value - specified in Line (042).

Lines (044)-(048) indicate the key that was used for the signature. In this case, it is the X.509 certificate included in the message. Line (046) provides a URI link to the Lines (011)-(013).

The body of the message is represented by Lines (052)-(060).

Lines (053)-(059) represent the encrypted metadata and form of the body using XML Encryption. Line (053) indicates that the "element value" is being replaced and identifies this encryption. Line (054) specifies the encryption algorithm - Triple-DES in this case. Lines (055)-(058) contain the actual cipher text (i.e., the result of the encryption). Note that we don't include a reference to the key as the key references this encryption - Line (024).

Liberty Project

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     SCDJWS 5.0 Quiz