在SOA和云中我们真的需要身份传递吗?_架构_Michael Poulin

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

IT 开发者，尤其 IT 安全专家已经为创建一个企业级的身份控制机制奋斗了多年。在这一领域最广为人知的倡议和模型就是单点登陆（SSO），单个终端用户的身份能够在系统间传递并能在整个企业内被认知。

在当今的 IT 环境下，安全问题还必须要处理面向服务的环境以及云计算（简称云）。许多企业安全专家及供应商都有对服务和云在 SSO 方面的考虑。尽管如此，一个简单的问题仍然需要被回答，那就是从商业视角来看，建立 SSO 对于 SOA 和云可行吗？在开发该 SSO 之前，我们必须明白当我们进入面向服务的生态系统（SO Ecosystem）和云时，身份控制的安全执行环境已经改变。

面向服务的生态系统

OASIS 参考架构基金会（SOA-RAF）[1] 把面向服务的体系结构（SOA）扩展到了包含关注 SOA 架构的 SO 生态系统概念。SO 生态系统可以解释为“一个空间中，人、流程和机器共同采取行动，把业务能力作为服务提供给自己及更大的社区以实现目标”。

在一个 SO 生态系统中，可能没有一个人或者组织能真正控制或者负责整个生态系统。任何“中心化”的基础设施，管理或控制功能，以安全性为例，只存在于签订了自由商业合同的单个服务间，如他们的供应商之间或业主之间。一个 SO 生态系统和业务以及技术都相关联的。这就允许维护者同时关注技术及业务。举例来说，在云中，技术方面的标识管理受到提供云业务的财务关系及其它约束的影响。

所有权的约束

SOA-RAF 为 SO 生态系统中的所有权定义了一个视角：“该视角关注了 SO 生态系统中对于拥有和管理基于 SOA 系统的顾虑。很多这类顾虑往往无法通过自动化来解决；与此相反，它们往往包含基于人的流程，比如：治理体。”

SOA-RAF 继续强调，“所有权……在 SO 生态系统中提出了大量的拥有其他复杂系统的不同挑战，比如：企业套件。因为当某一系统跨越多个拥有域时，任意一方在控制和授权上都有严格的限制。”所有权这一概念在企业安全上并没有真正得到考虑，因为企业本身就是由一个单一所有制域组成的。

该单一所有制域允许了 SSO，同时忽略了新老系统的混合，其应用只有嵌入的安全体制或根本就没有。在企业里，安全专家往往拥有 IT 里每个系统无限制的权限，并对他们信息系统里所有企业单元的安全负有责任。一个 SO 生态系统渗透着所有制边界，安全专家需要处理有着不同商业，技术和安全需求的多种所有制域。

服务所有权边界

SOA-RAF 声明每个服务所有者或提供者都可能有自己的特殊权利或政策。由于企业中最重要的服务是商业服务，它们一般都有不属于 IT 管辖范畴的商业所有者，比如：BU，组或团队，部门或业务线（LOB）。在这种情况下，IT 只是一个开发和维护协助者，而非所有者。而这恰恰又极大地影响了安全解决方案。

SOA-RAF 解释道，“就算……是在一个单一的组织内，不同的团队和部门之间也都经常存在所有权边界问题。这体现了组织现实情况的同时，也反应了组织管理层的真正意图和动机…因此，尽早考虑多边界给基于 SOA 系统所带来的影响，就为处理任意形式存在的边界提供了坚实的基础，而不是考虑这些边界是否会存在。”

业务及其技术服务，可能属于同一安全 / 身份域，形成了与其一致的商业所有权和相应的边界线。此外，一个域可能覆盖一个或多个业务的所有权，形成了该域的认证权威。

商业服务这一概念可能能通过“SOA 所有权的骑士法则”[2] 来总结：

该服务是我的，但是又不是我的
该顾客是我的，但是又不是我的
该伙伴是我的，但是又不是我的
该供应商是我的，但是又不是我的

换句话说，服务或者客户只知晓和见到他们的直接联系人。他们并不关心他们的联系人如何执行或他们在其商业交易中为谁服务。如果现实中，他们中有任意一人关心的话，就表明了该面向服务并没有完全实现。

商业所有权边界

商业所有权的问题在于它的边界对技术解决方案的不透明化，包括服务及其相关的安全控制。在一个身份域中，参与者可能同意承认彼此身份，然后整个系统将如同任意有 SSO 的企业般工作。同样，参与者可能拒绝开放他们的边界。任意一个商业或服务所有权彼此间都互不依赖（否则就不是一个所有权）。这意味着如果安全专家需要修改与服务相关的安全信息，就需要从其所有者那里获得同意。

进一步说，IT 不能简单地强制使用特定的安全服务，比如：政策执行，认证服务，授权服务，身份管理服务之类。需要首先征得商业服务及其客户的准许才可以。SOA-RAF 里规定这类协定以服务合同的形式存在。实际上，在 SO 生态系统中，服务合同集代替了集中的验证和授权。

服务合同和财务边界

一个服务合同至少包含有服务接口、交互和执行政策，特殊功能协议，沟通渠道，期望结果和 SLA。服务合同作为客户 - 服务关系和交互的基础的同时，其在云中也起着特殊的附加作用。

服务合同将两个云中的商业实体联结在一起，验证了这些实体不同的利益与目的。尽管在企业内部可能会同意跨服务所有权边界分享身份（由于企业单一授权），但是在云里，财务独立的商业并不会相信外来的身份（对 PKI 的采用已经验证了这点）。

对每个云供应商来说，财务利益总是高于一切。云中的财务可行性比一个合理的解决方案来的重要的多。举个例子，如果一个云供应商为客户维护其验证机构，那他为什么要接受外部消费者支付安全费用给外部的验证机构？这些客户为什么不直接付费给云供应商？这是个商业问题，而不是技术。

推广还是不推广?

服务的所有权和商业上的边界所包含的商业现实引导出了一个简单的总结：对一个 SO 生态系统中正在交互的服务链的身份的推广，尤其是在云中，只对直接沟通的客户或服务有意义。更多的推广是无益的，因为服务只和它们自己的客户联系。其它客户的身份对它们来说毫无意义，也不构成服务义务。

对跨多个服务，和一个终端用户身份的相关推广的商业交互审计的需要已经存在争议。如果这些服务由相同的认证权力机构控制的话，该需求可能是验证覆盖这一概念的一部分。如果不是，每个独立服务根据它自己的政策有相应审计。对于独立服务来说，不存在任何跨边界商业交易；相反的，每一对交互的客户服务组成了独立的交易，这有助于由内到外的交易链。

尽管如此，这并不能阻止服务接受或传输任何包含终端用户身份的外部数据。但是这些身份对这些服务并无任何潜在安全隐患。

联合身份 vs. 身份联合

企业安全已经广泛使用联合身份（FID）方法论，它使用一个与实体（人，或系统，或应用）相关联的身份“象征”。该象征是“联合的”，因为它被不同身份域所信任。这种信任通常基于一个位于身份域之上的超级管理，它不能存在于被所有权边界分割的服务环境。

服务和商业边界为身份控制组成了新的执行上下文和实际情况。尤其是工作在云里，我们跨越于技术与商业间，它们的价值、目的和解决方案有着不同的理论和理由，在这里理论的价值胜过技术敏捷性所拥有的价值。举个例子，Tim Mather 就曾在 RSAConference.com 发表过，“当谈论到（公共）云中的联合身份管理（FIM）时，FIM 是‘不成立的’。这并不是说其在技术上不成立……而是其商业流程（比如：信任接受）上的不成立" [3]”谈到一个基于第三方的身份验证解决方案. 他解释到”问题不是技术, 而是基于商业考虑以及关于接受其他组织发布的身份验证信任所引出的特定法律问题”(Open ID 有效地避免了这个问题但是对于商业交易还不够安全)

一个云 PaaS（平台即服务）阐释了 FID 的相关问题。PaaS 被认为应为所工作的平台提供特定的开发工具，但不幸的是，没有一个 PaaS 供应商能为开发者提供一套完整的用于当前“内部”IT 的开发和测试工具。因此不论供应商还是开发人员最终都将拥有一堆来自不同云供应商的不同开发工具。但是 IT 会为所有这些开放他的安全域吗？另外，只要其中一个供应商是公共云提供者，IT 就有向全世界公开其系统和应用的风险。可想而知，企业对该机遇所能有的想法。

尽管如此，该问题却并没有困扰微软的身份架构师 Kim Cameron，他于 2012 年五月宣布了微软对 FID 的新展望：基于 Azure 动态目录 [4] 的身份管理即服务。它提供了相同的集中化身份管理，但是忽略了服务的独立性和所有权边界。该解决方案除了带来将所有企业身份从企业控制中移出的附加高风险外，并没有给云用户带来更多价值。大约在 6 年前，Eric Norlan 说过，“公司将会发现将身份数据太重要，以至于无法提交给第三方” [5] 。该声明依然有效。

与 FID 相反，身份联合（IDF）是由分布式认证权威构成，它只服务于自己成员，但是可以根据它们之间的信任关系联合起一个认证请求。这些认证域的成员依赖于它们自身两种可供选择的认证机制（注册认证权威）。其中第一个选择是：身份域中每个服务将其注册认证权威参与到对同一注册域中的用户或请求者的身份验证。第二个则是：如果某一用户的身份对该注册认证权威不可知，该身份验证请求就会在认证权威的一个联合中扩散直到它被确认或否定。问题在于本地的商务甚至不相信联合的认证权威，以至于不接受他们的验证。因此，我们需要另一个联合机制。

基于身份联合模式的解决方案

在“SOA 设计模式”中有一个候选模式：联合身份模式 [6]。不幸的是，该模式与 Web Services 技术一样遭遇到命名模糊的问题。虽然该模式在名字上指的是 FID，其内容本身却更近于 IDF。该模式遵循身份域的独立性，并不试图将它们作为一个联合体。与之相反，它提倡在不同身份域之间建立云认证代理商，类似于与其认证权威相关的 A 和 B。云认证代理商利用其与 A 和 B 间的信任关系，将 A 中的一个身份令牌转化为 B 的身份令牌。然后将转化为 B 的身份令牌提交给 A 的请求者，这样该请求者就可以直接使用 B 身份令牌参与到 B 的服务中去。

但是该模式对于 A 请求者可能将 B 身份令牌与 C 域中的伙伴分享所可能发生的问题却没有任何说明。该渗透模式如果持续在别的域渗透，将造成恶意实体的产生，这就要求在 B 端需要进行一些信任和控制工作。因此恰当的 IDF 解决方案应该是基于注册认证权威间的直接协议，以避免对第三方云认证供应商的需要。

假设你在自己身份域中控制着认证权威，而其中一个服务可能同时也是一个外部认证域的成员。与之相反的例子也成立 — 每个外部伙伴的域中都可能存在一个运行的服务依赖于你的域的认证。我们将这类服务称为域代表（RR）。显而易见，任意服务都可能成为任意身份域中的一员，但是如果要维护该成员关系的话就太复杂了，而且也是个不必要的附加。

因此，你的 RR 代表了所有来自注册客户对外部身份域能力的请求。与此同时，作为外部身份域中的一员，你的 RR 可能会在该外部域中被验证为一个服务消费者。该 RR 在该外部域中扮演着一个外交官或代理角色。对于你注册域的外部 RR 也是同样的道理。有多少不同的身份域与你的进行交互，你的身份域就有多少 RR。

RR 与集中的 FID 的一个主要不同点就在于：FID 中的认证供应者以一个独立的构造实体存在，而 RR 则是一个真正的执行于注册身份控制下的商业服务。因此，可能会被本地商业参与者信任。消费者和服务之间忽视服务合同的关系使得我们不再需要跨域认证权威。

最后，需要强调的是 RR 的这一理念很好地符合了商业中面向服务的概念。RR 满足了面向服务商业中的一个基础要求：“要想和对方做生意，就必须了解对方。”换句话说，在服务交互开始前，客户必须与供应商或者服务所有者建立起信任关系。在 IDF 中，需要建立起真正客户与相应作为服务代表的 RR 间，以及 RR 与另一身份域间关系，如图 1 所示。

（点击图片看大图）

图1. 两个身份域的域代表

一个RR 可以被看作是一个中介，以维系一个ESB 系统。技术往往倾向于将ESB 系统置于客户与服务中间来脱离它们直至互不认识。这是特别遗憾的，因为它不仅破坏了[7] 商业交互要求，同时也破坏了SOA-RAF 中定义的服务交互模型。如果ESB 想隐藏某个服务，以及管理服务中任何除了信息路由或端点决策东西时，它本身都要变成一个服务或服务代理。它无法成为架构的一部分，这意味着它需要为客户处理并提供所有相关的商业责任，就像一个RR 所做的那样。

一个实际例子

假设我们有一个客户公司Ace Corporation 和两个服务：Catering 和FoodPro。其中Ace 集团和Catering 服务同属于身份域Town，而FoodPro 属于身份域Vill。Ace 已经和Catering 建立起信任关系，并在相应合同条款内同意让Catering 为Ace 的小卖部提供服务。因此，Ace 将启用Catering 的某些功能和操作。Ace 和Catering 间的合同里说明了Ace 有兴趣，而且也准备好按照合同价格只支付本地食品原料，而不包括Town 以外的运输费。

Town 和 Vill 的部分信息是公开的，并在两个域中相互知晓，但并不足以完成域间的商业操作，还须有对注册政策的服从。

显然，Catering 必需依据 Ace 的订单大小添加一个类似与 FoodPro 所提供的附加功能。Catering 意识到 Vill，但是由于不是 Vill 的会员进而无法与其会员直接交互。与此同时，Town 的卡车服务已拥有 Vill 域中的成员资格。该卡车服务提升它在 Vill 商业服务中运输产品的能力。

（点击图片看大图）

图 2. 跨安全边界的商业交互

因此 Catering 联系了 Town 里的卡车服务。该卡车曾经服务过 FoodPro，并能在运输上提供一些优惠，比如，它可以使用 FoodPro 中只对 Vill 居民开放的部分功能。另外，卡车服务可以联系 Vill 中其他食品供应商，并在与本地服务竞争对手竞争时获取优势。该附加商业价值吸引了 Catering，使他决定使用 Truck 的服务，而非成为 Vill 域中一成员，为了其市场份额而努力。

当 Ace 与 Catering 建立起服务合同时，Cattering 与卡车服务也建立起了附加服务合同，这反过来，建立起一个如图 2 所示的与 FoodPro 相关联的服务合同。很有可能客车公司在与 FoodPro 签订附加服务合同时，他就已经和 Catering 签订了服务合同。当 FoodPro 接受到卡车服务的合同请求时，因为该请求是从 Vill 发过来的，FoodPro 并不会问它是如何发起的。因此，如果 FoodPro 意外接收到来自卡车的 Ace 身份，FoodPro 将无从处理。

附加想法

在现实世界的 SO 生态系统和云中，对终端用户身份的渗透是无效的，甚至是不安全的（一个商业服务可以学习到谁是另一商业的客户）。我们已经建立了以下事实：不同认证或身份域，连同不同服务或商业所有者在云里由于他们相对立的利益，都是竞争关系。因此，越过直接交互实体范畴，对终端用户身份渗透进行投资在资源和资金上都是一种浪费。

我们知到服务只考虑与它直接交互的客户和供应商，它并不处理来自其他服务的客户。服务或客户可能需要来自外部身份域服务所提供的功能，以及交叉域边界上一个良好的商业解决方案（连同所有权边界）都是推荐的基于 RR 的身份联合模式。在该模式中，所有服务和客户都在注册认证权威的控制和保护下，停留在他们身份域的同时，通过后者共享的域代表相互联合起来。

资源

Reference Architecture Foundation for Service Oriented Architecture Version 1.0 . Committee Specification Draft 03 / Public Review Draft 02, July 2011. On-line resource
Michael Poulin, “Knight Rules of Ownership in Service-Oriented Ecosystem” Business Ecology Initiative & Service-Oriented Solution, ebizQ, Jun 2012. On-line resource
Tim Mather, “Federated Identity Management in the Cloud” Experienced Security ,Dec 2010. On-line resource - Federated Identity Management in the Cloud
Kim Cameron, “Identity Management As A Service” Kim Cameron’s Identity Weblog, May 2012. On-line resource
Eric Norlan, “Identity management as a service” Digital ID World, Apr 2006. On-line resource
Federated Identity Pattern . SOA Patterns, a Community Site for SOA Design Patterns. On-line resource
Michael Poulin, “Does ESB fit with Business Service?” Business Ecology Initiative & Service-Oriented Solution, ebizQ, Aug 2009. On-line resource

关于作者

Michael Poulin 博士是位于英国伦敦的 BuTechCon 有限公司的首席业务和技术架构师。该公司为 EMEA 地区的客户提供企业级业务技术架构解决方案。他曾经写过《Ladder to SOE（Service-Oriented Enterpirse》一书以及多篇关于SOA 治理（发布于InfoQ）和云计算文章。他是OASIS 成员之一，同时也工作于SOA 技术委员会，和参考架构基金会（RAF）子委员会，在这里他为SOA RAF 委员会规范三个草稿的编写做出了很大的贡献。他为联合架构师课程的认证计划撰写了SOA 模块，并被包含在IASA Body of Knowledge 中，目前发布在ebizQ 的一篇博客中。