[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]