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.