OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] WS Trust


Hi Duane,

Can you abstract the WS out and add that to the
security section?  The SOA reference architecture
should be equally valid for a non WS environment. 
There are many development environments, particularly
in the real time world, that can be service oriented
but not WS based.  

Danny


--- Ken Laskey <klaskey@mitre.org> wrote:

> 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:SecurityTokenReference>...</wsse:SecurityTokenReference>
> > </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
> > Visit us online@ http://www.boozallen.com
> >
> >
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Thursday, December 07, 2006 12:54 PM
> > To: Duane Nickull
> > Cc: soa-rm-ra@lists.oasis-open.org
> > Subject: Re: [soa-rm-ra] WS Trust
> >
> > A short voiceover?
> >
> > On Dec 7, 2006, at 12:44 PM, Duane Nickull wrote:
> >
> 
=== message truncated ===



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]