[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
For proposal 157.
Wouldn't a personal X.509 certificate also be one of the
possible challenges for two factor authentication? You certainly would
have to treat it differently than just another password.
Paul Lesov,
CISSP From: Hal Lockhart [mailto:hlockhar@bea.com] Sent: Wednesday, March 05, 2008 8:54 AM To: Marc Goodner; ws-sx@lists.oasis-open.org 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]