It was so cool: I logged into OIA, clicked
Administration-> Configuration -> Import/Export and scheduled a job of
Type Export Roles. A few minutes later, they were all there, the roles we
created in OIA now existed in OIM!
Granted, both OIM and OIA are products that are still “work
in progress” and need enhancements to provide complete functionality. Regardless,
it was still good to complete that last step of the integration process and
test a full user lifecycle:
Users are created or updated in OIM on a regular basis; these users are
then imported to OIA. Based on pre-defined rules created in OIA, the users get
specific roles assigned to them. This new assignment is then read by OIM which
acts as a provisioning server and grants/revokes access based on the policies
associated with these roles.
When it comes to using OIA-OIM as a tool to manage users via
Roles, not simply for auditing and compliance purposes, there were three main
issues that stood out to me. First is role hierarchy. When you export roles
from OIA into OIM, the parent child relationship between roles is lost. In
other words, when we look at all the roles in OIM, they exist as a flat
structure and assignment of a role would not provide any automatic inheritance.
The second issue that makes the integration not as clean is
that in OIA, a Policy can only have a single resource associated with it. In
OIM we can associate as many resources as we please to a single access policy.
Thus, during my ‘Export Roles’, I ended up having 3 separate policies for the
same role if they were associated with 3 different resources. Had this policy
been created in OIM directly, we could have had a single policy.
The third issue did have a simple workaround. On the same
page where I clicked ‘Export Roles’, the link below says ‘Export Policies’.
Policies of course, define a role. Thus in OIA, we need to
create Policies separately and then associate them to a Role. This ‘Export
Policies’ feature however, does not work. Clicking on this link gives the
message below. This message is incorrect since provisioning servers are
available.
The only way to export policies associated with a role is to
‘Export Roles’. Along with the roles, all associated policies are also
transferred to OIM.
Overall, from what I understand, the future releases on
OIA-OIM will share the same database for Roles. Thus explicit integration may
not even be necessary.
For our current OIA-OIM integration, the technical
documentation was quite detailed and helpful. (http://docs.oracle.com/cd/E24179_01/doc.1111/e23377/toc.htm)
The one issue we had was integrating resources of type
‘Generic Technology Connector’ (GTC) in OIM with OIA. If you read the documentation,
it clearly says that the ‘AccountName’ and ‘ITResource’ properties should
be set to true on the parent form. The problem was that with GTCs, we didn’t
have a field for which the Property ‘ITResource’ could be set like in the case
of Active Director, eDirectory etc. What we had to do was create a new field/column
of type ‘ITResourceLookupField’ and set the value to the name of the GTC. Now
the property ‘ITResource’ could be set to true for this field/column. Once this
new form with the additional column was made Active, the integration for GTCs between
OIA and OIM worked as expected.
One issue that we still don’t have a clear resolution for is
the OIA rules used to automatically assign users to roles. Manually creating
over a 100 rules (if 100 roles exist) is quite tedious, not to mention
management of such a large set of rules is quite impossible. Even if the logic
is quite simple, for example, if field DepartmentName has value ‘XYZ’ then put
him in Role ‘XYZ’, there is simply no way to create one single rule that can
dynamically check values and assign roles. Hopefully the future releases will
address this problem.
No comments:
Post a Comment