[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 155 - 159: Generalized Interactive Challenge forWS-Trust
|
These were recorded as issues
155 to 159. I’ve responded in line to each one below. From: Hal Lockhart
[mailto:hlockhar@bea.com] I have a number of different kinds of
reservations about this proposal. [issue 155] 1. I think
being able to support challenge-response AuthN for Web Services is a good thing
and should not be limited to cases where a token is being issued. I also think
the design of sending back a RST Response containing a Challenge Request which
is responded to with an RST (request) containing a Challenge Response is clumsy
and will cause confusion. I understand that WST has a signature
challenge scheme defined in general terms, but my assumption was that this was
to provide proof of possession of a private key in the case where the requestor
is providing the public key to be used in the token to be issued. (This is a
standard feature of X.509 cert issuance.) Since the token in question was the
one being issued by the STS, it makes sense for this interaction to be a part
of WS-T. However Issue 153 pertains to any c-r AuthN regardless of whether a
token is being issued or not. Therefore I think it should be available anytime
WSS is used. The general scheme I would propose is
analogous to the way HTTP works. If the receiver of any message wants to use
c-r, it should send a SOAP fault message with an agreed coded to indicate c-r.
The Interactive Challenge would be contained in one of the fields of the fault
message. Then the original message would be re-sent with the Interactive
Challenge Response added to the Security Header. (We could consider optimizing this
in some way to avoid resending the whole message, but no one seems to care in
the HTTP case and it does enable statelessness.) I realize that there is an issue with defining
anything for WSS, so I would settle for a proposal which would allow us to add
this to WS-T now and later drop it into WSS-next. MG: One of the key points of WS-Trust is that it separates
claim acquisition from claim presentation as defined in WS-Security.
Specifically, there was an overt decision to not complicate application protocols
(their state models) with multi-leg challenges. It is very complex to
have specialized error semantics that are passed in the header without
processing the body. This gets messy with the SOAP model or you need
complex bodies which are even more complicated. Instead, this pattern was
placed into WS-Trust so that applications have a simple “require
claims” model. They can fault and provide policy as to what claims
they need and not have to define application-level semantics. That is, it
can be handled completely by infrastructure if desired. Essentially this
makes the claims acquisition and negotiation a new application-level protocol
which can leverage the SOAP semantics. So I believe that is a core model
of WS-Trust and the difference between it and WS-Security. The existing WS-Trust
specification calls out a specific model that allows any kind of custom
challenges to be used and specifically has the RST->RSTR->RSTRC pattern
where the RSTR messages allow arbitrary challenges and responses to be
exchanged. This has been in WS-Trust since the TC was formed. In
fact, at the first TC meeting we specifically changed the final message from
RSTR to RSTRC to allow a formal differentiation between the intermediary
exchange legs and the final issuance. The existing standard formally
defines a mechanism for Binary Exchanges which does not involve a signature
challenge, but allows for non-XML to be exchanged. There is a section in
the spec that specifically discusses arbitrary XML exchanges and these are not
limited to PoP. [issue 156] 2. Another
issue is I think we need to define error handling more specifically. What
happens when the IC or ICR get lost? What happens if you get two in a row? If
the requester doesn’t know how to respond to the challenge, what does it
do? Basically we are moving from a stateless protocol to a statefull one, so we
need to be careful. MG: This is applicable to all forms of challenges already
defined in the WS-Trust spec that involve multiple legs; it is not specific to
interactive challenges. For example, the question could be asked what happens
if the requestor does not receive the response to the token request in a
two-leg exchange, or what happens if an intermediate leg gets lost in a
SignatureChallenge? That said, message delivery and correlation are handled by
the underlying messaging stack and transport. The challenges and corresponding
responses can be correlated by the WS-Trust protocol handler (on top of the
message stack) based on the ID-valued attribute “RefId” included
with the challenge and response elements. We could state that the challenges
and responses are idempotent as long as they bear the same identifiers, but do
we need to? The WS-Trust standard already
makes any multi-leg exchange involving challenges to be stateful anyway. In the
interactive challenge proposal, we make it a little better by allowing for a
server to effectively become stateless by embedding state in the
“ContextData” element in the challenge (like a cookie) that gets
reflected back by the requestor. [issue 157] 3. I am
confused about the PIN. What is a PIN? Is it just a kind of password? is it
required to be numeric? Usually a PIN is not transmitted over the wire. For
example: Smartcard PIN is only used locally, ATM PIN is encrypted before being
sent. What is the use case here? MG: No, there are no restrictions on the content of PIN. It
can be thought of as a shared secret between the requestor and the token issuer
used as an additional means of authentication. [issue 158] 4. I have
a lot of concerns about the text fields like Title and TextChallenge,
ChoiceChallenge, etc. a. First is the fact that there is no way to
deal with Internationalization. MG: I don’t understand. The content of any string-valued XML element can be
localized and the locale reflected in an xml:lang attribute carried by that XML
element. That’s described in section 8.3 below. b. How is the text to be interpreted? HTML?
Are escaped control characters allowed? Is Javascript allowed? I see a lot of
potential for security attacks here. MG: The text is to be interpreted as ordinary strings
(Unicode) only. We should understand the security attacks if there are
potential attacks. [issue 159] 5. The use
case for image is unclear. The intent seems to be to support CAPTCHA functionality.
It does not seem to support user chosen image functionality. (see for example
Yahoo login) Is this correct? MG: The image can be thought of
as an alternate/additional way to label each challenge element just like a text
label is. CAPTCHA is one applicable use case but there can be others: (1)
Use a grid-based challenge where a grid with embedded symbols is displayed as
an image and the user responds with the appropriate sequence of symbols
corresponding to a secret pattern registered with the issuer; (2) Show a
choice of images to a user to select the one that has been previously
established as the shared secret image; (3) any other creative means by
which images can be used to challenge the user to interact in a certain way. Hal From: Marc Goodner [mailto:mgoodner@microsoft.com]
Issue 153 From: Marc Goodner
[mailto:mgoodner@microsoft.com] 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: TrustArtifact: 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:
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>
<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>
<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>
<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]