您所使用的各种身份pipe理解决scheme的相对优势和劣势

一年前，我花了一些时间对微软的Identity Lifecycle Manager进行原型devise。 自那时起，他们就开始改变这种状况，所以这可能并不准确。 与此同时，我也花费了时间与Novell IDM合作。

ILM与IDM有一些明显的区别。

• 箱子里有更多的连接器 。 与Novell IDM不同的是，您不需要额外购买像Oracle和MS-SQL连接器那样的东西。 如果你的成本意识很强，这是一个巨大的成就。 在我们的环境中，成本差异是10万美元而不是15000美元。
• 新对象复制需要自定义代码至less在我对产品的评论中，“新build对象”事件需要链接到一个编译的DLL，它实际上处理远程环境中的对象创build过程。 大概在VisualStudio中编译，这包含了在远程标识域中实际build立一个新的对象和相关环境所需要的function。 一方面，这可以让您完全控制安装过程，这是Novell IDM不太了解的。 另一方面，您需要能够在Visual Studio中创buildC＃/ VB程序。
• 几乎没有定义好的转换阶段 IDM非常擅长创build描述两个环境之间的对象转换的各个阶段的可视化环境。 ILM没有这个。 IDM非常直观。 ILM需要大量的阅读。 更重要的是，要想在ILM的中间转换阶段需要一个编译的DLL，在IDM中，它大部分是通过Novell自1999年以来发展起来的DirXML脚本来处理的。
• 糟糕的devise工具没有Identity Manager Designer的等价物。

Novell IDM确实是身份pipe理解决scheme的顶级。 它已经上市时间最长，并有机会真正巩固其function集和思想共享。 尽pipe它比ILM花费更多，但你确实得到了你所付出的东西。 最后，在我们的环境中，ILM与IDM的成本将会被淘汰，因为基于ILM的环境需要额外的工作时间。

最后我们决定最便宜的方法是继续自己的。 我们已经build立了自build系统，成本预测与IDM / ILM实施项目本来就没有太大差别。 惯性赢了。

我只涉及到Sun IdM项目的外围，然而到目前为止我所听到的只有一致的评论是涉及到相当奇怪的XPRESS脚本语言。 这是基于xml的，就像没有其他的脚本语言。

奇怪的是，尽pipeSun IdM几乎完全由Java构build，但不能使用Java或任何其他通用语言来编写数据转换，工作stream，导入/导出等。

我唯一可以担保的部分是Active Directory连接器，它看起来工作得非常好，而且可以高度定制，允许几乎无限制的属性和类pipe理（不是开箱即用的），还有一些AD安全pipe理。

我想就Froosh关于SUN IDM的评论展开讨论

XPRESS语言有点奇怪，但是SUN是从Waveset购买IDM解决scheme的结果。 虽然他是正确的，你不能独自从Java写一个工作stream，你可以从XPRESS“调用”Java类并传入参数。

整个解决scheme并不可怕，但是你把所有的东西写在XPRESS中，然后把它们转换/解释成Java类，所以有很多开销。

在研究IDM解决scheme的同时，请记住，在Oracle收购SUN后，SUN IDM可能会以某种方式转换/迁移到Oracle的解决scheme。

我已经研究了几个解决scheme，我将它们排列如下（请记住每个都有自己的利基）

1. Novell（令人敬畏的大型机集成）
2. 孙（只要记住它的未来是有问题的）
3. 甲骨文（拥有最佳的访问pipe理解决scheme）

我还没有机会研究微软的解决scheme，但是如果你是一家微软的商店，那么它与AD和Sharepoint的集成非常好（据我所知）。

– 约翰

我们正在Oracle，Sun，Microsoft和Novell之间寻找一个好的IDM解决scheme。 你有任何机会可以告诉我们的优势和劣势的比较图表。

你的帮助是非常appriciated。

-Srini [email protected]