[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 157: Generalized Interactive Challenge for WS-Trust
This is the right idea,
but the wording seems awkward and indirect. How about: In some situations, some
additional authentication step may be required, but the Consumer cannot
determine this in advance of making the request. Two common cases, that require
user interaction are: •
a challenge for a secret PIN, •
a challenge for a one-time-password (OTP). Hal From: Marc Goodner [mailto:mgoodner@microsoft.com] Not trying to fork the
thread so changing title. This is only the proposal for 157. Hal responded to
the proposals below here: http://lists.oasis-open.org/archives/ws-sx/200803/msg00002.html
So, I think we should
just add a new sentence at the beginning of 8.3.2: There are common challenges where a second
authentication factor may be required that cannot always be known a priori. 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). From: Marc Goodner [mailto:mgoodner@microsoft.com] We discussed calling out on the call last week that this was
just a display difference. I thought I knew what I should do for 157, but
I’m not really sure now. I think we can probably talk through that on the
call today. Proposals for the others below. 156 158 159 From: Using
a new color to make it easy to find my comments. From: Marc Goodner [mailto:mgoodner@microsoft.com] These were recorded as
issues 155 to 159. I’ve responded in line to each one below. From: 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. Well I think there is
value to directly supporting Authentication methods which require an
additional message exchange without requiring the use of an STS and the
issuance of another Token. SOAP is not an application protocol and WS-Security
supports SOAP. I think in a layered design, the Security element gets processed
before the message is ever seen by the app. If the two parties support some kind
of challenge resp AuthN protocol they should be able to generate messages for
the handshake. This is essentially the same scheme used for HTTP AuthN and I
have never heard anyone complain that it makes HTTP security too hard to
implement. In any event, since we
are not working on WS-Security at this time. I am satisfied that the message
exchange defined could be dropped into a different protocol at a further date
and I am willing to postpone this argument until then. [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. Well that fact that
this stuff was not previously defined does not mean it is not an error. I would
like to see some additional text describing the scheme you propose. It could be
required or simply suggested as an example implementation. It seems to me that
this needs to be defined for true interoperability anyway (the kind that works
even if there are errors, so why not specify at least one way that works? [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. What
I was really trying to get at was the motivating usecase. If the PIN is just a
password, why not treat it like a password? If there are two passwords, why not
one longer password or two passwords in the same messge? [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. Ok,
fine. I just missed this one. 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. Well
there is a general tendency to pass text thru some kind of generalized html
parser which may support various kinds of scripting and other non-display
functionality. Hackers have frequently found ways to exploit such sloppy
coding. I would like text added to say that non-printable characters MUST be
ignored, HTML tags MUST be ignored, etc. [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. This
answers my question. I don’t think it would hurt to add these examples to
the spec. (Unless someone is planning to write an implementers guide real
soon.) 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: 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>
<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]