[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] WS Trust
Yes - the model itself is completely abstract of WS protocols. This is what I was also advocating for WS-Security, WS-SX, WS-Policy and other WS-* specs. If we take the implied abstract models behind them, it will fill the gap in between SOA and the on the wire protocol in the RA. Duane On 12/8/06 7:24 AM, "Danny Thornton" <danny_thornton2@yahoo.com> wrote: > 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 -- ********************************************************** 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]