Forefront Identity Manager 2010高效身份管理 (04): Forefront Identity Manager 2010 架构介绍（一）

本系列文章由ghjconan创作，转载自ITECN。尊重原创，分享精彩。

好了，从今天开始将正式为大家介绍Forefront Identity Manager 2010。说实话，前三篇博客呢，主要是满足各位动手党的好奇心，因为如果光学理论知识的话，学完就忘，所以需要有个实际环境来进行不断操作来掌握知识。不过从我个人的学习过程来看，FIM 2010对系统工程师的基础能力要求还是很高的。这点大家已经可以从实验环境的准备过程中有所体会了，在折腾FIM 2010之前，可能还要学会折腾其它微软产品。关于这一点，我个人的理解是，因为FIM 2010所要解决的问题是位于基础架构的核心位置，会牵涉到很多东西，所以难度可想而知。编写这一系列博客的目的，主要是凭借我自身的能力，来降低大家学习FIM
2010的门槛。所以好戏现在才正式开演。

在开始具体介绍之前，我想打一个比方来告诉大家FIM 2010所处的位置。各位知道，身份管理其实是非常纷繁复杂，在本次课程中实验环境只是基于微软服务器端产品，然而在现实生产环境中，各式各样的产品可为种类繁多，如果要为每个产品提供身份管理支持，那FIM 2010真的是处在争论的中心，各个数据源都会强调自身数据的重要性，用户的某一个属性值必须有它来决定，而不是其它数据源。那么如果要在争论中心还能独善其身的话，FIM 2010本身就必须非常强壮，而要支持这份强壮的体格，那么它本身的架构就必须非常健壮。这也是接下来要讨论的话题。

如果大家看过FIM 2010 Rampup文档，或者其它文档/PPT介绍的时候，会发现FIM 2010的高阶架构是这样的：





虽然文档里面配了很多说明，但是作为初学者的话一下子肯定接受不了这么多信息。而且做为系统管理员，因为平时学过很多产品，一看到这些组件，就开始忍不住要马上记忆，但是记得越多，就越发现FIM 2010的复杂，然后会发现自己学不进了。

那么实际上，再往高阶上迈一步，让鸟瞰的范围更大一点。FIM 2010其实就是一套身份管理系统（Identity Management System，缩写成IdM System），其存在的意义就是在一个统一的数据库中保存企业中的各种身份信息，并强化企业的身份管理流程。同时FIM也是基于状态的身份管理系统，当其它数据源发生变化时，FIM 2010并不会急着将变化的内容同步到其他系统中，这一点在日后的说明中大家变化有体会。基于这一点，我们可以得到以下这张图。





有了这么一个笼统的概念之后，接下来各位就想要知道FIM 2010到底是如何实现身份信息在各个系统中流转的。就像大家知道在Exchange中，服务器从客户端接收到了一份邮件然后在发送给另一个邮件系统需要经历一个复杂的过程， 对FIM 2010来说也是一样的，身份信息在FIM 2010中的流动过程也是非常复杂的。在接下来的时间里，各位首先就要直面FIM 2010中的核心功能：同步服务。

在FIM架构中，同步服务起到的作用是根据商业需求将身份信息同步到各个应用系统中。在FIM 2010的术语中这些应用系统被称为外部系统，这当然是以FIM 2010本身作为观察视角所下的定义。因此与此相对的所谓“内部系统”就是指FIM 2010身份信息数据存储组件。这里为了简化问题，先假设同步服务只连接两端，一端是外部系统，另一端是FIM 2010本身的数据存储组件。

外部系统就不用多介绍了，它们可以是SQL数据库，CSV文件或者各个厂商的目录服务。

然后要搞清楚FIM 2010的数据存储组件的具体组成。如果把这个数据存储组件看成两个同心圆，那么外层称为连接器空间（Connector Space，CS），内层称为Metaverse（MV）。Metaverse这词本身具有传奇色彩（WIKI），目前没有合适的中文术语可以进行表述，因此在接下来的表述中会保留这个英文单词。

先来看下Metaverse。从之前的宏观介绍中，大家可以看到描述企业内一位员工的信息在各外部系统中是不同的，然而这些信息的拥有者是一致的，显而易见为了统一管理这些信息，管理者需要一张统一的视图来方便信息的存放和读取。而这张视图在FIM 2010的术语中便被称为Metaverse。

那么接下来的一个问题就是连接器空间（CS）是什么以及存在的意义。这里不妨设想下用户改名这一个场景。假设Anna Smith和Bob Black结婚之后，根据当地风俗Anna Smith要改随夫姓，变成Anna Black，于是Anna在FIM 2010中发起了姓氏更改请求。然而由于种种原因，变更申请中姓氏填错了，于是她又要重新发起另外一个请求进行更正。于是在短短的几分钟内产生了两个请求。然后我们把这个问题放置到一个大型环境，那么可以发现这些人为错误的数量是惊人的。而Metaverse本身作为一个统一管理视图，尽量避免其中的信息错误是应当予以重视的。因此开发人员在这里引入了连接器空间，来解决包括人为错误的各种问题。而连接器空间也作为一个准备区域（Staging
Area）而存在。因为FIM本身是基于状态而不是变更来管理身份信息，通过使用连接器空间，可以使得FIM 2010不需要实时维护一个同外部系统之间的连接，减少FIM 2010本身的资源消耗。连接器空间中数据存放的目的主要是用来支持数据同步，同时按照设计需要，每一个外部系统的身份对象必须在连接器空间中有一个它表他的对象。

注：Staging Area原本是一个军事术语，中文为集结待命区，这里为了淡化军事色彩，我使用了准备区域。当然这个词在数据库领域中也有所使用，微软术语网站上的翻译为临时区域，但我个人觉得准备区域更加贴近FIM 2010中使用场景。

在连接器空间中存在三种类型的对象，第一种类型是连接器（Connector），指的是该对象至少和外部系统或者Metaverse两者中的一者存在连接关系。第二种是非连接器（Disconnector），也就是和第一种类型相反的对象，它本身与外部系统或者Metavserse之间没有连接关系。最后一种类型是占位符（Placeholder），该对象存在的一个典型场景是活动目录中的经理属性，我们知道活动目录中的经理属性实际上是一个链接，在实际存储中该值是以distinguishedName的形式保存的。然而在FIM
2010导入数据时这种情况会导致一些问题，因为绝对数量上的关系，员工的身份信息通常会先于经理的身份信息导入，这时需要一种机制来保存这种连接，而FIM 2010开发人员给出的方案就是在连接器空间中使用所谓占位符对象。

在实际数据库中，连接器空间对应FIMSynchronizationService数据库中的mms_connectorspace表。





在了解完同步服务所连接的“内部系统”之后，再来看看FIM 2010是如何连接外部系统的。这里将引入另外一个术语，管理代理（Management Agent）。

Management Agent在FIM 2010中的作用是连接各个外部系统，它本身规定了需要进行同步的身份信息，信息处理规则，以及如何进行同步。简而言之，管理代理是FIM 2010和其它数据源进行联系时的代理人。FIM 2010本身自带了很多管理代理，系统管理员可以通过FIM 2010与很多信息系统进行连接。当然这也是FIM 2010考验Windows管理员的地方，因为可能其它异构系统的管理员并不清楚FIM 2010的工作机制，他们在你的配置过程中不一定能帮上忙，这点是需要各位注意的。





当然，我写本系列博客的目的就是降低大家对FIM 2010的恐惧感，至少可以先试着把微软这一侧的东西摆平，其它系统那就是人挡杀人，佛挡杀佛，看各位的功力了。关键一点是你是否有足够的信心说出“我不怕”这三个字？

扯远了，在回到管理代理本身，大家看到有这么多代理中，有一个非常特殊。那就是FIM Service Management Agent。因为它所连接的是FIM连接器空间，而这个连接器空间的作用就是作为Metaverse的镜像。Metaverse和FIM连接器空间之间的数据同步是通过非声明性规则（nondeclarative rule）来配置的。好的，各位又被我吓到了，什么叫非声明性规则？暂时可以把它理解成这是来自ILM的馈赠品，也就是所谓的老的同步规则。这个名词本身主要是用来区分在SharePoint中所配置的属于FIM
2010的新型同步规则（Synchronization Rule）。以下是一张配置好的截图：





不过请大家注意一点，这张图中的配置是为了简化后续的讲解过程，所以仅选择了非常少的属性进行映射。一旦涉及到活动目录将会变得非常复杂，这也是FIM 2010的配置过程中最复杂的一项工作，这里先给大家打下预防针。

接下来的一篇博文中将重点介绍同步规则以及在同步规则中使用的专用术语，敬请期待。