Privacy and XML, Part 2
Pages: 1, 2

WS-Security

Relevant Privacy Concepts • Information Sharing • Confidentiality • Authentication • Authorization

WS Security is a recent proposal from Microsoft for adding security metadata to SOAP messages. We'll discuss it here in the context of a site requesting user information from .NET My Services. In this context, there are two privacy aspects to WS Security:

1. The requesting application will use WS Security mechanisms to authenticate to .NET My Services such that .NET My Services can determine if the relevant user has been granted the appropriate authorizations as defined in its privacy policy
2. The confidentiality of the returned user information will be ensured through WS Security's support for encryption.

To ensure that only authorized parties gain access to this data, the site must first prove its identity by authenticating itself. Rather than the application authenticating directly to .NET My Services, it will do so to Microsoft's Passport service in order to obtain a token (a Kerberos ticket), which it will then present to .NET My Services. .NET My Services, after verifying the token and confirming that it came from Passport, will confirm that it conforms to the appropriate user's privacy preferences. It will then accept the request and return the requested data in a SOAP response.

An example of the SOAP request to .NET My Services is shown below, illustrating both the elements of the WS-Security namespace (identified by the namespace prefix "wsse") and those of HSDL (.NET My Services data manipulation language). For clarity, the actual namespace declarations are omitted.

<SOAP:Envelope>
    <SOAP:Header>
    <wsse:Security>
    <wsse:BinarySecurityToken wsse:ValueType="wsse:Kerberosv5"
        EncodingType="wsse:Base64Binary" Id="token">
        MIIEZzCCA9CgAwIBAgIQEmtJZc0...
    </wsse:BinarySecurityToken>
    
    <dsig:Signature>
        <dsig:Reference="#busmsg"/>
        <dsig:SignatureMethod Algorithm="#hmac-sha1">
            <HMACOutputLength>128</HMACOutputLength> 
        </dsig:SignatureMethod>
        <dsig:SignatureValue>IU(89.Hl8*.</dsig:SignatureValue>
        <dsig:KeyInfo>
            <wsse:SecurityTokenReference>
                <wsse:Reference URI="#token"/>
            </wsse:SecurityTokenReference>
        </disg:KeyInfo>
    </dsig:Signature>
    </wsse:Security>
    </SOAP:Header>

    <SOAP:Body>
    <hsdl:queryRequest id="busmsg">
        <xpQuery select='/contact[Name="Smith"]'/>
    </hsdl:queryRequest>
    </SOAP:Body>

</SOAP:Envelope>

The binary encoded Kerberos ticket in the <BinarySecurityToken> element is highlighted in green in the SOAP header. The ticket is encrypted with a secret key that .NET My Services shares with Passport.

The <Signature> element is highlighted in red in the SOAP Header. The enclosed WS-Security <SecurityTokenReference> references the ID of the previous <BinarySecurityToken>.

The HSDL elements of the SOAP Body are highlighted in blue. The HSDL request is to return all contacts with the name of "Smith" for the user on whose behalf the request is made.

To authenticate and authorize this SOAP message, .NET My Services would perform the following processing:

1. Use the secret key it shares with Passport to decrypt the Kerberos ticket in the <BinarySecurityToken> element. The ticket will contain:
1. The Passport PUID of the user on whose behalf the request is being made
2. An identifier for the requesting application.
3. The temporary session key (of which the requesting application has the other copy)
2. Examine the <Reference> element in the XML Signature to determine over which elements of the SOAP message was the MAC calculated
3. Use the session key it extracted from the Kerberos ticket (1c above) to calculate a MAC over the same elements
4. Compare the MAC it calculates to that supplied by the requesting application.
5. If the MACs match, compare the authenticated requesting application with the user's privacy policy to determine if the request should be granted.

Assuming that the nature of the user profile data to be returned in the SOAP response is sensitive, the user's privacy requires that the confidentiality of this information be protected in transit. An example of the SOAP response is shown here:

<SOAP:Envelope>
    <SOAP:Header>
  
        <wsse:Security>

         <xenc:EncryptedData id="encdata">
         <xenc:EncryptionMethod   
             Algorithm='http://www.w3.org/xmlenc#3des-cbc'/>
         <xenc:CipherData>
             <xenc:CipherValue>JS*du89sad7</xenc:CipherValue>
         </xenc:CipherData>
        </xenc:EncryptedData>

        </wsse:Security>
 
   </SOAP:Header>

    <SOAP:Body>
        <hsdl:queryResponse id="busmsg">
        <xenc:CipherReference idref="#encdata"/>
       </hsdl:queryResponse>
    </SOAP:Body>

</SOAP:Envelope>

The XML Encryption <EncryptedData> element is highlighted in red. It holds the encrypted contents of the <queryResponse> element. The actual encryption operation used the 3DES algorithm and the secret key previously established between the requesting application and .NET My Services.

The HSDL elements of the SOAP Body are highlighted in blue. The contents of the <queryResponse> have been replaced with the <CipherReference> element of the XML Encryption namespace. This element points at the EncryptedData element in the SOAP header above.

SAML

Relevant Privacy Concepts • Information Sharing • Authentication • Authorization

SAML (Security Assertions Markup Language) is another OASIS initiative. SAML will provide a standard way to define user authentication, authorization, and attribute information in XML documents. As its name suggests, SAML will allow business entities to make assertions regarding the identity, authorizations, and attributes of a subject to other entities, which may be partner companies, other enterprise applications, and so on. These assertions will be passed as XML documents, either pushed from the Asserting Party to the Relying Party, or pulled from the Asserting Party by the Relying Party.

SAML is relevant to privacy because the Liberty Alliance, a consortium of companies committed to defining a framework of standards and processes for federated identity, has decided to use SAML as the syntax for communicating authentication assertions from one business to another to enable Single Sign-On (SSO) for Web users. In a typical SSO scenario, a Web user would login to one site, and then, without needing to present any additional credentials, be able to access the resources of a second site as if they had actually logged-in. In addition to SSO, Liberty will define mechanisms for the passing of user information from one Web site to another; SAML supports this information sharing through its attribute assertions. The following listing gives an example of such an Attribute assertion (omitting some of the namespace details for clarity), the assertion states that the designated subject has an AAA credit rating.

<saml:Assertion>
  <saml:AttributeStatement>
    <saml:Subject>
      <saml:NameIdentifier
        SecurityDomain=" www.creditcheck.com"
        Name="averagejoe" />
    </saml:Subject>
    <saml:Attribute
          AttributeName="CreditRating"
      AttributeNamespace="http://www.creditcheck.com">
      <saml:AttributeValue>
        AAA
      </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

In order for the recipient of such an assertion to trust it, the recipient must be able to authenticate that the assertion did indeed come from the entity who claims to have sent it (i.e., it hasn't been sent by an impersonator). This authentication will be accomplished through the sender attaching an XML Signature over the SAML assertion; by verifying this XML Signature, the recipient of the assertion will be able to determine its authenticity. The confidentiality of this information -- obviously a requirement if the privacy of the individual is to be respected -- could be achieved through the use of XML Encryption. (Note that if the confidentiality of the information received does not need to persist, then confidentiality of the information in transit could be achieved through a transport layer mechanism like SSL.)

Conclusion

Privacy, ensuring that e-business customers remain in control over the personal information they share with online businesses, is one of the key issues facing today's companies as they attempt to take advantage of the great potential the Internet has for creating personalized and trusted relationships with customers. XML, not surprisingly, plays a critical role, both aggravating the problem through the free-flow of information it enables and providing syntax that offers a piece of the technology puzzle for solving the problem.

---