Federation of Identities

背景

Web service最吸引人的特性就是Loosely coupled, 利用它企业能够及时的将业务中的变革和创新体现在对外提供的服务(Web Service)上(创建新的服务或更新现有服务的实现)，还可以更加高效的集成企业与其合作伙伴的应用价值链。然而，实现这一目标的前提是拥有方便有效的安全保障，如果没有适当的安全保障或者需要复杂的安全保障都将影响企业间广泛存在的服务交互。试想如果企业A的员工访问其合作伙伴提供的时候服务时需要不断重复的输入自己的验证信息，那么无论在服务的方便性或安全性上都会给用户以不好的体验，从而影响服务的集成，限制Web Service在企业集成中所能发挥的作用。

假设存在如下一个场景：
John Doe是一家叫做Pharma456.cm医药公司的职员，John在自己的公司拥有一个账户，用于访问本公司的服务。Pharma456.com公司有一些合作伙伴，作为公司的职员，可以在其合作伙伴的公司所提供的服务中享有某些优惠。在本例中，Pharma456.com公司分别有一家财务公司(RetireAccounts.com)和一家投资公司(InvestAccounts.com)作为它的合作伙伴，它们分别可以为Pharma456.com公司的职员提供储蓄服务和投资服务，并给予一定的优惠。此时，如果John想以合作伙伴公司职员的身份使用RetireAccounts.com的储蓄服务，就必须向RetireAccounts.com公司提供自己的SSN(Social Security Number), Pharma456.com公司给自己的特定标识等等信息。如果没有一种身份联邦的机制，那么即使John已经在自己的公司验证过身份而且是在自己公司的网站上调用的RetireAccounts.com的储蓄服务，但是为了使用RetireAccounts.com的储蓄服务，他不得不再次到RetireAccounts.com公司验证自己的身份。而RetireAccounts.com公司并没有John的身份信息，无法实现对他的身份鉴别。

现有的解决方案

上述问题由来已久，以往主要有两种方法解决这个问题。第一种方法就是RetireAccounts.com公司将收到的John的身份信息返回给Pharma456.com公司，让Pharma456.com公司验证John的身份，并将验证结果返回。还有一种方法就是让RetireAccounts.com公司复制Pharma456.com公司的身份信息，这样RetireAccounts.com公司也就可以独立完成对Pharma456.com公司的职员的身份鉴别了。

存在的问题

可以想象这两种方法都不是好的解决方案。前者需要各个公司之间的身份鉴别服务能互相访问,而将身份鉴别服务暴露在外将带来很多安全方面的问题(例如泄漏机密), 即便不考虑安全方面的问题, 为了实现身份鉴别，服务之间的消息传递就又多了一次往返，既容易出问题(网络是很不可靠的)而且效率低下。后者虽然避免了将身份鉴别服务暴露在外, 但是实际上很难实现完全及时的用户信息的同步, 如果John离开了Pharma456.com公司, 很难保证RetireAccounts.com公司中的用户信息得到及时的更新. 另一方面, 由于用户信息涉及一些敏感数据,出于个人隐私和公司利益的考虑, 把一个公司的用户信息全部复制给另一个公司也是不太现实的.

提出新的方案

基于以上两种方案存在的问题, 得到以下结论:

1.       尽量让用户在本地完成身份鉴别, 不要将用户鉴别服务对外公开。

2.       不希望将企业的用户信息不经选择的复制到其他企业.

要想达到这两个要求, 那么必须使得经过鉴别的用户信息可以在企业间移动, 也就是实现所谓的Portal Identity. 而且这些用户信息要有选择的移动.

 

 

   利用Portable Identity ---SAML

   如何获得SAML --- WS-Trust

   SAML是如何保证身份的,SAML如何签名加密 hold-of-key sender-vouch    如何在一组服务中解决Interoperate---WS-Federation SAML用于在企业与企业之间传递.虽然我们不能让所有的企业都采用一种安全模型, 但是可以让它们在对外的时候都采用SAML,来减少集成的代价.