should be equally valid for a non WS environment.
but not WS based.
OK, how does this work with the PDP and PEP ala
XACML?
Ken
On Dec 7, 2006, at 1:06 PM, Chiusano, Joseph wrote:
In case it helps, here is an excerpt from a March
2003 article that
I wrote on WS-Trust - though the spec has changed
since then, I
think if you look at the description I provided
below, most if not
all of the concepts can be applied to the figure
that Duane
provided. The figure below is my own, as there was
no such figure
in WS-Trust at the time.
Joe
P.S. My other choice was to send you a very short
block of Word Art
with the word "voiceover".;)
Managing Trust Relationships: WS-Trust
All of the concepts discussed to this point are
highly important,
but they cannot be useful unless there is a trust
relationship
between two parties. This is the focus of WS-Trust
specification,
released in December by 2002 by Microsoft, IBM,
Verisign, and RSA
Security.
Trust Engine/Security Token Service
WS-Trust introduces the notion of a trust engine,
a conceptual
component of a Web service that evaluates the
security-related
aspects of a message. A trust engine verifies
that:
The claims in a security token are sufficient to
comply with the
policy and that the message conforms to the
policy.
The attributes of the claimant are proven by the
signatures.
The issuers of the security tokens are trusted to
issue the claims
they have made.
For example, if a policy stated that only Kerberos
tickets were
accepted as a security token, the trust engine of
a Web service
would enforce this requirement for all incoming
messages. The WS-
Trust specification also introduces the notion of
a security token
service that issues security tokens based on
trust, similar to a
certificate authority (CA).
The figure below depicts a "sender" and "receiver"
Web service,
each with its own trust engine. A security token
service is also
depicted, from which the sender Web service will
request a security
token to be used for its interaction with the
receiver Web service.
The sender Web service can request a security
token based on the
receiver Web service's policies, using the
mechanisms described
earlier in this article. The sender Web service
will use its trust
engine to authenticate the security token service,
while the
receiver Web service will use its trust engine to
authenticate the
sender Web service.
XML Example: Security Token Request/Response
The following example demonstrates a request for a
security token
(X.509 certificate), and the response with the
certificate. The
<wsse:BinarySecurityToken> was seen earlier in the
description of
the WS-Security specification.
<wsse:RequestSecurityToken>
<wsse:TokenType>wsse:X509v3</wsse:TokenType>
<wsse:RequestType>wsse:ReqIssue</wsse:RequestType>
</wsse:RequestSecurityToken>
<wsse:RequestSecurityTokenResponse>
<wsse:RequestedSecurityToken>
<BinarySecurityToken ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary">
MIIEZzCCA9CgAwIBAgIQEmtJZc0...
</BinarySecurityToken>
</wsse:RequestedSecurityToken>
</wsse:RequestSecurityTokenResponse>
In the above example, the <wsse:RequestType>
element value of
"ReqIssue" denotes the issuance of a security
token. Other valid
values are "ReqValidate" (validate security token)
and
"ReqExchange" (exchange security token).
Challenges
In some cases, a security token service may choose
to challenge the
requestor of a security token. For example, this
may occur if the
security token service does not trust the nonce
and timestamp (for
example, the freshness) in the message. Or, the
security token
service may challenge the signature within the
message. Challenge
requests and responses are issued by specifying
challenge and
response elements within a
<wsse:RequestSecurityTokenResponse>
element, in a negotiation-type scenario.
XML Example: Signature Challenge
Signature challenges are processed using the
<wsse:SignChallenge>
element, as shown in the following example:
<wsse:SignChallenge>
<wsse:Challenge>Describes the message parts to
be
signed...</wsse:Challenge>
</wsse:SignChallenge>
The <wsse:Challenge> element in the above example
uses one of two
possible mechanisms to describe the message parts
to be signed:
either an XPath expression, or one of several
"message part
selection functions" that are defined in the
WS-PolicyAssertions
specification. The <wsse:SecurityTokenReference>
element is used to
reference security tokens that are passed as part
of the
negotiation process. Once the sender receives this
challenge, they
would normally create a new signature that
includes the specified
message parts and return the new signature in a
<wsse:SignChallengeResponse> element.
Specification Location
The WS-Trust specification can be found at http://
msdn.microsoft.com/ws/2002/12/ws-trust.
Joseph Chiusano
Associate
Booz | Allen | Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Sent: Thursday, December 07, 2006 12:54 PM
To: Duane Nickull
Subject: Re: [soa-rm-ra] WS Trust
A short voiceover?
On Dec 7, 2006, at 12:44 PM, Duane Nickull wrote:
Everyone is raving about the all-new Yahoo! Mail beta.