文档章节

WS-Trust1.4-第三章

abcijkxyz
 abcijkxyz
发布于 2016/07/08 16:29
字数 2196
阅读 2
收藏 0

安全令牌服务框架

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

请求者发送一个请求,如果策略允许和收件人的要求得到满足,然后请求者收到安全令牌响应。此过程使用的<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.

本文转载自:http://blog.csdn.net/yuwenruli/article/details/6679807

共有 人打赏支持
abcijkxyz
粉丝 63
博文 6196
码字总数 1876
作品 0
深圳
项目经理
ActiveMQ中文指南

ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用...

harries
2016/03/17
130
2
基于SOA 思想下的WebService实战资料分享

跟大家分享基于SOA 思想下的WebService实战(电子商务需求,分析,架构全涉及,百万数据优化) 课程讲解内容涵盖: 第1章 CXF框架快速起步(2课时) Webservice技术规则 Java-WebService技术规范...

abcfhl
2013/06/24
1K
7
JAVA区块链项目实战视频课程

课程介绍 全国首套,基于java的区块链实战教程。目的是让更多的java编程者了解区块链,掌握区块链开发。 1、区块链理论:以node.js例子区块链原理有深刻理解; 2、区块链java实战:深刻理解区...

小红牛
09/14
0
0
ATL7窗口类剖析

目录: ATL7窗口类剖析... 1 目录:... 1 前言:... 1 第一章 HWND和CWindow类... 1 Create成员函数:... 2 使用CWindow类... 3 第二章 CWindowImpl类... 4 ProcessWindowMessage与消息映射宏...

长平狐
2012/08/28
392
0
WCF技术剖析之二十六:如何导出WCF服务的元数据(Metadata)[扩展篇]

通过《实现篇》对WSDL元素和终结点三要素的之间的匹配关系的介绍,我们知道了WSDL的Binding元素来源于终结点的绑定对象,那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢...

长平狐
2012/09/04
55
0

没有更多内容

加载失败,请刷新页面

加载更多

SQL count(*) 和count(1)的区别

开发中经常会使用这两个聚合函数,作用都是用来统计记录行,今天查找资料发现,其实这两个函数并没有区别, 实践才是检验的标准,首先看执行计划(表是我自己建立的): 可以看到,两个执行计...

一曲图森破
3分钟前
0
0
ppwjs之bootstrap文字排版:字体设置

<!DOCTYPT html><html><head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><title>ppwjs欢迎您</title><link rel="icon" href="/favicon.ico" ......

ppwjs
5分钟前
0
0
区块链100讲:详解区块链之P2P网络

1 P2P网络 如果我们简单来看 P2P 技术,它的应用领域已经非常广泛了,从流媒体到点对点通讯、从文件共享到协同处理,多种领域都有它的身影出现。 同样的,P2P 的网络协议也有很多,比较常见的...

HiBlock
20分钟前
0
0
74.expect脚本同步文件以及指定host同步文件 构建分发系统文件和命令

20.31 expect脚本同步文件: 在expect脚本中去实现在一台机器上把文件同步到另外一台机器上去。核心命令用的是rsync ~1.自动同步文件 #!/usr/bin/expect set passwd "123456" spawn rsync -a...

王鑫linux
45分钟前
0
0
TypeScript项目引用(project references)

转发 TypeScript项目引用(project references) TypeScript新特性之项目引用(project references) 项目引用是TypeScript 3.0中的一项新功能,允许您将TypeScript程序构建为更小的部分。 通过这...

durban
49分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部