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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: RE: [ws-sx] Issue 153: Generalized Interactive Challenge forWS-Trust


It will be applied in Trust 1.4. Similar to WSS since this is new it will go in a Trust 1.4 namespace, the existing Trust 1.3 bits stay in the same namespace.

I expect to produce new drafts once we get the 2119 terms applied from the errata issues. That isn't something I want to have to do twice. :-p

-----Original Message-----
From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
Sent: Monday, January 07, 2008 1:46 PM
To: Marc Goodner
Cc: ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue 153: Generalized Interactive Challenge for WS-Trust

Marc,

Is this a proposal for an extension of the WS-Trust 1.3 standard? As in
a new version of WS-Trust?

Thanks,
prateek
>
> Issue 153
>
> *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> *Sent:* Tuesday, November 13, 2007 4:16 PM
> *To:* ws-sx@lists.oasis-open.org
> *Subject:* [ws-sx] New Issue: Generalized Interactive Challenge for
> WS-Trust
>
> PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
> The issues coordinators will notify the list when that has occurred.
>
> Title: Generalized Interactive Challenge for WS-Trust
> Protocol: Trust
> Artifact:  spec
> Type: design
>
> Description:
>
> The security token services (STS) framework defined by WS-Trust allows
> for a simple request and response for security tokens as well as an
> extension mechanism to enable exchanges for negotiation and
> challenges. The WS-Trust specification defines a "signature challenge"
> construct as a specific type of exchange that makes use of the above
> extension mechanism for general exchanges.
>
> There are many scenarios where an STS may require further interactions
> with the requestor prior to returning a security token, beyond the
> authentication requirements expressed in its security policy and
> satisfied by the security tokens bound to the initial RST request
> through SOAP security header. Following are examples of exchanges
> where an STS may further challenge the requestor for additional
> interactive input, to supplement authentication information submitted
> in the original request in the SOAP security header, before issuing
> the requested token.
>
> * Prompt the user for an additional shared secret such as a PIN.
>
> * Prompt the user for second-factor authentication data such as "one
> time password" (OTP) taken from an OTP device or module.
>
> * Prompt the user for answers to text-based secret questions (e.g.,
> mother's maiden name, date of birth) as either text inputs or
> multiple-choice inputs.
>
> * Prompt the user for answers to image-based challenges as either text
> inputs or multiple-choice inputs.
>
> The challenge may be selectively issued by the STS only for particular
> users or for token requests for particular target scopes. The specific
> user or target scope can only be identified after the initial request
> is received.
>
> In all such cases, however, the supplemental authentication
> information required by the STS does not cause a reset of the security
> policy of the STS. Specifically, the additional information requested
> by the STS in the form of challenge and response exchanges is carried
> entirely within the RST/RSTR message bodies and does not affect the
> authentication information carried inside the SOAP security headers in
> any way. The security token content in the SOAP security headers
> remains unchanged across the user interaction challenge/response
> exchanges.
>
> This proposal defines a "user interaction challenge" construct, as a
> strongly typed mechanism, for issuing interactive challenges and
> receiving corresponding responses within the WS-Trust framework inside
> the bodies of RST/RSTR messages. The proposed mechanism easily fits
> into the general exchanges mechanism already defined in WS-Trust.
>
> Proposal:
>
> Add the following section to section 8, Negotiation and Challenge
> Extensions after section 8.2. Existing sections 8.3 through 8.6
> increment accordingly. To be consistent with the existing section the
> examples for interactive challenges should be added as section 8.8
> after the existing section 8.6 (renumbered to 8.7) on signature
> challenge examples. Remaining existing sections 8.7 through 8.9
> increment accordingly.
>
> Also, add a new property to SecurityPolicy 1.3 in the Trust 1.3
> assertion and a new nested assertion to control the setting of that
> property.
>
> All new elements, attributes, URIs are to be defined under the Trust
> 1.4 namespace, represented here with the wst14 namespace prefix and
> the placeholder URI http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm.
> New assertions for SecurityPolicy 1.3 are defined under sp13 namespace
> prefix and the placeholder URI
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/yyyymm.
>
> WS-SecurityPolicy change for Trust 1.3 assertion
>
> [Interactive Challenge]
>
> This boolean property indicates whether interactive challenges are
> supported. A value of 'true' indicates that a
> wst14:InteractiveChallenge element is supported inside of an RSTR sent
> by the server to the client. A value of 'false' indicates that
> wst14:InteractiveChallenge is not supported. A challenge issued by the
> server may increase the number of messages exchanged by the client and
> service in order to accommodate the wst14:InteractiveChallengeResponse
> element sent by the client to the server in response to the
> wst14:InteractiveChallenge element. There is an optimization in which
> a client MAY send the wst14:InteractiveChallengeResponse element in an
> initial RST to the server. A final RSTR containing the issued token
> will follow subsequent to the server receiving the
> wst14:InteractiveChallengeResponse element. This property has a
> default value of 'false'.
>
> /sp:Trust13/wsp:Policy/sp13:MustSupportInteractiveChallenge
>
> This optional element is a policy assertion indicates that the
> [Interactive Challenge] property is set to 'true'.
>
>
>   8.3 User Interaction Challenge
>
> User interaction challenge requests are issued by including the
> <InteractiveChallenge> element. The response is returned in a
> <InteractiveChallengeResponse> element. Both the challenge and
> response elements are specified within the
> <wst:RequestSecurityTokenResponse> element. In some instances, the
> requestor may issue a challenge to the recipient or provide a response
> to an anticipated challenge from the recipient in the initial request.
> Consequently, these elements are also allowed within a
> <wst:RequestSecurityToken> element. The challenge/response exchange
> between client and server MAY be iterated over multiple legs before a
> final response is issued. Note that the xml:lang attribute may be used
> where allowed via attribute extensibility to specify a language of
> localized elements and attributes using the language codes specified
> in [RFC 3066].
>
>
>     8.3.1 Challenge Format
>
> The syntax of the user interaction challenge element is as follows:
>
> <wst14:InteractiveChallenge xmlns:wst14="..." ...>
>
> <wst14:Title ...> /xs:string /</wst14:Title> ?
>
> <wst14:TextChallenge RefId="/xs:anyURI/" Label=/"xs:string"/?
> MaxLen="/xs:int/"? HideText="/xs:boolean/"? ...>
>
> <wst14:Image MimeType="/xs:string/"> /xs:base64Binary/ </wst14:Image> ?
>
> </wst14:TextChallenge> *
>
> <wst14:ChoiceChallenge RefId="/xs:anyURI/" Label="/xs:string/"?
> ExactlyOne="/xs:boolean/"? ...>
>
> <wst14:Choice RefId="/xs:anyURI/" Label=/"xs:string"/? ...>
>
> <wst14:Image MimeType="/xs:string/"> /xs:base64Binary/ </wst14:Image> ?
>
> </wst14:Choice> +
>
> </wst14:ChoiceChallenge> *
>
> < wst14:ContextData RefId="/xs:anyURI/"> /xs:any /</wst14:ContextData> *
>
> ...
>
> </wst14:InteractiveChallenge>
>
> The following describes the attributes and elements listed in the
> schema outlined above:
>
> .../wst14:InteractiveChallenge
>
> A container element for a challenge that requires interactive user input.
>
> .../wst14:InteractiveChallenge/wst14:Title
>
> An optional element that specifies an overall title text to be
> displayed to the user (e.g. a title describing the purpose or nature
> of the challenge). How the preferred language of the requestor is
> communicated to the STS is left up to implementations.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge
>
> An optional element that specifies a challenge that requires textual
> input from the user.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/@RefId
>
> A required attribute that specifies a reference identifier for this
> challenge element which is used to correlate the corresponding element
> in the response to the challenge.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/@MaxLen
>
> An optional attribute that specifies the maximum length of the text
> string that is sent as the response to this text challenge. This value
> serves as a hint for the user interface software at the requestor
> which manifests the end-user experience for this challenge.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/@HideText
>
> An optional attribute that specifies that the response to this text
> challenge MUST receive treatment as hidden text in any user interface.
> For example, the text entry may be displayed as a series of asterisks
> in the user interface. This attribute serves as a hint for the user
> interface software at the requestor which manifests the end-user
> experience for this challenge.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/@Label
>
> An optional attribute that specifies a label for the text challenge
> item (e.g. a label for a text entry field) which will be shown to the
> user. How the preferred language of the requestor is communicated to
> the STS is left up to implementations.
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/Image
>
> An optional element that contains a base64 encoded inline image
> specific to the text challenge item to be shown to the user (e.g. an
> image that the user must see to respond successfully to the challenge).
>
> .../wst14:InteractiveChallenge/wst14:TextChallenge/Image/@MimeType
>
> A required attribute that specifies a MIME type (e.g., image/gif,
> image/jpg) indicating the format of the image.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge
>
> An optional element that specifies a challenge that requires a choice
> among multiple items by the user.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@RefId
>
> A required attribute that specifies a reference identifier for this
> challenge element which is used to correlate the corresponding element
> in the response to the challenge.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@Label
>
> An optional attribute that specifies a title label for the choice
> challenge item (e.g., a text header describing the list of choices as
> a whole) which will be shown to the user. How the preferred language
> of the requestor is communicated to the STS is left up to implementations.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@ExactlyOne
>
> An optional attribute that specifies if exactly once choice must be
> selected by the user from among the child element choices. The absence
> of this attribute implies the value "false" which means multiple
> choices can be selected.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice
>
> A required element that specifies a single choice item within the
> choice challenge.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@RefId
>
> A required attribute that specifies a reference identifier for this
> specific choice item which is used to correlate the corresponding
> element in the response to the challenge.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@Label
>
> An optional attribute that specifies a text label for the choice item
> (e.g., text describing the individual choice) which will be shown to
> the user. How the preferred language of the requestor is communicated
> to the STS is left up to implementations.
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image
>
> An optional element that contains a base64 encoded inline image
> specific to the choice item to be shown to the user (e.g. an image
> that the user must see to respond successfully to the challenge).
>
> .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image/@MimeType
>
> A required attribute that specifies a MIME type (e.g., image/gif,
> image/jpg) indicating the format of the image.
>
> .../wst14:InteractiveChallenge/wst14:ContextData
>
> An optional element that specifies a value that MUST be reflected back
> in the response to the challenge (e.g., cookie). The element may
> contain any value. The actual content is opaque to the requestor; it
> is not required to understand its structure or semantics. This can be
> used by an STS, for instance, to store information between the
> challenge/response exchanges that would otherwise be lost if the STS
> were to remain stateless.
>
> .../wst14:InteractiveChallenge/wst14:ContextData/@RefId
>
> A required attribute that specifies a reference identifier for this
> context element which is used to correlate the corresponding element
> in the response to the challenge.
>
> .../wst14:InteractiveChallenge/{any}
>
> This is an extensibility mechanism to allow additional elements to be
> specified.
>
> .../wst14:InteractiveChallenge/@{any}
>
> This is an extensibility mechanism to allow additional attributes to
> be specified.
>
> The syntax of the user interaction challenge response element is as
> follows:
>
> <wst14:InteractiveChallengeResponse xmlns:wst14="..." ...>
>
> <wst14:TextChallengeResponse RefId="/xs:anyURI/" ...>
>
> /xs:string/
>
> / /</wst14:TextChallengeResponse> *
>
> <wst14:ChoiceChallengeResponse RefId="/xs:anyURI/"> *
>
> <wst14:ChoiceSelected RefId="/xs:anyURI/" /> *
>
> </wst14:ChoiceChallengeResponse>
>
> <wst14:ContextData RefId="/xs:anyURI/"> /xs:any /</wst14:ContextData> *
>
> ...
>
> </wst14:InteractiveChallengeResponse>
>
> The following describes the attributes and elements listed in the
> schema outlined above:
>
> .../wst14:InteractiveChallengeResponse
>
> A container element for the response to a challenge that requires
> interactive user input.
>
> .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse
>
> This element value contains the user input as the response to the
> original text challenge issued.
>
> .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse/@RefId
>
> A required attribute that specifies the identifier for the text
> challenge element in the original challenge which can be used for
> correlation.
>
> .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse
>
> A container element for the response to a choice challenge.
>
> .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/@RefId
>
> A required attribute that specifies the reference identifier for the
> choice challenge element in the original challenge which can be used
> for correlation.
>
> .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected
>
> A required element that specifies a choice item selected by the user
> from the choice challenge.
>
> .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected/@RefId
>
> A required attribute that specifies the reference identifier for the
> choice item in the original choice challenge which can be used for
> correlation.
>
> .../wst14:InteractiveChallengeResponse/wst14:ContextData
>
> An optional element that carries a context data item from the original
> challenge that is simply reflected back.
>
> .../wst14:InteractiveChallengeResponse/wst14:ContextData/@RefId
>
> A required attribute that specifies the reference identifier for the
> context data element in the original challenge which can be used for
> correlation.
>
> .../wst14:InteractiveChallengeResponse/{any}
>
> This is an extensibility mechanism to allow additional elements to be
> specified.
>
> .../wst14:InteractiveChallengeResponse/@{any}
>
> This is an extensibility mechanism to allow additional attributes to
> be specified.
>
> In order to prevent certain types of attacks, such as
> man-in-the-middle or replay of response, the challenge SHOULD be bound
> to the response. For example, an STS may use the <ContextData> element
> in the challenge to include a digest of any relevant replay protection
> data and verify that the same data is reflected back by the requestor.
>
>
>     8.3.2 PIN and OTP Challenges
>
> Two commonly used challenges, usually as forms of second
> authentication factors, that require user interaction are:
>
>     * a challenge for a secret PIN,
>     * a challenge for a one-time-password (OTP).
>
> This challenge may be issued by an STS using the "text challenge"
> format within a user interaction challenge specified in the section
> above. A requestor responds to the challenge with the PIN/OTP value
> along with the corresponding /@RefId/ attribute value for the text
> challenge which is used by the STS to correlate the response to the
> original challenge. This pattern of exchange requires that the
> requestor must receive the challenge first and thus learn the /@RefId/
> attribute value to include in the response.
>
> There are cases where a requestor may know /a priori/ that the STS
> challenges for a single PIN/OTP and, as an optimization, provide the
> response to the anticipated challenge in the initial request. The
> following distinguished URIs are defined for use as the value of the
> /@RefId/ attribute of a <TextChallengeResponse> element to represent
> PIN and OTP responses using the optimization pattern.
>
> http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN
>
> http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/OTP
>
> An STS may choose not to support the optimization pattern above for
> PIN/OTP response. In some cases, an OTP challenge from the STS may
> include a dynamic random value that the requestor must feed into the
> OTP generating module before an OTP response is computed. In such
> cases, the optimized response pattern may not be usable.
>
>
>     8.8 Challenge Examples
>
>
>       8.8.1 Text and choice challenge
>
> Here is an example of a user interaction challenge using both text and
> choice challenges. In this example, a user requests a custom token
> using a username/password for authentication. The STS uses the
> challenge mechanism to challenge the user for additional information
> in the form of a secret question (/i.e./, Mother's maiden name) and an
> age group choice. The challenge additionally includes one contextual
> data item that needs to be reflected back in the response. The user
> interactively provides the requested data and, once validated, the STS
> issues the requested token. All messages are sent over a protected
> transport using SSLv3.
>
> The requestor sends the initial request that includes the
> username/password for authentication as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> <wsse:Security>
>
> <wsse:UsernameToken>
>
> <wsse:Username>Zoe</wsse:Username>
>
> <wsse:Password Type="http://...#PasswordText";>ILoveDogs</wsse:Password>
>
> </wsse:UsernameToken>
>
> </wsse:Security>
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityToken>
>
> <wst:TokenType>http://example.org/customToken</wst:TokenType
> <http://example.org/customToken%3c/wst:TokenType>>
>
> <wst:RequestType>...</wst:RequestType>
>
> </wst:RequestSecurityToken>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The STS issues a challenge for additional information using the user
> interaction challenge mechanism as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst14:InteractiveChallenge xmlns:wst14="..." >
>
> <wst14:Title>
>
> Please answer the following additional questions to login.
>
> </wst14:Title>
>
> <wst14:TextChallenge RefId=http://.../ref#text1
>
> Label="Mother's Maiden Name" MaxLen=80 />
>
> <wst14:ChoiceChallenge RefId="http://.../ref#choiceGroupA";
>
> Label="Your Age Group:" ExactlyOne="true">
>
> <wst14:Choice RefId="http://.../ref#choice1"; Label="18-30" />
>
> <wst14:Choice RefId="http://.../ref#choice2"; Label="31-40" />
>
> <wst14:Choice RefId="http://.../ref#choice3"; Label="41-50" />
>
> <wst14:Choice RefId="http://.../ref#choice4"; Label="50+" />
>
> </wst14:ChoiceChallenge>
>
> <wst14:ContextData RefId="http://.../ref#cookie1";> .../
> /</wst14:ContextData>
>
> </wst14:InteractiveChallenge>
>
> </wst:RequestSecurityTokenResponse>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The requestor receives the challenge, provides the necessary user
> experience for soliciting the required inputs, and sends a response to
> the challenge back to the STS as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst14:InteractiveChallengeResponse xmlns:wst14="..." >
>
> <wst14:TextChallengeResponse RefId="http://.../ref#text1";>
>
> Goldstein
>
> </wst14:TextChallengeResponse>
>
> <wst14:ChoiceChallengeResponse RefId="http://.../ref#choiceGroupA";>
>
> <wst14:ChoiceSelected RefId="http://.../ref#choice3"; />
>
> </wst14:ChoiceChallengeResponse>
>
> <wst14:ContextData RefId="http://.../ref#cookie1";> .../
> /</wst14:ContextData>
>
> </wst14:InteractiveChallengeResponse>
>
> </wst:RequestSecurityTokenResponse>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The STS validates the response containing the inputs from the user,
> and issues the requested token as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponseCollection>
> <wst:RequestSecurityTokenResponse>
>
> <wst:RequestedSecurityToken>
>
> <xyz:CustomToken xmlns:xyz="...">
>
> ...
>
> </xyz:CustomToken>
>
> </wst:RequestedSecurityToken>
>
> <wst:RequestedProofToken>
>
> ...
>
> </wst:RequestedProofToken>
>
> </wst:RequestSecurityTokenResponse>
>
> </wst:RequestSecurityTokenResponseCollection>
>
> </S11:Body>
>
> </S11:Envelope>
>
>
>       8.8.2 PIN challenge
>
> Here is an example of a user interaction challenge using a text
> challenge for a secret PIN. In this example, a user requests a custom
> token using a username/password for authentication. The STS uses the
> text challenge mechanism for an additional PIN. The user interactively
> provides the PIN and, once validated, the STS issues the requested
> token. All messages are sent over a protected transport using SSLv3.
>
> The requestor sends the initial request that includes the
> username/password for authentication as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> <wsse:Security>
>
> <wsse:UsernameToken>
>
> <wsse:Username>Zoe</wsse:Username>
>
> <wsse:Password Type="http://...#PasswordText";>ILoveDogs</wsse:Password>
>
> </wsse:UsernameToken>
>
> </wsse:Security>
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityToken>
>
> <wst:TokenType>http://example.org/customToken</wst:TokenType
> <http://example.org/customToken%3c/wst:TokenType>>
>
> <wst:RequestType>...</wst:RequestType>
>
> </wst:RequestSecurityToken>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The STS issues a challenge for a secret PIN using the text challenge
> mechanism as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst14:InteractiveChallenge xmlns:wst14="..." >
>
> <wst14:TextChallenge
>
> RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN";
>
> Label="Please enter your PIN" />
>
> </wst14:TextChallenge>
>
> </wst14:InteractiveChallenge>
>
> </wst:RequestSecurityTokenResponse>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The requestor receives the challenge, provides the necessary user
> experience for soliciting the PIN, and sends a response to the
> challenge back to the STS as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst14:InteractiveChallengeResponse xmlns:wst14="..." >
>
> <wst14:TextChallengeResponse
>
> RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN";>
>
> 9988
>
> </wst14:TextChallengeResponse>
>
> </wst14:InteractiveChallengeResponse>
>
> </wst:RequestSecurityTokenResponse>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The STS validates the PIN response, and issues the requested token as
> follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponseCollection>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst:RequestedSecurityToken>
>
> <xyz:CustomToken xmlns:xyz="...">
>
> ...
>
> </xyz:CustomToken>
>
> </wst:RequestedSecurityToken>
>
> <wst:RequestedProofToken>
>
> ...
>
> </wst:RequestedProofToken>
>
> </wst:RequestSecurityTokenResponse>
>
> </wst:RequestSecurityTokenResponseCollection>
>
> </S11:Body>
>
> </S11:Envelope>
>
>
>       8.8.3 PIN challenge with optimized response
>
> The following example illustrates using the optimized PIN response
> pattern for the same exact challenge as in the previous section. This
> reduces the number of message exchanges to two instead of four. All
> messages are sent over a protected transport using SSLv3.
>
> The requestor sends the initial request that includes the
> username/password for authentication as well as the response to the
> anticipated PIN challenge as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> <wsse:Security>
>
> <wsse:UsernameToken>
>
> <wsse:Username>Zoe</wsse:Username>
>
> <wsse:Password Type="http://...#PasswordText";>ILoveDogs</wsse:Password>
>
> </wsse:UsernameToken>
>
> </wsse:Security>
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityToken>
>
> <wst:TokenType>http://example.org/customToken</wst:TokenType
> <http://example.org/customToken%3c/wst:TokenType>>
>
> <wst:RequestType>...</wst:RequestType>
>
> <wst14:InteractiveChallengeResponse xmlns:wst14="..." >
>
> <wst14:TextChallengeResponse
>
> RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN";>
>
> 9988
>
> </wst14:TextChallengeResponse>
>
> </wst14:InteractiveChallengeResponse>
>
> </wst:RequestSecurityToken>
>
> </S11:Body>
>
> </S11:Envelope>
>
> The STS validates the authentication credential as well as the
> optimized PIN response, and issues the requested token as follows.
>
> <S11:Envelope ...>
>
> <S11:Header>
>
> ...
>
> </S11:Header>
>
> <S11:Body>
>
> <wst:RequestSecurityTokenResponseCollection>
>
> <wst:RequestSecurityTokenResponse>
>
> <wst:RequestedSecurityToken>
>
> <xyz:CustomToken xmlns:xyz="...">
>
> ...
>
> </xyz:CustomToken>
>
> </wst:RequestedSecurityToken>
>
> <wst:RequestedProofToken>
>
> ...
>
> </wst:RequestedProofToken>
>
> </wst:RequestSecurityTokenResponse>
>
> </wst:RequestSecurityTokenResponseCollection>
>
> </S11:Body>
>
> </S11:Envelope>
>



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