Validate — The validity of the specified security token is evaluated and a result is returned. The result MAY be a status, a new token, or both. It should be noted that for this binding, a SOAP Envelope MAY be specified as a "security token" if the requestor desires the envelope to be validated.
For some use cases a status token is returned indicating the success or failure of the validation. In other cases a security token MAY be returned and used for authorization. This binding assumes that the validation requestor and provider are known to each other and that the general issuance parameters beyond requesting a token type, which is OPTIONAL, are not needed note that other bindings and profiles could define different semantics.
For this binding an applicability scope e. It is assumed that the applicability of the validation response relates to the provided information e. The validation binding does not allow the use of exchanges. The RSTR for this binding carries the following element even if a token is returned note that the base elements described above are included here italicized for completeness :.
When a validation request is made, this element MUST be in the response. The code value indicates the results of the validation in a machine-readable form. The accompanying text element allows for human textual display. The Trust service successfully validated the input. The Trust service did not successfully validate the input. The following illustrates the syntax of a validation request and response. In this example no token is requested, just a status. In this example a custom token is requested indicating authorized rights in addition to the status.
The general security token service framework defined above allows for a simple request and response for security tokens possibly asynchronous. This section describes the extensions to the base WS-Trust mechanisms to enable exchanges for negotiation and challenges. There are potentially different forms of exchanges, but one specific form, called "challenges", provides mechanisms in addition to those described in [ WS-Security ] for authentication.
This section describes how general exchanges are issued and responded to within this framework. Other types of exchanges include, but are not limited to, negotiation, tunneling of hardware-based processing, and tunneling of legacy protocols. The process is straightforward illustrated here using a challenge :.
It should be noted that the requestor might challenge the recipient in either step 1 or step 3. In which case, step 2 or step 4 contains an answer to the initiator's challenge. Similarly, it is possible that steps 2 and 3 could iterate multiple times before the process completes step 4. The two services can use [ WS-SecurityPolicy ] to state their requirements and preferences for security tokens and encryption and signing algorithms general policy intersection.
This section defines mechanisms for legacy and more sophisticated types of negotiations. The general mechanisms defined for requesting and returning security tokens are extensible.
This section describes the general model for extending these to support negotiations and challenges. The exchange model is as follows:. Other types of challenges MAY also be included. Multiple challenges and responses MAY be included. Exchange requests are issued by including an element that describes the exchange e.
Some forms of negotiation MAY specify challenges along with responses to challenges from the other party. It should be noted that the requestor MAY provide exchange information e. The syntax of these elements is as follows:.
The following describes the attributes and tags listed in the schema above:. For example, the challenge SHOULD track such as using a digest of any relevant data exchanged such as policies, tokens, replay protection, etc. Furthermore, the recipient of a challenge SHOULD verify that the data tracked digested matches their view of the data exchanged. The exact algorithm MAY be defined in profiles or agreed to by the parties.
This is an extensibility mechanism to allow additional negotiation types to be used. This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element. If a challenge was issued, the response MUST contain the challenge element exactly as received.
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. In the absence of a lower level protocol guaranteeing delivery of every message in order and exactly once, which retains the ordering of requests and responses traveling in opposite directions, implementations SHOULD observe the following procedures:.
Never send a new request while an existing request is pending,. Timeout requests and retransmit them. Silently discard responses when no request is pending.
Respond to a repeated request with the same information. Retain user input until the Challenge Interation is complete in case it is necessary to repeat the response.
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 ].
The following describes the attributes and elements listed in the schema outlined above:. How the preferred language of the requestor is communicated to the STS is left up to implementations. 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. This value serves as a hint for the user interface software at the requestor which manifests the end-user experience for this challenge.
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. 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. The element may contain any value. The actual content is opaque to the requestor; it is not required to understand its structure or semantics.
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. This is an extensibility mechanism to allow additional elements to be specified.
This is an extensibility mechanism to allow additional attributes to be specified. A container element for the response to a challenge that requires interactive user input. This element value contains the user input as the response to the original text challenge issued. A required attribute that specifies the identifier for the text challenge element in the original challenge which can be used for correlation.
A required attribute that specifies the reference identifier for the choice challenge element in the original challenge which can be used for correlation. A required element that specifies a choice item selected by the user from the choice challenge.
A required attribute that specifies the reference identifier for the choice item in the original choice challenge which can be used for correlation. An optional element that carries a context data item from the original challenge that is simply reflected back. A required attribute that specifies the reference identifier for the context data element in the original challenge which can be used for correlation.
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. Service consumers MUST insure that image data does not contain imbedded commands or other content before displaying the image. 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:. 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. In such cases, the optimized response pattern may not be usable. A generic mechanism is provided for this that includes a URI attribute to indicate the type of binary exchange.
The syntax of this element is as follows:. The following describes the attributes and tags listed in the schema above note that the ellipses below indicate that this element MAY be placed in different containers. The contents of this element are blob-type-specific and are encoded using base64 unless otherwise specified. A common approach is to use the negotiated key as a "secure channel" mechanism to secure the new token and proof-of-possession token. For example, an exchange might establish a shared secret Sx that can then be used to sign the final response and encrypt the proof-of-possession token.
In some cases it MAY be necessary to provide a key exchange token so that the other party either requestor or issuer can provide entropy or key material as part of the exchange.
The syntax of these elements is as follows Note that the ellipses below indicate that this element MAY be placed in different containers. The contents of this element either contain the security token to be used for key exchange or a reference to it.
That is, a specific exchange mechanism MAY use multiple elements at different times, depending on the state of the exchange. Here is an example exchange involving a signature challenge. In this example, a service requests a custom token using a X.
The issuer uses the exchange mechanism to challenge the requestor to sign a random value to ensure message freshness. The requestor provides a signature of the requested data and, once validated, the issuer then issues the requested token. The first message illustrates the initial request that is signed with the private key associated with the requestor's X.
The issuer recipient service doesn't trust the sender's timestamp or one wasn't specified and issues a challenge using the exchange framework defined in this specification. This message is signed using the private key associated with the issuer's X. The requestor receives the issuer's challenge and issues a response that is signed using the requestor's X. The signature only covers the non-mutable elements of the message to prevent certain types of security attacks:.
The issuer validates the requestor's signature responding to the challenge and issues the requested token s and the associated proof-of-possession token. The proof-of-possession token is encrypted for the requestor using the requestor's public key. Here is an example of a user interaction challenge using both text and choice challenges.
The STS uses the challenge mechanism to challenge the user for additional information in the form of a secret question i. 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 STS issues a challenge for additional information using the user interaction challenge mechanism as follows. Please answer the following additional questions to login. 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. The STS validates the response containing the inputs from the user, and issues the requested token as follows.
Here is an example of a user interaction challenge using a text challenge for a secret PIN. 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.
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.
The STS validates the authentication credential as well as the optimized PIN response, and issues the requested token as follows. Here is another illustrating the syntax for a token request using a custom XML exchange. Note that the framework allows for an arbitrary number of exchanges, although this example illustrates the use of four legs.
The request uses a custom exchange element and the requestor signs only the non-mutable element of the message:. The issuer service recipient responds with another leg of the custom exchange and signs the response non-mutable aspects with its token:. The requestor receives the issuer's exchange and issues a response that is signed using the requestor's token and continues the custom exchange. The signature covers all non-mutable aspects of the message to prevent certain types of security attacks:.
The issuer processes the exchange and determines that the exchange is complete and that a token should be issued. Consequently it issues the requested token s and the associated proof-of-possession token.
It should be noted that other example exchanges include the issuer returning a final custom exchange element, and another example where a token isn't returned. There are some attacks, such as forms of man-in-the-middle, that can be applied to token requests involving exchanges. After an exchange both parties have a shared knowledge of a key or keys that can then be used to secure messages. However, in some cases it may be desired to have the issuer prove to the requestor that it knows the key and that the returned metadata is valid prior to the requestor using the data.
However, until the exchange is actually completed it MAY be and is often inappropriate to use the computed keys. As well, using a token that hasn't been returned to secure a message may complicate processing since it crosses the boundary of the exchange and the underlying message security. This means that it MAY NOT be appropriate to sign the final leg of the exchange using the key derived from the exchange. For this reason an authenticator is defined that provides a way for the issuer to verify the hash as part of the token issuance.
The following describes the attributes and elements listed in the schema overview above the This section outlines additional parameters that can be specified in token requests and responses. Typically they are used with issuance requests, but since all types of requests MAY issue security tokens they could apply to other bindings.
In some scenarios the requestor is obtaining a token on behalf of another party. These parameters specify the issuer and original requestor of the token being used as the basis of the request. The syntax is as follows note that the base elements described above are included here italicized for completeness :.
This element's type is an endpoint reference as defined in [ WS-Addressing ]. In the following illustrates the syntax for a proxy that is requesting a security token on behalf of another requestor or end-user.
In some cases the service may support a variety of key types, sizes, and algorithms. These parameters allow a requestor to indicate its desired values. It should be noted that the issuer's policy indicates if input values must be adhered to and faults generated for invalid inputs, or if the issuer will provide alterative values in the response. This specification does not predefine classifications; these are specific to token services as is the relative strength evaluations.
The relative assessment of strength is up to the recipient to determine. For example, this might be used to indicate which of the four U. The predefined values are identified in the table below.
Note that some security token formats have fixed key types. It should be noted that new algorithms can be inserted by defining URIs in other specifications and profiles. A public key token is requested. A symmetric key token is requested default. A bearer token is requested. This key type can be used by requestors to indicate that they want a security token to be issued that does not require proof of possession. This is a request, and, as such, the requested security token is not obligated to use the requested key size.
The information is provided as an indication of the desired strength of the security. That is, so that the owner of the specified token can decrypt the secret. Normally the security token is the contents of this element but a security token reference MAY be used instead.
If this element isn't specified, the token used as the basis of the request or specialized knowledge is used to determine how to encrypt the key. If the requestor wishes to use an existing key rather than create a new one, then this OPTIONAL element can be used to reference the security token containing the desired key.
Otherwise this parameter is meaningless and is ignored. When this attribute is present, a key need not be specified inside the element since the referenced signature will indicate the corresponding token and key.
The following summarizes the various algorithm parameters defined above. T is the issued token, P is the proof key. SignatureAlgorithm - The signature algorithm to use to sign T. EncryptionAlgorithm - The encryption algorithm to use to encrypt T. But each party must know that the other party is trustworthy, and the asserted credentials are put to the right end.
The two parties can be different operating systems, domains or technologies placed at the two ends of a communication channel. Web Services Trust Language allows multiple security tokens to be combined, and it can even supplement already existing security technologies and methods to devise a security service. By: Justin Stoltzfus Contributor, Reviewer.
By: Satish Balakrishnan. Dictionary Dictionary Term of the Day. Natural Language Processing. WSS uses the UsernameToken method to bind an issued security token to a particular user.
Each WS enabled SOAP endpoint should have a list of supported encryption methods, keys that may be issued, and authorized users. This can be achieved using a PL Stored Procedure hook. The client has to have a way to know what policy to apply.
This can be a UDT that is initialized appropriately and passed to the client routines. The WS-Trust standard specifies that Security Token Service STS can be used by both web service clients and providers to perform operations on standard security tokens.
On the web service client side, which can be a web application or rich desktop application, the STS converts whatever security token that is used locally into a standard SAML security token containing the user's identity, which is shared with the web services provider.
0コメント