Wednesday Nov 25, 2009

Role Manager and Directory Server Integration

Last week at work there were some discussions about Sun Role Manager (SRM) and its use of LDAP Server for authentication. I tested this Role Manager integration with Sun Directory Sever version 6.3 as my LDAP server and I am sharing some information about this setup. The high level steps for this integration are as follows:

1) Configure the Role Manager (SRM) "" file to reflect your Directory Server (DS) settings. The following document discusses the "" file settings:

2) For the users that you want to allow access to SRM, create corresponding users with "uid" in DS same as "username" of SRM (RBACx) users. We are assuming that "uid" attribute will be used for authentication to directory server.

3) To verify that the setup is working correctly, edit the of your SRM installation and add the following property:
Restart the application server after adding the above line. This DEBUG setting is only being added for verification purposes and should be removed once the setup is working correctly.

4) Login to SRM GUI using credentials of a valid Sun Directory Server user that also has a SRM(RBACx) user account. In my example below, DS "uid" of "manish" is used for authentication and for this "uid" there is a corresponding SRM(RBACx) "username" in SRM. If you have this setup correctly, you should expect to see logs similar to following lines in rbacx.log file:

21:19:18,125 DEBUG [MultipleChainablePasswordDaoAuthenticationProvider] ----> using authentication dao []
21:19:18,125 DEBUG [PasswordDaoAuthenticationProvider] ---> attempting authentication for user 'manish'
21:19:18,125 DEBUG [PasswordDaoAuthenticationProvider] ------> looking for user 'manish' in cache
21:19:18,125 DEBUG [PasswordDaoAuthenticationProvider] ------> loading user 'manish' from backend
21:19:18,125 DEBUG [LdapPasswordAuthenticationDao] Connecting to ldap://,dc=com/null as manish
21:19:18,130 DEBUG [LdapPasswordAuthenticationDao] keeping ldap context prefix
21:19:18,212 DEBUG [LdapPasswordAuthenticationDao] Returning user: Username: manish; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_ACCESS_IDC_VIEW, ROLE_AUTHENTICATED_PRINCIPAL: Internal RbacxUser: Last name: kapur; First name: manish; Email: manish@example-DOT-com
21:19:18,214 DEBUG [PasswordDaoAuthenticationProvider] ------> loaded user 'manish' from backend
21:19:18,214 DEBUG [PasswordDaoAuthenticationProvider] ------> putting user 'manish' in cache
21:19:18,215 DEBUG [PasswordDaoAuthenticationProvider] ---> successful authentication for user 'manish'

Now let's try logging in to SRM GUI with a valid LDAP user who does not have a SRM(RBACx) account.  When using a DS "uid" that does not have a corresponding SRM(RBACx) "username" the access to SRM GUI should not be allowed. In my example, I used "uid" of "denck" and made sure that "denck" "username" does not exist in my SRM setup. The rbacx.log entries in this case should look like follows:

11:59:25,598 DEBUG [MultipleChainablePasswordDaoAuthenticationProvider] ----> using authentication dao []
11:59:25,598 DEBUG [PasswordDaoAuthenticationProvider] ---> attempting authentication for user 'denck'
11:59:25,598 DEBUG [PasswordDaoAuthenticationProvider] ------> looking for user 'denck' in cache
11:59:25,598 DEBUG [PasswordDaoAuthenticationProvider] ------> loading user 'denck' from backend
11:59:25,598 DEBUG [LdapPasswordAuthenticationDao] Connecting to ldap://,dc=com/null as denck
11:59:25,601 DEBUG [LdapPasswordAuthenticationDao] keeping ldap context prefix
11:59:25,602 DEBUG [CacheModel] Cache 'RbacxUser.rbacxUserCache': cache miss
11:59:25,603 DEBUG [CacheModel] Cache 'RbacxUser.rbacxUserCache': stored object '[B@1792c41'
11:59:25,603 WARN  [UserManagerImpl] RbacxUser with username: 'denck' not found
11:59:25,604 ERROR [MultipleChainablePasswordDaoAuthenticationProvider] ERROR: Bad Credentials User does not have RBACx account!

That's it! Wasn't it easy? Once you have this integration working, remember to remove the DEBUG log property that was added in step 3 above.

Friday Oct 23, 2009

Identity Manager and Password Policy Special Characters

This question has come up a couple of times so I thought I will write a quick blog about it. In Sun Identity Manager (IdM), the password policy can be setup with character type rules that apply to the policy. What is the list of Special Characters in the password policy?

The list of Special Characters that is used by IdM password policy is in the UserUIConfig object. You can look at this using /idm/debug page and find this list in Configuration->UserUIConfig object. There is a tag called <PolicySpecialChars> in this UserUIConfig Configuration object where these characters are defined.

Friday Aug 14, 2009

Logging Client IP Address instead of Load Balancer IP Address

If Sun Identity Manager version 8.1 is deployed with a Load Balancer or Reverse HTTP Proxy server in front of it and you need to log the IP address of the actual client in Audit logs then you need to configure Identity Manager (IdM) to pick the client IP address from the HTTP request headers. For example, if the Load Balancer sends the actual client IP address in the "X-Forwarded-For" HTTP request header then you would have to modify the IdM “” file to make it read this header and log the client IP address from this header. To do this, edit the "" file and set "client.headerIPVariable" as follows:


Save the “” file and restart IdM server. Now when a user logs in to IdM, you should see the actual IP address of the actual client rather than the Load Balancer IP address being logged in IdM Audit logs. Some times the "X-Forwarded header" of an incoming HTTP request can contain multiple IP addresses like "<Client IP>, <Proxy IP>, <Load Balancer IP>". In this case, I noticed that IdM 8.1 logs all three IP addresses, which is nice.

Monday Aug 03, 2009

Integrating Sun Role Manager and IdM using SPML

I have come across many customers trying to integrate Sun Identity Manager (IdM) and Sun Role Manager (SRM) products and I thought this will be a good topic to write about. In an environment where Sun IdM is already deployed, Sun Role Manager (SRM) can connect to IdM using SPML interface and then it can be used to import user data. In such integration, Sun IdM and SRM need to be configured to allow using SPML as the way of exchanging provisioning information.

Here are the high level steps to configure this integration between SRM and IdM:
  1. Log in to SRM and navigate to Administration->Configuration->Provisioning Servers. Click on the New Provisioning Server Connection button and select Sun from the list.

  2. Enter the following information on "New Provisioning Server Connection" screen -
  3.  Connection Name - Enter a name for the new connection being created with the Sun IdM. This connection name is used during import process instead of the Host Name and Port, which is difficult to remember. e.g. "Sun IDM Connection"
     SPML URL - Here, SPML URL pattern is - http://host:port/idm/servlet/rpcrouter2
     e.g. http://localhost:8080/idm/servlet/rpcrouter2
        \* User Name - “configurator”
        \* Password - “\*\*\*\*\*\*\*\*\*\*”
        \* Check Role Consumer if you want to enable ad-hoc roles transfer and update between SRM and Sun IdM

  4. Log in to Sun IdM as "configurator" and navigate to Configure->Import Exchange File and import "rm_idm_init.xml" and "spml.xml" files. The "rm_idm_init.xml" file can be obtained from SRM installation(look under $SRM_HOME/conf/spml directory). This completes the SRM-IdM integration configuration.

  5. To import users or accounts from Sun IDM, log in to SRM and navigate to Administration->Configuration->Import/Export Click on Schedule Job and Select the Sun IDM connection that was set up in step 2 and click on Next. You can check the "Run Job Now?" check box to trigger the user import job immediately. Or you can schedule the user import job on a future date. Similarly, you can import accounts by clicking on the Import Accounts link in the schedule job window.
NOTE: The above blog entry was originally written back in August 2009 for older SRM 4.x and Sun IdM 8.0 releases. Since then there have been several enhancements and improvements made to better integrate these two products. There is also newer documentation available for this integration which covers more details. Please refer to the following newer document that covers all the new use cases for this integration: .




« July 2016