现在IAM/AAA/AAAA项目热火朝天，一般规划中，系统和应用常常花开两朵。系统级的IAM/AAA/AAAA相对来说，技术产品都较为成熟，项目风险也容易控制。但是应用级的IAM/AAA/AAAA建设就不一样了。一方面这方面的技术产品在国内的应用时间较短，技术储备也没有前者那么多，建设中、建设完成的项目数量也比较少，另一方面，应用级的IAM/AAA/AAAA往往涉及到应用改造，需要深入应用的架构和流程，所以惊动面比较大，牵掣的部门较多，所以“政治”“人事”就都需要考虑进来，往往不是运维部门的同学们可以自己决定得了的。

下面这部分内容大部分取材自Gartner的一个报告，“The Do's and Don'ts of Identity and Access Management ”，分析了在IAM建设中那些一定要作，那些一定不要作。 其中的一些观点也颇有启发性，我总结了几个放到下面供大家讨论参考。

[separator]

• Don't expect to use a single authoritative source of user information
  不要期望使用纯粹单一权威的用户信息源，大部分企业都使用多个“权威”的用户信息源，财务、人力、电子邮件系统，以及CRM系统中的客户信息。如果在一开始就尝试统一这些信息源，将会注定遭遇众多“政治”阻力。所以，一开始就不要有那样的打算。
• Don't aim for a single enterprise directory
  也不要期望短时期的将来会统一成为一个企业目录。因为不仅仅有上述“政治”阻力，还有技术方面的阻力，因为当前企业信息系统架构的异构性，天生就对多个目录的存在提供了一种营养和土壤。过快、过早的整合统一将会极大的降低应用的效率，甚至导致崩溃。
  因为有相当部分的用户只和一小部分系统和应用打交道，全面的整合效率和性能将会非常低下，并且可用性上也不合算。
• Don't use your enterprise directory as the authoritative repository for user provisioning
  不要使用企业目录来做用户配置管理。企业内部雇员的用户身份帐号目录一定要与外部客户目录分开处理，内部系统和应用维护的帐号应该和最终使用者的帐号分开处理。
• Don't try to integrate all applications at once
  不要想着一下子建成罗马 － 通过一个项目就能统一所有的应用。小步快跑、快速成功法则在这里都适用。选择有代表性的若干应用、制定合理的目标来当成第一个身份管理项目的范围。