Conferences and Events

....spread the word! ...some conferences and events we participated / will participate in the upcoming weeks.... presenting two of our recent identity and security management projects...

Security Zone 2012: Identity Management @ Bank Vontobel Zürich

Swiss eHealth Summit 2012: Identity Management @ Inselspital Bern

Oracle Identity Manager & Analytics Integration

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.

Oracle Identity Manager LDAP and Smart Card authentication against Active Directory

Just recently we had the requirement to configure Oracle Identity Manager (OIM) 11g for LDAP and Smart Card authentication against Active Directory.

In this article I will share the configuration steps to get this up an running.

Step 1: Configure LDAP Authentication against Active Directory
Step 2: Configure SmartCard Authentication, Certs are stored in Active Directory

We take the following as given:

• OIM 11g with Weblogic 10.3.x configured and running
• Working LDAP Server (here Active Directory) available
• SSL for OIM / Weblogic set up
• Users from AD exist in OIM (e.g. through trusted source reconciliation)
• Users in OIM have scrambled passwords

Configure Weblogic (and OIM) LDAP authentication against Active Directory

Requirements (on AD side)

• LDAP connection user with the necessary rights in AD to do subtree searches on your users and groups container, respectively in the scope we configure below
• For LDAP in OIM to work, you need an AD Group called "oimusers", in which all users who shall be able to login to OIM need to be member. The group need to be named exactly "oimusers".

Add an additional Authentication Provider
After a standard OIM / Weblogic Installation you should have something like this


Now we add an additional Authentication Provider
Name: ADAuthenticationProvider
Type: ActiveDirectoryAuthenticator
Control Flag: SUFFICIENT

 

 

Configure Provider Specific Options
LDAP Connection Information
(In a production environment you would use SSL enabled LDAP, but this configuration is not part of this article) 

Principal: Your LDAP connection user 

User scope configuration
User Base DN: Container where your users are found
Rest of the parameters stay default  

Group scope configuration
Group Base DN: Container where your groups are found
Your "oimusers" group must be found in this container or in the subtree
Rest of the parameters stay default

Optionally you can also set Weblogic Server Debugging option for troubleshooting
If needed do the same for oim_server1 as well

Restart your AdminServer.
To confirm the debug option is properly set, you should see <Debug> <SecurityAtn> entries in your logfile.

The logfile will be found in your AdminServer log directory, in our Windows Installation this is:
C:\Oracle\Middleware\user_projects\domains\OIM_DEV\servers\AdminServer\logs\AdminServer.log

Login to your Weblogic console, navigate to "myrealm" and check the Users and Groups tabs. You should now see all your users from Active Directory within the subtree of the configured scope.



Check on Groups tab and find “oimusers” (this is a regular AD group, OIM will only accept authentication for users belonging to this object as “member”). 
Notice that the embedded LDAP (DefaultAuthenticator) also has an “oimusers” group.

With that configuration step complete you should already be able to login to OIM with one of your Active Directory users.

Please note:
In our environment Active Directory is configured as a trusted source for OIM, so all the users we log in with already exist as accounts in OIM, but with unknown random passwords.
For simple LDAP login tests you can just manually create a corresponding account in OIM and give it some password. (Preferably not the same as the LDAP password, otherwise you cannot properly test)



Configure Weblogic (and OIM) Smart Card authentication against Active Directory

Add and configure an additional Authentication Provider.

Name: LDAPX509IdentityAsserter
Type: LDAPX509IdentityAsserter
Active Types Chosen: X.509 (already the default)

Provider Specific Parameters
Host: Your LDAP Host, same as used above
Principal: Your LDAP connection user, same as used above
User Filter Attributes: The attribute in Active Directory you want to map the Smart Card attribute to. In our case we map the SmartCard Subject CN to use userPrincipalName in AD.
Certificate Attribute: userCertificate. Please note default value was userCertificate;binary. This didn't work although our Certs are save in binary in AD.
Certificate Mapping: Container where your AD users are, if in doubt, use the same as during our LDAP configuration above.

Now that we configured the new Authentication Providers we need to put them in the right order.

For Weblogic to request the client Certificate, in our use case from the Smart Card, the SSL Advanced Option "Two Way Client Cert Behavior" needs to be modified for each managed server you want to be able to use your Smart Card.

You can either set it to be "... Requested But Not Enforced or ".. Requested And Enforced". 
See here for more details.

Summary

• We created one WLS Authentication Provider for LDAP authentication
• We created one WLS Authentication Provider to act as an Identity Asserter for our Smart Card certificates
• We configured both providers to "talk" to Active Directory using LDAP to find the corresponding users and to do the authentication based on certificates from the Smart Card
• Additional steps would be to put a proper authorization setup for OIM and Weblogic in place

Please give feedback if you find this useful, or if something is missing or incorrect.