域间服务融合授权控制框架

本文提出了一种允许在不同管理域间进行服务融合（service composition）的控制模式。使得基于本地授权规则的授权决策或者是来自外部域授权凭证的授权决策成为可能。

随着互联网上的服务请求越来越成为一种普遍的活动，服务提供商必须在充满竞争的环境中不断提供各种新的增值服务以吸引用户。然而，要求服务提供商能够构建起每一种可能的服务显然是不切实际的。服务融合（service composition）就是在这种需求下产生的，通过服务融合，互联网上的各种服务组件就可以在需要的时候动态地进行组合。

随着服务融合的提出，那么如何对这种在不同服务组件间融合的授权进行控制就成了一个必须解决的问题。这种授权控制要求既能服务于各式各样的服务组件，还要求能够处理不同管理域之间服务的相互请求。但是，当前的各种授权框架无法满足这种要求。通常，这些授权框架是针对某一种或某几种特定服务而提出的，比如DIAMETER专门用于网络接入控制。而其他的一些授权控制却只限定在某个特定的服务范围中（管理域），如微软的.Net Passport，对管理范围以外的服务就不能支持；而Kerberos虽然支持在不同域之间的接入控制，但是在处理服务用户来自其他域的凭证时会附加一些工作。

所谓服务融合，字面理解就是允许开发人员使用来自不同环境的服务融合成为应用程序、流程或者其他更加复杂的服务，而不需要考虑这些环境的细节和差异。

为了解决这些问题，就要求提出一种授权控制框架，它必须有如下两种特点：一、这是一种相对通行的授权控制协议，要求能够运用在各种不同的服务之上；二、这种授权控制方案要求能够提供凭证转换功能（这里的凭证转换功能主要是针对在不同管理域间进行服务融合的情况）。对于第一种情况，本文在基于XML/SOAP技术的基础上给出了能够满足这种需求的授权控制框架。而第二种情况，在授权控制方案中利用联盟管理域形成相互对称的凭证转换规则，当然这些凭证在不同域间要求是相互信任和认可的。授权服务器首先利用转换规则来转换本地的授权规则，然后再给来自外部的服务请求进行授权。在本文中，笔者设计了这样一个授权控制方案：凭证转换规则设计成一个XSLT文档，然后再利用这个规则对基于XML的授权规则进行转换。

服务融合模型

图1给出了一个服务融合的例子：一个针对移动网络的内容流系统。该系统根据用户的特征信息（比如：年龄、喜好、位置等）通过门户（Portal）为用户提供各种合适的内容。在收到用户请求后，门户启动一个后台服务组件，例如用户信息服务器或者内容服务器； 然后，内容服务器接着启动其他的后台组件，示例中是一个内容适应服务（比如：格式转换、内容保护等等）和 QoS管理服务。 而内容服务器、内容适应服务又分别位于各自不同的管理域Domain 1、Domain 2 和Domain3中

每个管理域中的认证授权(CA)通过一个认证码与密钥对进行用户和服务组件进行确认。 这个认证码与密钥形成的对主要是用来用户认证和请求签名的。具体的认证格式，这里我们使用已有的标准，例如X.509。授权控制服务器通过认证码给服务请求者认证(用户或服务组件)。在该系统，认证码包含有与请求者相关的信息，例如会员资格(金卡会员、银卡会员)，等级信息(正式站点、非官方的站点)，以及角色。这些信息都通过XML格式的文档进行描述。授权控制服务器同时还给服务组件提供具体的授权决定方法。而服务器根据管理域和服务提供商指定的认证规则，同时再利用由服务组件提供的认证码和用户信息来做出授权决定。 虽然有其他类型的认证，比如包含有接入服务信息的认证，这里并没有采用。

授权控制过程

服务组件首先收到服务请求，然后会唤起已存在与授权服务器中的一个授权决定方法。这一过程是通过一个基于SOAP/XML的通用授权控制协议完成的。下面给出了一个请求认证的SOAP消息示例。

Post /AuthorizationDecision HTTP/1.1

Host: www.省略

Content-Type: text/xml; charset="UTF-8"

Content-Length: nnnn

SOAPACTION: "/AuthorizationDecision"

< SOAPENV:Envelope xmlns:SOAPENV="schemas.省略/soap/envelope/"

SOAPENV:encodingStyle="schemas.省略/soap/encoding/">

< SOAPENV:Header>

< !--Header entries go here -->

< /SOAPENV:Header>

< SOAPENV:Body>

< message:AuthorizationDecision xmlns:message="AuthorizationServerInterface">

< message:Service> … < / message:Service>

< message:Certificate> … < / message:Certificate>

< message:Credential> … < / message:Credential>

< message:Profile> … < / message:Profile>

< message:Condition> … < / message:Condition>

< / message:AuthorizationDecision>

< /SOAPENV:Body>

< /SOAPENV:Envelope>

SOAP请求和相应通过HTTPS协议在服务组件和授权服务器之间进行传输。之所以选择HTTPS是因为，它提供了较好的安全性，可以防止恶意伪造信息或者窃听等。并且，服务组件和授权服务器可以使用由认证授权的密匙对SOAP消息进行签名。上面实例所示的请求消息包含有如下用于授权决策的参数:指定的服务、认证码、凭证、用户信息以及使用条件等。 这里的“服务”参数包含了服务请求者所要求的具体方法，而“认证码”信息中则带有由服务请求者发出的认证信息，“凭证”参数包含服务请求者发送的一个凭证集（credential set），“用户信息”包含了从用户信息服务器所获得有关该用户的相关信息，最后“使用条件”部分给出了诸如服务器负载等一系列使用条件信息。

当授权服务器收到授权决定请求时，首先会提取出SOAP信息中所包含的各种参数，并且对认证码，凭证、用户信息和使用条件通过核实签名进行确认。如果授权服务器没有使用公共密钥进行确认核查，它会从签名信息指定的地址中获取认证码。 如果成功确认，授权服务器将它们输入到授权决定方法中，并返回带有认证结果的SOAP响应信息。

使用凭证转换的授权控制

在图1中，服务请求者(比如在domain1中的Portal门户)发送一个请求到另一个管理域中的一个服务组件(如domain2中的内容服务器)，它会附加上本地的认证码。这就要求在domain2中的授权服务器需要给domain1中的认证码做出一个授权决定。一种可能的解决方案就是为每一个可能要求该管理域中某个服务组件提供服务的其他管理域都预先准备足够多的授权规则。但是，这就要求服务提供商和提供服务的管理域承担起这种责任（准备规则的责任），这显然会带来很多问题，比如安全问题、规则缺失问题。这种方法显然是不可取的。第二种可能的方法是，基于凭证转换的授权控制方案。所谓基于凭证转换的授权控制方案有点像国家与国家间身份证件相互认可制度，这种方案相比较第一种方案而言应该有较多的优势，也应该是更好的选择。下面详细讨论这种方案的实现手段和相对优势。

基于凭证转换的认证方案中，首先会在不同的管理域建立一个联盟，在这个联盟类的管理域之间是相互信任的，他们之间形成一种相互认可的规则双向转换机制。例如，授权服务器在收到带有管理域之外的认证码请求时，会首先进行凭证规则转换,然后再结合授权规则和凭证做出授权决定。而凭证的转换又可以考虑如下两种方式：直接对凭证运用转换规则和对授权规则运用转换规则。在这里我们选用后者，因为对授权规则运用转换规则的方法能够更方便地支持条件转换。例如，如果要求一个用户在做出一个附加的支付操作后，domain 1中的“金牌”凭证就能够转换为“VIP”认证。那么此时，这种转换通过修改原始授权规则，将“VIP”元素用“金牌”和“支付”元素取代就可以实现了。

结论

要全面认识跨管理域的服务融合的巨大魅力，授权认证是非常重要的一个环节。而授权控制中的最大挑战是建立一种能够支持各种不同服务请求的通用授权控制协议，以及一种能够在不同管理域间进行服务调用的高效的授权控制方案，同时这种方案不会引起服务提供商的管理授权规则的大量增长。

SOAP/XML技术给了我们一个很好的选择，基于这种技术之上的授权认证协议满足了不同服务相互组合的要求。同时，文中提出了一种新的授权控制方案，这种方案使用凭证转换机制，它只需要服务提供商准备很少的授权规则和转换规则用来在本地凭证和外部接入域之间进行转换。而且我们只要简单地部署一个带有这些特点的授权控制服务器就能很好地满足我们的要求。

服务融合实例