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


Frank et al:

I wasn't advocating adopting the technology, just the model.  The model for
trust is agnostic to the weighting issue you describe below.  It is only
about the establishment of a trust DMZ.  The chain of trust is not relevant
at this level.

Duane


On 12/7/06 10:26 AM, "Francis McCabe" <frankmccabe@mac.com> wrote:

> Right now, this stuff looks both too low level and missing the larger
> point.
> 
> Some random responses
> 1. the current efforts in message security are focusing on actually
> reading the communications to make sure that policies are being
> complied with (e.g., no discussion of ira* in public) This gets
> around the problem of a properly signed message containing stuff that
> it should not.
> 2. Real trust is a function of who you are and what you are trying to
> do. I.e., you cannot separate out the roles from the action.
> 3. We made the decision some time ago not to make technology choices.
> 
> Frank
> 
> On Dec 7, 2006, at 10:06 AM, 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:
>> 
>>> I would like to encourage the use of the WS-Trust model as part of
>>> the
>>> security aspects of the RA.  The model is attached.
>>> 
>>> Duane
>>> -- 
>>> **********************************************************
>>> Sr. Technical Evangelist - Adobe Systems, Inc.           *
>>> Chair - OASIS SOA Reference Model Technical Committee    *
>>> Blog: http://technoracle.blogspot.com                    *
>>> Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
>>> **********************************************************
>>> 
>>> <Picture 1.png>
>> 
>> 
>> ----------------------------------------------------------------------
>> --------------------
>> Ken Laskey
>> MITRE Corporation, M/S H305     phone:  703-983-7934
>> 7515 Colshire Drive                        fax:        703-983-1379
>> McLean VA 22102-7508
>> 
> 

-- 
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************



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