[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: Generalized Interactive Challenge for WS-Trust
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred.
Title: Generalized Interactive Challenge for WS-Trust Protocol: Trust Artifact: spec Type: design
Description: The security token services (STS) framework defined by
WS-Trust allows for a simple request and response for security tokens as well
as an extension mechanism to enable exchanges for negotiation and challenges.
The WS-Trust specification defines a “signature challenge”
construct as a specific type of exchange that makes use of the above extension
mechanism for general exchanges. There are many scenarios where an STS may require further
interactions with the requestor prior to returning a security token, beyond the
authentication requirements expressed in its security policy and satisfied by
the security tokens bound to the initial RST request through SOAP security
header. Following are examples of exchanges where an STS may further challenge
the requestor for additional interactive input, to supplement authentication
information submitted in the original request in the SOAP security header,
before issuing the requested token. ·
Prompt the user for an additional shared secret
such as a PIN. ·
Prompt the user for second-factor authentication
data such as “one time password” (OTP) taken from an OTP device or
module. ·
Prompt the user for answers to text-based secret
questions (e.g., mother’s maiden name, date of birth) as either text
inputs or multiple-choice inputs. ·
Prompt the user for answers to image-based
challenges as either text inputs or multiple-choice inputs. The challenge may be selectively issued by the STS only for
particular users or for token requests for particular target scopes. The
specific user or target scope can only be identified after the initial request
is received. In all such cases, however, the supplemental authentication
information required by the STS does not cause a reset of the security policy
of the STS. Specifically, the additional information requested by the STS in
the form of challenge and response exchanges is carried entirely within the
RST/RSTR message bodies and does not affect the authentication information
carried inside the SOAP security headers in any way. The security token content
in the SOAP security headers remains unchanged across the user interaction
challenge/response exchanges. This proposal defines a “user interaction
challenge” construct, as a strongly typed mechanism, for issuing
interactive challenges and receiving corresponding responses within the
WS-Trust framework inside the bodies of RST/RSTR messages. The proposed
mechanism easily fits into the general exchanges mechanism already defined in
WS-Trust. Proposal: Add the following section to section 8, Negotiation and Challenge
Extensions after section 8.2. Existing sections 8.3 through 8.6 increment
accordingly. To be consistent with the existing section the examples for
interactive challenges should be added as section 8.8 after the existing
section 8.6 (renumbered to 8.7) on signature challenge examples. Remaining
existing sections 8.7 through 8.9 increment accordingly. Also, add a new property to SecurityPolicy 1.3 in the Trust
1.3 assertion and a new nested assertion to control the setting of that
property. All new elements, attributes, URIs are to be defined under
the Trust 1.4 namespace, represented here with the wst14 namespace prefix and
the placeholder URI http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm.
New assertions for SecurityPolicy 1.3 are defined under sp13 namespace prefix
and the placeholder URI http://docs.oasis-open.org/ws-sx/ws-securitypolicy/yyyymm. WS-SecurityPolicy change for Trust 1.3 assertion [Interactive Challenge] This boolean property indicates whether interactive
challenges are supported. A value of 'true' indicates that a
wst14:InteractiveChallenge element is supported inside of an RSTR sent by the
server to the client. A value of 'false' indicates that
wst14:InteractiveChallenge is not supported. A challenge issued by the server
may increase the number of messages exchanged by the client and service in
order to accommodate the wst14:InteractiveChallengeResponse element sent by the
client to the server in response to the wst14:InteractiveChallenge element.
There is an optimization in which a client MAY send the
wst14:InteractiveChallengeResponse element in an initial RST to the server. A
final RSTR containing the issued token will follow subsequent to the server
receiving the wst14:InteractiveChallengeResponse element. This property has a
default value of 'false'. /sp:Trust13/wsp:Policy/sp13:MustSupportInteractiveChallenge This optional element is a policy assertion indicates that
the [Interactive
Challenge] property is set to 'true'. 8.3 User Interaction
Challenge
User interaction challenge requests are issued by including
the <InteractiveChallenge>
element. The response is returned in a <InteractiveChallengeResponse>
element. Both the challenge and response elements are specified within the <wst:RequestSecurityTokenResponse> element. In
some instances, the requestor may issue a challenge to the recipient or provide
a response to an anticipated challenge from the recipient in the initial
request. Consequently, these elements are also allowed within a <wst:RequestSecurityToken> element. The
challenge/response exchange between client and server MAY be iterated over
multiple legs before a final response is issued. Note that the xml:lang
attribute may be used where allowed via attribute extensibility to specify a
language of localized elements and attributes using the language codes
specified in [RFC 3066]. 8.3.1 Challenge Format
The syntax of the user interaction challenge element is as follows: <wst14:InteractiveChallenge
xmlns:wst14="..." ...> <wst14:Title ...> xs:string
</wst14:Title> ? <wst14:TextChallenge
RefId="xs:anyURI" Label="xs:string"?
MaxLen="xs:int"? HideText="xs:boolean"?
...> <wst14:Image
MimeType="xs:string"> xs:base64Binary
</wst14:Image> ?
</wst14:TextChallenge> * <wst14:ChoiceChallenge
RefId="xs:anyURI" Label="xs:string"?
ExactlyOne="xs:boolean"? ...>
<wst14:Choice RefId="xs:anyURI" Label="xs:string"?
...>
<wst14:Image MimeType="xs:string">
xs:base64Binary </wst14:Image> ?
</wst14:Choice> +
</wst14:ChoiceChallenge> * < wst14:ContextData
RefId="xs:anyURI"> xs:any </wst14:ContextData>
* ... </wst14:InteractiveChallenge> The following describes the attributes and elements listed
in the schema outlined above: .../wst14:InteractiveChallenge A
container element for a challenge that requires interactive user input. .../wst14:InteractiveChallenge/wst14:Title An
optional element that specifies an overall title text to be displayed to the
user (e.g. a title describing the purpose or nature of the challenge). How the
preferred language of the requestor is communicated to the STS is left up to
implementations. .../wst14:InteractiveChallenge/wst14:TextChallenge An optional
element that specifies a challenge that requires textual input from the user. .../wst14:InteractiveChallenge/wst14:TextChallenge/@RefId A required
attribute that specifies a reference identifier for this challenge element
which is used to correlate the corresponding element in the response to the
challenge. .../wst14:InteractiveChallenge/wst14:TextChallenge/@MaxLen An
optional attribute that specifies the maximum length of the text string that is
sent as the response to this text challenge. This value serves as a hint for
the user interface software at the requestor which manifests the end-user
experience for this challenge. .../wst14:InteractiveChallenge/wst14:TextChallenge/@HideText An
optional attribute that specifies that the response to this text challenge MUST
receive treatment as hidden text in any user interface. For example, the text
entry may be displayed as a series of asterisks in the user interface. This
attribute serves as a hint for the user interface software at the requestor
which manifests the end-user experience for this challenge. .../wst14:InteractiveChallenge/wst14:TextChallenge/@Label An
optional attribute that specifies a label for the text challenge item (e.g. a label
for a text entry field) which will be shown to the user. How the preferred
language of the requestor is communicated to the STS is left up to
implementations. .../wst14:InteractiveChallenge/wst14:TextChallenge/Image An
optional element that contains a base64 encoded inline image specific to the
text challenge item to be shown to the user (e.g. an image that the user must
see to respond successfully to the challenge). .../wst14:InteractiveChallenge/wst14:TextChallenge/Image/@MimeType A required
attribute that specifies a MIME type (e.g., image/gif, image/jpg) indicating
the format of the image. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge An
optional element that specifies a challenge that requires a choice among
multiple items by the user. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@RefId A required
attribute that specifies a reference identifier for this challenge element
which is used to correlate the corresponding element in the response to the
challenge. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@Label An
optional attribute that specifies a title label for the choice challenge item
(e.g., a text header describing the list of choices as a whole) which will be
shown to the user. How the preferred language of the requestor is communicated
to the STS is left up to implementations. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@ExactlyOne An
optional attribute that specifies if exactly once choice must be selected by
the user from among the child element choices. The absence of this attribute
implies the value “false” which means multiple choices can be
selected. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice A required
element that specifies a single choice item within the choice challenge. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@RefId A required
attribute that specifies a reference identifier for this specific choice item
which is used to correlate the corresponding element in the response to the
challenge. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@Label An
optional attribute that specifies a text label for the choice item (e.g., text
describing the individual choice) which will be shown to the user. How the preferred
language of the requestor is communicated to the STS is left up to
implementations. .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image An
optional element that contains a base64 encoded inline image specific to the
choice item to be shown to the user (e.g. an image that the user must see to
respond successfully to the challenge). .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image/@MimeType A required
attribute that specifies a MIME type (e.g., image/gif, image/jpg) indicating
the format of the image. .../wst14:InteractiveChallenge/wst14:ContextData An
optional element that specifies a value that MUST be reflected back in the
response to the challenge (e.g., cookie). The element may contain any value.
The actual content is opaque to the requestor; it is not required to understand
its structure or semantics. This can be used by an STS, for instance, to store
information between the challenge/response exchanges that would otherwise be
lost if the STS were to remain stateless. .../wst14:InteractiveChallenge/wst14:ContextData/@RefId A required
attribute that specifies a reference identifier for this context element which
is used to correlate the corresponding element in the response to the
challenge. .../wst14:InteractiveChallenge/{any} This is an
extensibility mechanism to allow additional elements to be specified. .../wst14:InteractiveChallenge/@{any} This is an
extensibility mechanism to allow additional attributes to be specified. The syntax of the user interaction challenge response element is as
follows: <wst14:InteractiveChallengeResponse
xmlns:wst14="..." ...>
<wst14:TextChallengeResponse RefId="xs:anyURI" ...> xs:string </wst14:TextChallengeResponse>
* <wst14:ChoiceChallengeResponse
RefId="xs:anyURI"> *
<wst14:ChoiceSelected RefId="xs:anyURI" /> *
</wst14:ChoiceChallengeResponse> <wst14:ContextData
RefId="xs:anyURI"> xs:any </wst14:ContextData>
* ... </wst14:InteractiveChallengeResponse> The following describes the attributes and elements listed
in the schema outlined above: .../wst14:InteractiveChallengeResponse A
container element for the response to a challenge that requires interactive
user input. .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse This
element value contains the user input as the response to the original text
challenge issued. .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse/@RefId A required
attribute that specifies the identifier for the text challenge element in the
original challenge which can be used for correlation. .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse A
container element for the response to a choice challenge. .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/@RefId A required
attribute that specifies the reference identifier for the choice challenge
element in the original challenge which can be used for correlation. .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected A required
element that specifies a choice item selected by the user from the choice
challenge. .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected/@RefId A required
attribute that specifies the reference identifier for the choice item in the
original choice challenge which can be used for correlation. .../wst14:InteractiveChallengeResponse/wst14:ContextData An
optional element that carries a context data item from the original challenge
that is simply reflected back. .../wst14:InteractiveChallengeResponse/wst14:ContextData/@RefId A required
attribute that specifies the reference identifier for the context data element
in the original challenge which can be used for correlation. .../wst14:InteractiveChallengeResponse/{any} This is an
extensibility mechanism to allow additional elements to be specified. .../wst14:InteractiveChallengeResponse/@{any} This is an
extensibility mechanism to allow additional attributes to be specified. In order to prevent certain types of attacks,
such as man-in-the-middle or replay of response, the challenge SHOULD be bound
to the response. For example, an STS may use the <ContextData>
element in the challenge to include a digest of any relevant replay protection
data and verify that the same data is reflected back by the requestor. 8.3.2 PIN and OTP Challenges
Two commonly used challenges, usually as forms of second authentication
factors, that require user interaction are:
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]