商业所有权边界商业所有权的问题在于它的边界对技术解决方案的不透明化，包括服务及其相关的安全控制。在一个身份域中，参与者可能同意承认彼此身份，然后整个系统将如同任意有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则是一个真正的执行于注册身份控制下的商业服务。因此，可能会被本地商业参与者信任。消费者和服务之间忽视服务合同的关系使得我们不再需要跨域认证权威。 |
