WS-Trust1.4-第三章

安全令牌服务框架

本节定义用于令牌颁发安全令牌服务的总体框架。

请求者发送一个请求，如果策略允许和收件人的要求得到满足，然后请求者收到安全令牌响应。此过程使用的<wst:RequestSecurityToken> 和<wst:RequestSecurityTokenResponse>标签。这些标签是通过特定的WSDL端点（第1.4节中描述），是由安全令牌服务实施的有效负载。 

这个框架没有定义具体行动，每个绑定使用各自的行动。

当请求和返回的安全性令牌的附加参数，可列入请求，或在答复中提供的表示服务器（或使用）值确定。如果一个请求指定一个特定的值是由收件人不支持，则收件人可能与WST故障：InvalidRequest（或更具体的故障代码），或者他们可能与他们所选择的参数返回一个记号，然后请求者可以选择放弃，因为它没有满足他们的需求。
 
请求和返回的安全令牌可用于多种用途。绑定定义如何使用这个框架是针对特定的使用模式。其他规格可以定义特定的绑定，这为其他目的的机制和型材。
在一般情况下，建议进行身份验证的请求的来源;然而，在某些情况下，一个匿名的请求，可适当。请求者可以匿名请求，它是由收件人的政策，以确定是否这样的要求是可以接受的。如果不是一个应该产生故障（但不是必需的拒绝服务的理由返回）。
 
[WS - Security的规范定义，并说明在XML Schema中定义的DateTime类型的时间参考。建议所有的时间参考，使用这种类型的。委员会还建议，所有引用UTC时间。不应该依赖于其他应用程序，支持比毫秒的时间分辨率更精细的请求者和接收器。实现必须不会产生指定闰秒的时刻。此外，任何所需的时钟同步是本文档??的范围之外。
 
以下各节描述的基本结构令牌的请求和响应识别的一般机制，最常见的子元素的元素。特定绑定扩展绑定特定的子元素，这些元素。也就是说，第3.1和3.2应视为具体的绑定建立的模式或模板。

3.1 请求一个安全令牌

<wst:RequestSecurityToken>标签 (RST) 用来使用请求一个安全令牌（任何目的）。  This element SHOULD be signed by the requestor, using tokens contained/referenced in the request that are relevant to the request.  If using a signed request, the requestor MUST prove any required claims to the satisfaction of the security token service.

If a parameter is specified in a request that the recipient doesn't understand, the recipient SHOULD fault.

The syntax for this element is as follows:

    <wst:RequestSecurityToken Context="..." xmlns:wst="...">

        <wst:TokenType>...</wst:TokenType>

        <wst:RequestType>...</wst:RequestType>

        <wst:SecondaryParameters>...</wst:SecondaryParameters>

        ...

    </wst:RequestSecurityToken>

The following describes the attributes and elements listed in the schema overview above:

/wst:RequestSecurityToken

This is a request to have a security token issued.

/wst:RequestSecurityToken/@Context

This OPTIONAL URI specifies an identifier/context for this request.  All subsequent RSTR elements relating to this request MUST carry this attribute.  This, for example, allows the request and subsequent responses to be correlated.  Note that no ordering semantics are provided; that is left to the application/transport.

/wst:RequestSecurityToken/wst:TokenType

This OPTIONAL element describes the type of security token requested, specified as a URI.  That is, the type of token that will be returned in the <wst:RequestSecurityTokenResponse> message.  Token type URIs are typically defined in token profiles such as those in the OASIS WSS TC.

/wst:RequestSecurityToken/wst:RequestType

The mandatory RequestType element is used to indicate, using a URI, the class of function that is being requested.  The allowed values are defined by specific bindings and profiles of WS-Trust.  Frequently this URI corresponds to the [WS-Addressing] Action URI provided in the message header as described in the binding/profile; however, specific bindings can use the Action URI to provide more details on the semantic processing while this parameter specifies the general class of operation (e.g., token issuance).  This parameter is REQUIRED.

/wst:RequestSecurityToken/wst:SecondaryParameters

If specified, this OPTIONAL element contains zero or more valid RST parameters (except wst:SecondaryParameters) for which the requestor is not the originator.

The STS processes parameters that are direct children of the <wst:RequestSecurityToken> element.  If a parameter is not specified as a direct child, the STS MAY look for the parameter within the<wst:SecondaryParameters> element (if present).  The STS MAY filter secondary parameters if it doesn't trust them or feels they are inappropriate or introduce risk (or based on its own policy).

/wst:RequestSecurityToken/{any}

This is an extensibility mechanism to allow additional elements to be added.  This allows requestors to include any elements that the service can use to process the token request.  As well, this allows bindings to define binding-specific extensions.  If an element is found that is not understood, the recipient SHOULD fault.

/wst:RequestSecurityToken/@{any}

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added.  If an attribute is found that is not understood, the recipient SHOULD fault.

3.2 返回一个安全令牌

The <wst:RequestSecurityTokenResponse> element (RSTR) is used to return a security token or response to a security token request. The <wst:RequestSecurityTokenResponseCollection>element (RSTRC) MUST be used to return a security token or response to a security token request on the final response.

 

It should be noted that any type of parameter specified as input to a token request MAY be present on response in order to specify the exact parameters used by the issuer.  Specific bindings describe appropriate restrictions on the contents of the RST and RSTR elements.

In general, the returned token SHOULD be considered opaque to the requestor.  That is, the requestor SHOULD NOT be required to parse the returned token.  As a result, information that the requestor may desire, such as token lifetimes, SHOULD be returned in the response.  Specifically, any field that the requestor includes SHOULD be returned.  If an issuer doesn't want to repeat all input parameters, then, at a minimum, if the issuer chooses a value different from what was requested, the issuer SHOULD include the parameters that were changed.

If a parameter is specified in a response that the recipient doesn't understand, the recipient SHOULD fault.

In this specification the RSTR message is illustrated as being passed in the body of a message.  However, there are scenarios where the RSTR must be passed in conjunction with an existing application message.  In such cases the RSTR (or the RSTR collection) MAY be specified inside a header block.  The exact location is determined by layered specifications and profiles; however, the RSTR MAY be located in the<wsse:Security> header if the token is being used to secure the message (note that the RSTR SHOULD occur before any uses of the token).  The combination of which header block contains the RSTR and the value of the OPTIONAL @Context attribute indicate how the RSTR is processed.  It should be noted that multiple RSTR elements can be specified in the header blocks of a message.

It should be noted that there are cases where an RSTR is issued to a recipient who did not explicitly issue an RST (e.g. to propagate tokens).  In such cases, the RSTR MAY be passed in the body or in a header block.

The syntax for this element is as follows:

    <wst:RequestSecurityTokenResponse Context="..." xmlns:wst="...">

        <wst:TokenType>...</wst:TokenType>

        <wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>

        ...

    </wst:RequestSecurityTokenResponse>

The following describes the attributes and elements listed in the schema overview above:

/wst:RequestSecurityTokenResponse

This is the response to a security token request.

/wst:RequestSecurityTokenResponse/@Context

This OPTIONAL URI specifies the identifier from the original request.  That is, if a context URI is specified on a RST, then it MUST be echoed on the corresponding RSTRs.  For unsolicited RSTRs (RSTRs that aren't the result of an explicit RST), this represents a hint as to how the recipient is expected to use this token.  No values are pre-defined for this usage; this is for use by specifications that leverage the WS-Trust mechanisms.

/wst:RequestSecurityTokenResponse/wst:TokenType

This OPTIONAL element specifies the type of security token returned.

/wst:RequestSecurityTokenResponse/wst:RequestedSecurityToken

This OPTIONAL element is used to return the requested security token.  Normally the requested security token is the contents of this element but a security token reference MAY be used instead.   For example, if the requested security token is used in securing the message, then the security token is placed into the <wsse:Security> header (as described in [WS-Security]) and a<wsse:SecurityTokenReference> element is placed inside of the <wst:RequestedSecurityToken> element to reference the token in the <wsse:Security> header.  The response MAY contain a token reference where the token is located at a URI outside of the message.  In such cases the recipient is assumed to know how to fetch the token from the URI address or specified endpoint reference.  It should be noted that when the token is not returned as part of the message it cannot be secured, so a secure communication mechanism SHOULD be used to obtain the token.

/wst:RequestSecurityTokenResponse/{any}

This is an extensibility mechanism to allow additional elements to be added.  If an element is found that is not understood, the recipient SHOULD fault.

/wst:RequestSecurityTokenResponse/@{any}

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added.  If an attribute is found that is not understood, the recipient SHOULD fault.

3.3 二进制数据

It should be noted that in some cases elements include a key that is not encrypted.  Consequently, the <xenc:EncryptedData> cannot be used.  Instead, the <wst:BinarySecret> element can be used.  This SHOULD only be used when the message is otherwise protected (e.g. transport security is used or the containing element is encrypted).  This element contains a base64 encoded value that represents an arbitrary octet sequence of a secret (or key).  The general syntax of this element is as follows (note that the ellipses below represent the different containers in which this element MAY appear, for example, a <wst:Entropy>or <wst:RequestedProofToken> element):

.../wst:BinarySecret

This element contains a base64 encoded binary secret (or key).  This can be either a symmetric key, the private portion of an asymmetric key, or any data represented as binary octets.

.../wst:BinarySecret/@Type

This OPTIONAL attribute indicates the type of secret being encoded.  The pre-defined values are listed in the table below:

URI	Meaning
http://docs.oasis-open.org/ws-sx/ws-trust/200512/AsymmetricKey	The private portion of a public key token is returned – this URI assumes both parties agree on the format of the octets; other bindings and profiles MAY define additional URIs with specific formats
http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey	A symmetric key token is returned (default)
http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce	A raw nonce value (typically passed as entropy or key material)

.../wst:BinarySecret/@{any}

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added. If an attribute is found that is not understood, the recipient SHOULD fault.

3.4 组合

The sections below, as well as other documents, describe a set of bindings using the model framework described in the above sections.  Each binding describes the amount of extensibility and composition with other parts of WS-Trust that is permitted.  Additional profile documents MAY further restrict what can be specified in a usage of a binding.

转载于:https://my.oschina.net/abcijkxyz/blog/708523