在从理论深度去理解ID Federation之前，先从最朴素的需求和实现思想上的一些思考。

我要分享帐号

　　我们大家都知道安全的一个基本原则性建议：不要共享系统帐号，这样非常不安全。这是每一个安全从业人员的基本知识，在作风险评估的时候，如果发现这样的问题我们从来都是给出负面的评价并建议用户改进。

[separator]

　　可是，在实际的业务工作中，这样一个简单的要求，其实会消耗不少的管理成本。因为，在这个认证和授权的行为中，由几个方面的因素都是多变的，是的管理起来有困难。比如，人是一个多变的因素，人的新进和离开，都会导致系统帐号的变化。而每配置一个帐号，都要不少的管理活动不得不配套，这样复杂的管理活动必然容易引起错误，或者引起管理者的投机取巧。再比如，系统本身也是一个多变的因素，随着企业竞争环境的剧烈化和多变化，新的业务会不断出现，新的管理应用也会不断配套出现。这些都带来应用系统的频繁变化，而一个新业务系统都要进行帐号的配置。那么每个系统都要为其所有相关的Stakeholder配置帐号，这又是一个比较繁琐的管理过程。在上述两种变化中，如果我们每次遇到变化都要对从人、角色、权力、具体的帐号配置等等全都进行配套调整，那将是一个非常复杂的工作，特别是对于一个大型的机构来说，甚至可以说是一个不可能完成的任务。在这样的背景下，多人共享一个系统中的帐号，就变成了一个自然的结果。

　　怎么平衡这种帐号分享要求与基本帐号安全要求的矛盾呢？

围绕ＩＤ拆解认证过程

　　解决上述矛盾，其实就是要认清楚，＂要求不要多人共享帐号＂的目的是什么。简单来说，其目的就是为了防止责任不清。而不是控制粒度问题。因为，既然让多人共享一个帐号，就是认可多人具有同样的一个角色，也就是这个觉得的访问控制规则是可以适用多人的。而剩下的就是如何确定每个人的accountability了。所以，这个要求非常类似于RBAC的需求。

　　这个时候，我们就可以将整个认证过程拆解开了：

　拆解为三步：

   1、为每个人（个体）分配ＩＤ，并对其进行认证。这个认证可以是用户名口令、动态口令、证书、生物识别等等。总之，这个步骤解决的是人的ＩＤ问题。
   2、为每个必要的系统角色分配ＩＤ。每个ＩＤ所对应的权限分配等等已经就绪。这些ＩＤ常常就是各个机器和系统上的帐号。
   3、第三步就是将上面两个ＩＤ关联起来。最简单的理解就是做一个mapping。　

　　当然，拆解和mapping还不完全，所有和ID相关的活动和操作，都要跨越/穿越这个mapping关系。最最典型的要求，就是accountability功能要得到继承，也就是审计功能应当能够将ID4R的活动对应到ID4P上去。

　　如果能够很好地实现拆解和关联，那么前面提到的挑战就得到了一个很好的解决办法。而且，你也会感觉到，这个解决方案在将事情向简化的方式推进，完全符合“安全从简单开始”的理念。