| |||
|
作者:Firdaus Fraz
Oracle Identity Manager 中针对协调、协调事件排序可供选择的方案和相关限制
2013 年 4 月
本文讨论协调和协调事件排序;协调数据从 Identity Connector Framework (ICF)(基于 Oracle Identity Manager (OIM) 连接器)到 OIM 信息库的功能流;协调排序的优缺点;以及可供选择的方案和相关限制。
OIM 用于完整的身份生命周期管理。无论是哪种企业环境,企业身份都可能分散在各种应用程序中。如果具备 OIM 供应解决方案,它将与所有这些应用程序进行交互来管理身份。OIM 通过 OIM 连接器与企业应用程序通信,并在内部数据存储中保存所有身份数据的副本。
为了获取所有身份数据,OIM 使用协调引擎协调来自受管目标应用程序(企业应用程序)的数据。
首次部署 OIM 时,将从所有权威来源和其他目标系统全面执行初始协调任务。此后,将持续执行协调,逐步从所有目标系统获取数据。OIM 在 OIM 数据存储中使用不同的实体表示权威来源数据和其他目标系统数据。
权威来源是特定类型身份(例如用户、角色、组织)可靠、可信的基础,并且还推动了该身份在 OIM 中的创建。用户有权访问的企业应用程序(称为目标系统或应用程序实例)通过 OIM 进行管理;目标系统数据存储在每个用户的 OIM 数据存储中。
持续的增量协调更新 OIM 中的身份数据(用户、角色、组织)以及与用户的企业应用程序帐户对应的数据。
现在我们对 OIM 中协调的基本类型有了比较清楚的认识,接下来开始介绍协调排序的概念、OIM 中协调事件处理的工作原理、协调排序的优缺点、可供选择的方案和相关限制。
顾名思义,协调排序是指按一定的顺序从目标应用程序协调数据,然后在 OIM 中按该顺序处理协调的数据。例如,权威来源协调。假设我们从轻量型目录访问协议 (LDAP) 目录(或任何其他应用程序)协调用户。由于是权威来源协调,所以从 LDAP 目录协调的每个用户也将在 OIM 中创建。现在,考虑每个用户实体都有一个关联的管理器 ID 作为一个用户属性。如果在 OIM 中创建用户管理器的用户实体之前处理了用户创建的协调事件,OIM 用户创建将失败。原因是:OIM 创建用户时,“manager ID”字段将参考用户的管理器;OIM 将尝试在 OIM 中找到管理器实体,此过程中会失败。
但如果我们能够按顺序创建/处理此类事件,让用户的管理器实体在 OIM 中先于被报告者的用户实体创建,那么我们就不会面临失败。这只是一个例子。协调排序发挥作用的场合还有很多。
以上讨论的情况可以通过事件的自动重试或自定义调度任务来处理;在以后的文章中我们再来讨论此类解决方案。
OIM10g 有一个现成的产品特性可以实现协调排序。提供了一个标志(位于设计控制台)和一个资源对象表单,可针对 OIM 中定义的特定资源实现协调排序。资源对象表示 OIM 的受管目标系统。(在 OIM R2 版中,用被称作“应用程序实例”的 OIM 实体表示目标系统。)
该特性已停止使用,因为协调事件排序带来的额外开销影响了性能。
OIM 11g 带来了许多架构上的变化,改善了产品的功能和性能,同时采用了异步处理。考虑 OIM 中的用户创建:用户创建所必需的活动(例如,验证用于创建用户的数据)以同步方式执行,创建用户之后会异步执行审计条目创建等活动。
接下来,我们将讨论 OIM11gR2 中的协调处理和一些可用的事件排序方案。但是请注意,OIM 中无法对异步处理进行排序。此外,排序有其自身的局限性,下面我们会简要讨论。
OIM ICF 连接器读取从目标系统协调的数据。然后,将数据传递给作为 OIM 服务器一部分的 ICF 集成层。ICF 集成层调用 OIM API 创建协调事件。
有关 OIM Identity Connector Framework 的更多信息,请参阅 OIM 文档:
http://docs.oracle.com/cd/E21764_01/doc.1111/e14309/icf.htm
下面将介绍从 OIM ICF 连接器开始,经过 OIM ICF 集成层,然后到 OIM 协调引擎的协调事件处理流。
ICF 提供 org.identityconnectors.framework.spi.operations.SearchOp 接口执行协调操作。
SearchOp — org.identityconnectors.framework.spi.operations.SearchOp。
所有与协调有关的操作都使用 ICF 提供的搜索功能执行。需要支持协调操作的连接器包应实现此接口,此接口又要求连接器开发人员提供两个方法的实现:
org.identityconnectors.framework.common.objects Interface ResultsHandler
handle (ConnectorObject obj)
ICF 集成层处理传递给 ResultsHandler 的数据,应用定义的转换,并根据对应的属性映射查询定义创建属性名称-值对的映射。属性名称可以是 OIM 用户表单的属性名称,也可以是应用程序实例处理表单的属性名称,具体取决于创建的映射是用于供应还是目标/受信任协调。
协调数据已就绪,现在即可传递给 OIM 协调 API。ICF 集成层允许定义批处理大小。根据这个批处理大小,将协调数据传递给 OIM 协调批处理 API“createReconciliationEvents”。数据的顺序与传递给 ResultsHandler 的顺序相同。
createReconciliationEvents(InputData [ ] input, BatchAttributes
batchAttribs)
在 OIM11gR2PS1 中,增强的 ICF 集成层可以通过多个线程提交协调事件创建批处理。默认线程数量是 1(该值可在 ICF 配置查询中配置)。可以增加线程数。
注:提交用于跨线程创建的协调事件无法排序。
OIM 协调引擎处理批量输入数据,并按照相同顺序创建协调事件。创建协调事件只是在 OIM 协调数据库表中创建一条记录。
OIM 还定义了协调的批处理大小。OIM 协调引擎不断将创建的协调事件添加到批处理,一旦达到批处理大小,便将批号(批处理的唯一编号)提交到 JMS 队列。
OIM 协调的消息驱动 Bean (MDB) 读取 JMS 队列并从 JMS 消息接收批号。MDB 调用一个数据库存储过程并向其传递批号。
存储过程使用批号从 recon_Events 数据库表读取所有协调事件。与此同时,它还使用协调事件键对数据排序。因此,在独立的数据库安装中,会按照协调事件的创建顺序处理协调事件(假定协调事件键描述了正确的顺序)。
协调事件键使用数据库序列生成。所以在数据库集群中,无法确保按照记录插入数据库的顺序分配协调事件键,因为不同的集群节点可能会使用不同的数据库序列。
从 11g 版本开始,协调排序并不是 OIM 中现成的产品特性。虽然可以通过一些变通方法实现自定义协调排序解决方案,但它们会有一些局限性。
虽然我并不推荐接下来要介绍的方法,但不失为一种选择。在低协调负载下,该方法可能很好用,但对于高负载完全没用。
请注意,此方法只适用于基于 ICF 的自定义连接器。
可以在 ICF 自定义连接器中通过以下代码流实现排序(在 ICF 连接器中,按照所需顺序为每个协调记录直接调用 OIM 协调 API,而不是将协调数据作为输入传递给 ICF 服务提供程序接口 (SPI) ResultsHandler):
createReconciliationEvent (java.lang.String psObjectName,
java.util.Map poData, boolean pbFinishEvent,
java.lang.String psDateFormat)
processReconciliationEvent (long rceKey)
在该连接器的协调配置文件中,将 OIM 协调批处理大小定义为“0”(零)。
Firdaus Fraz 是 Oracle 融合中间件身份管理 A 团队的首席解决方案架构师。她的职责是就实施最佳实践、架构、用例设计和故障排除为 IDM 全球范围的客户和合作伙伴提供指导。