WS-Trust: Interoperable Security for Web Services
by Paul Madsen
|
Pages: 1, 2
WS-Trust Scenario
In this section we'll explore how WS-Security and WS-Trust may be used together to afford both message-layer security and interoperability across security infrastructures for a SOAP-based Web Service. We will see that the web service itself will be afforded the required authentication of clients and integrity and confidentiality of messages, while being insulated from much of the details and complexity of the underlying infrastructure, with the result being transparent (to the service) security.
The basic architecture is shown in the figure below. A SOAP client sends a SOAP message to a business application SOAP service (for the sake of this example a purchasing application), which, after appropriate business processing, sends the SOAP response back. Supporting this fundamental exchange are the components of the security infrastructure, a SOAP gateway and a security token service (STS), which work together to ensure that the SOAP service receives only messages with "appropriate" security tokens.
|
|
The SOAP gateway and STS will use WS-Trust messages to enable interoperable processing of the more fundamental WS-Security protected SOAP message sent between the client and the service.
For this scenario, we make the following assumptions:
The client understands X.509 certificates only. It uses an XML Signature (keyed by the private key associated with an X.509 certificate issued to it by some known Certificate Authority) to protect the integrity of its outgoing messages and to allow their provenance to be determined.
The service understands SAML only. It will accept only SAML Authentication Assertions as Security Tokens within the SOAP messages it receives.
The service does not directly trust the client.
The client is not required to anticipate the preference that the service has for SAML Assertions.
Message flow
I discuss here only the incoming SOAP request sent by the client. The message flow could be run in reverse to ensure that the associated SOAP response would be processable and trusted by the client on its receipt.
Message 1 -- WS-Security message with X.509 certificate
The SOAP client sends the initial WS-Security protected request to the SOAP service. The request is shown below:
(In this and subsequent XML listings, some details (e.g. full namespace declarations) are omitted for the sake of clarity.)
1 <soap:Envelope>
2 <soap:Header>
3 <ws:Security>
4 <ws:BinarySecurityToken id="X509token" ValueType="X.509">
5 sdfOIDFKLSoidefsdflk …
6 </ws:BinarySecurityToken>
7 <ds:Signature>
8 <ds:Reference>
9 <ds:Ref URI="#PO"/>
10 </ds:Reference>
11 <ds:SignatureValue>akjsdflaksf</ds:SignatureValue>
12 <ds:KeyInfo>
13 <ws:BinarySecurityTokenReference URI="#X509token"/>
14 </ds:KeyInfo>
15 </ds:Signature>
16 </ws:Security>
17 </soap:Header>
18 <soap:Body>
19 <po:PurchaseOrder ID="PO"/>
20 </soap:Body>
21 </soap:Envelope>The identity of the client (and the integrity of the message) is
asserted through an XML Signature [Lines 7-15], keyed by a private key
associated with the X.509 certificate contained within the
BinarySecurityToken element [Lines 4-6]. The X.509
certificate is an assertion as to the binding between the identity of the
client and a public key -- it is through the XML Signature that the SOAP
client demonstrates that they have the associated private key and does
indeed own the identity asserted within the certificate.
The SOAP client sent the SOAP request to the address specified in the service's WSDL document -- this address is the SOAP gateway. Alternatively the WSDL could specify the service itself and the gateway would intercept these requests. Either way, the gateway acts as the first line of defense for the services it fronts. Consequently, it is the gateway that is first presented with the incoming WS-Security protected SOAP message, and it is therefore the gateway that must make the first decision regarding its security processing (SOAP gateways typically offer capabilities beyond security, e.g. schema validation.)
It may be the case that the gateway is aware of the service's "preference" for SAML and would therefore be able to identify the incompatibility were it to forward on the SOAP message as-is (i.e. with its embedded X.509 certificate) to the targeted service. Alternatively and less efficiently, it could route all incoming SOAP requests to an appropriate STS authority for "token processing". Either way, before the incoming SOAP request is passed onto the service, the X.509 certificate must be mapped into an appropriate SAML Assertion through the gateway requesting this operation of the STS using a WS-Trust Token Exchange Request.
Message 2 - WS-Trust Token Exchange Request
If the gateway were to remove the X.509 certificate (and associated XML Signature) from the SOAP message before delivering it onto the service, then the service would indeed be protected from the X.509 syntax. Beyond the obvious security implications of sending the message over this last leg in an unsecured manner, it is the certificate that contained the identity of the client, and it is most likely that this identity is relevant both to further security processing (i.e. is the request authorized) and to subsequent business processing (i.e. who gets charged). Consequently, the identity of the SOAP client must somehow persist to the SOAP service to enable this processing. There is therefore a need for a conversion of the X.509 security token to a format comprehensible to the SOAP service, (which, given our initial assumptions, is a SAML Authentication assertion).
For a mapping between X.509 and SAML to occur, it is apparent that some system entity must be able to comprehend both formats (and understand their correspondence). In this scenario it is the STS that is responsible for comprehending multiple security token formats. WS-Trust provides a protocol by which the SOAP gateway can request such a token conversion from the STS.
The following XML illustrates the request from the gateway to the Token Service for the creation of a SAML Assertion based on the X.509 certificate sent in the original SOAP message.
1 <soap:Envelope>
2 <soap:Header>
3 <ws:Security>
4
5 </ws:Security>
6 </soap:Header>
7 <soap:Body>
8 <wstrust:RequestSecurityToken>
9 <wstrust:TokenType>SAML</TokenType>
10 <wstrust:RequestType>ReqExchange</RequestType>
11 <wstrust:OnBehalfOf>
12 <ws:BinarySecurityToken id="originaltoken"
ValueType="X.509>
13 sdfOIDFKLSoidefsdflk …
14 </ws:BinarySecurityToken>
15 </wstrust:OnBehalfOf>
16 </wstrust:RequestSecurityToken>
17 </soap:Body>
18 </soap:Envelope>The SOAP Body contains the RequestSecurityToken element
[Lines 8-16]. The type of token that is being requested is identified as
SAML [Line 9]; the token for which it is being exchanged is listed within
the OnBehalfOf element [Lines 11-15]. The
OnBehalfOf element also notifies the STS that this request is
being made by the gateway on behalf of some other entity, namely the
client whose identity is asserted to in the contained token.
The signature calculated by the client over the original SOAP message
is not included in the RequestSecurityToken; the assumption
is that the gateway would have verified this signature before sending the
RequestSecurityToken. It could be the case that the STS's
policy required that this Signature be sent as well for audit purposes or
for the STS itself to perform the signature validation if the gateway were
unable to build the required chain of certificates.
Not shown are the mechanisms by which the gateway would authenticate to
the STS and by which the integrity of the request would be ensured. These
mechanisms could be applied at the transport layer (with the previously
identified limitations) or at the message layer. If the latter, the above
message would have additional security tokens and signatures in the
ws:Security element [Lines 3-5].
If there were no gateway in the picture, this WS-Trust request could also have been composed and sent by the service to the STS. The implication however is that the service would necessarily have more security "smarts", even if only the ability to recognize security tokens that it was incapable of dealing with.
Message 3 -- WS-Trust Security Token Exchange Response
After receiving the RequestSecurityToken message, and
verifying that it was indeed sent by the gateway, the STS will extract the
submitted security token from the request and, after processing, create an
appropriate token in response. In this scenario, this token will be a SAML
Authentication Assertion in the name of the client, targeted to the
service and signed by the STS. The following listing shows the
RequestSecurityTokenResponse message that the STS returns to
the gateway.
1 <soap:Envelope>
2 <soap:Header>
3 <ws:Security>
4
7 </ws:Security>
8 </soap:Header>
9 <soap:Body>
10 <wstrust:RequestSecurityTokenResponse>
11 <wstrust:TokenType>SAML</TokenType>
12 <wstrust:RequestedSecurityToken>
13 <saml:Assertion
14 AssertionID="2se8e/vaskfsdif="
15 Issuer="www.sts.com"
16 IssueInstant="2002-06-19T16:58:33.173Z">
17 <saml:Conditions
18 NotBefore="2002-06-19T16:53:33.173Z"
19 NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
20 <saml:AuthenticationStatement
21 AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:X.509"
22 AuthenticationInstant="2002-06-19T16:57:30.000Z">
23 <saml:Subject>
24 <saml:NameIdentifier
NameQualifier="service.com">Client</saml:NameIdentifier>
25 <saml:SubjectConfirmation>
26 <saml:ConfirmationMethod>
27 urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
28 </saml:ConfirmationMethod>
29 </saml:SubjectConfirmation>
30 </saml:Subject>
31 </saml:AuthenticationStatement>
32 <ds:Signature>
<-- calculated by STS --> </ds:Signature>
33 </saml:Assertion>
34 </wstrust:RequestedSecurityToken>
35 </wstrust:RequestSecurityTokenResponse>
36 </soap:Body>
37 </soap:Envelope>The STS returns to the gateway the SAML assertion in the
RequestedSecurityToken element [Lines 13-34] -- the SAML
assertion signed by the STS and recorded in the Signature
element [Line 32]. It is the application of this signature that allows
the STS to broker the trust between the client and the Sender; it was
through the trust that the STS was able to place in the original X.509
certificate that it issued a corresponding SAML assertion.
This dynamic brokering of trust is more comparable to the way in which Kerberos enables cross-domain trust than to the X.509 world. Kerberos accomplishes cross-domain trust through its authorities playing an active "run-time" role in the trust brokering. If a client in one Kerberos realm wants to access a service belonging to another realm, it must first ask its own KDC for a ticket for the KDC of the other realm and then use this ticket to request of this remote KDC a ticket for the desired service. Although the SOAP client in our scenario is oblivious to the brokering being performed on its behalf by the actively involved STS (which plays the role of an authority for the service), the similarities between Kerberos and the WS-Trust model are clear. Indeed, many aspects of the WS-Trust proposal have direct analogies in Kerberos, e.g. forwardable and proxyable tokens.
Note that the NameIdentifier element [Line 24] carries an
identifier for the client in a namespace that is presumably meaningful to
the service, this identified by the NameQualifier attribute. Although the
original identifier was contained within the binary X.509 certificate and
was not consequently visible in Message 1, the assumption is that by
default it would not be directly meaningful to the service. The
ConfirmationMethod element [Lines 26-28] lists
sender-vouches, meaning that the ultimate sender of this
assertion (the gateway) will be acting on behalf of the subject within the
assertion.
It could well be the case that the STS could return to the gateway additional SAML assertions targeted for the service. For instance, if the STS played the role of an Authorization Policy Decision Point, it could create a SAML AuthorizationDecisionStatement defining the client's privileges with respect to the service.
Message 4 -- WS-Security message with SAML Token
The gateway receives the RequestSecurityTokenResponse
message from the STS. It is the gateway's responsibility to extract the
SAML assertion from the message and use it to recreate a version of the
original SOAP message that the service will be able to understand. The
following listing shows the WS-Security/SAML protected message that the
gateway forwards on to the service.
1 <soap:Envelope>
2 <soap:Header>
3 <ws:Security>
4 <saml:Assertion
5 AssertionID="2se8e/vaskfsdif="
6 Issuer="www.sts.com"
7 IssueInstant="2002-06-19T16:58:33.173Z">
8 <saml:Conditions
9 NotBefore="2002-06-19T16:53:33.173Z"
10 NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
11 <saml:AuthenticationStatement
12 AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:X.509"
13 AuthenticationInstant="2002-06-19T16:57:30.000Z">
14 <saml:Subject>
15 <saml:NameIdentifier>
Client</saml:NameIdentifier>
16 <saml:SubjectConfirmation>
17 <saml:ConfirmationMethod>
18 urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
19 </saml:ConfirmationMethod>
20 </saml:SubjectConfirmation>
21 </saml:Subject>
22 </saml:AuthenticationStatement>
23 <ds:Signature>
<-- calculated by STS --> </ds:Signature>
24 </saml:Assertion>
25 </ws:Security>
26 </soap:Header>
27 <soap:Body>
28 <po:PurchaseOrder ID="PO"/>
29 </soap:Body>
30 </soap:Envelope>The gateway has inserted the SAML Assertion it received from the STS in
the SOAP header [Lines 4-24]. As the ConfirmationMethod
[Lines 17-19] lists sender-vouches, the service will likely
require additional mechanisms in order to place confidence in the SAML
Assertion beyond the fact that it has been signed by the STS. It will
require that the gateway authenticate so that the sender of the
SAML assertion can be verified in addition to its creator.
Discussion
This article has demonstrated how WS-Trust can enable interoperable WS-Security based message-layer security. The client and service in our scenario were insulated from the fact that they share neither a common security token format nor direct trust through the intervention of the gateway and STS in message processing on their behalf.
The benefit of this model is more transparent security to the client and service. The burden of understanding security token formats and managing trust relationships with external entities is removed from their shoulders (actually those of their developers and administrators) and placed on the STS (a service dedicated to this role).
This model of dedicated security services accessed through SOAP-based interfaces is also relevant for other security processing (e.g. digital signature creation, data encryption, authorization decisions etc.) With the burden of such functionality removed, the business applications can concentrate even more on the business logic and leave security to the infrastructure. Additionally, because security processing is performed in a centralized manner, the model offers advantages for ensuring these security protections are applied in a consistent and policy-respecting manner.
Summary
Marx's ideas have been difficult to implement in a social context. Perhaps it will be in web services security that it will find application -- from each SOAP client, according to its security processing abilities, to each SOAP service, according to its security policy.
Resources
Read the WS-Trust proposal at IBM's site.
Read the working draft of the WS-Security SOAP Message Security specification at the OASIS Web Services Security document page.
Read the working draft of the WS-Security X.509 Certificate Token Profile specification at the OASIS Web Services Security document page.
Read the working draft of the WS-Security SAML Token Profile specification at the OASIS Web Services Security document page.
