Writing Java Extensions in ITIM

Writing Java Extensions in ITIM

By Siva Praturi

The Identity Manager provisioning platform is designed with extensibility as a primary goal. Below are few typical scenarios in which we generally extend ITIM capability to meet business requirements.

-          Generate UniqueIds during provisioning accounts

-          Adding custom debug messages to ITIM log

-          Custom approval process that is determined by looking up an approver in a database

You can extend ITIM workflows in two ways: create a workflow extension in Java that can be called as a regular operation, or extending the JavaScript Engine with Java

To Extend JSEngine, One method to write an extension in java that is called from Tivoli Identity Manager (TIM), is to add a new custom class into the application and then call it from Javascript.

There is an alternative method, which uses classes that implement the com.ibm.itim.script.ScriptExtension interface. This method allows extensions to be limited to specific TIM components and access context information such as variables. This method is more complicated.

Developing Java Extensions in ITIM

Below figure shows typical deployment of custom Java Extensions in ITIM.

 Steps involved in writing Java Extensions in ITIM are

1. Develop & build custom java code as per business requirement.
2. Deploying the new extension.

-          Updating the Application Server's Classpath

-          Registering the JavaScript Extensions

3. Test Java Extensions by calling them from ITIM workflows.      

Updating the Application Server's Classpath

TIM is a J2EE application, running on top of IBM WebSphere Application Server (WAS). To add a Java class to the application, follow these steps:

1. Compile the Java code into a class file. To use the TIM API, put $ITIM_HOME/lib/itim_server.jar the class path

2. Include the Java class and properties file into a Java archive (JAR) file.

3. Log on to the WAS integrated services console. Perform step 4 or step 5 to add jar file to classpath

4. Create a new shared library that includes the JAR file you created. Modify the ITIM application: Change the Shared library references to add the new shared library.

5. Another option is to Expand ‘Environment’ menu and click on ‘Shared Libraries’. Click on ‘ITIM_LIB’ shared library. Under ‘General Properties’, append in (JAR) file in list of Classpath property.

6. Save the modified WAS configuration.

Registering the JavaScript Extensions

There are the steps to call the new class from JavaScript:

1. Edit this file: $ITIM_HOME/data/scriptframework.properties

In the file, add a property that starts with ITIM.java.access whose value is equal to the name of the new class. For example:  ITIM.java.access.test=com.ibm.tivoli.javaext.TestClass

2. Restart WebSphere Application Server

3. Use the class in JavaScript within ITIM to test it. For example: define a variable test in identity policy and request an account.

 var test = new com.ibm.tivoli.javaext.TestClass()

Note: To learn more on ITIM Extensions, look at the demonstration code at $ITIM_HOME/extensions/5.1/examples/directory.

Fix issue with Java Applets in ITIM Console

Fix issue with Java Applets in ITIM Console

By Siva Praturi

The IBM Tivoli Identity Manager administrative user interface (ITIM Console) uses java applets which requires a Java plug-in in browsers (e.g. IE & Firefox)

Below are two common issues we face while using them.

1. Java applets not getting loaded
2. Can not copy content from Java applets

To resolve issue#1 you need to install latest JAVA/JRE and that would automatically set the Java plug-in in browsers (e.g. IE & Firefox).

To resolve issue#2 you need to update java.policy. See steps below.

• Locate java.policy file (JREPATH \lib\security) on the server
• Add the following line down the bottom before the last closing bracket.

permission java.awt.AWTPermission "accessClipboard";

• Save the java.policy file

Note: if your system has multiple JRE installed, then you need to locate the correct java.policy file and update it.

After fixing issues, close all browser instances and Open new one to access ITIM Console.

Unable to run reports from ITIM console

Unable to run reports from ITIM console

By Siva Praturi & Vamshidhar K

When an attempt is made to run run reports in ITIM  console, the following message is displayed on the screen

"CTGIMU793E : Reports cannot run while the report data synchronization is in progress."

It happens if data synchronization task has failed for some reason and status column in SYNCHRONIZATION_HISTORY table is not updated. The only way to correct this issue is to update the status column manually.

When data synchronization task is started from ITIM console, then you will find one row with STATUS of "Started" in the SYNCHRONIZATION_HISTORY table.

This is what ITIM uses to determine if Data Synchronization is in progress or not. Most likely the actual processing finished long ago with some kind of error that was not reflected in the SYNCHRONIZATION_HISTORY table.

The database administrator can correct this situation by updating the status of the "Started" synchronization entry to "Failed". See DB2 SQL commands below.

DB2 CONNECT TO ITIMDB USER ITIMUSER USING PASSWORD

SELECT * FROM ITIMUSER."SYNCHRONIZATION_HISTORY" where status='Started';

UPDATE ITIMUSER.SYNCHRONIZATION_HISTORY set status='Failed' where status='Started';

DB2 CONNECT RESET

Manual update to SYNCHRONIZATION_HISTORY table will enable to run data synchronization task from ITIM console. It may take to complete data synchronization and some times it may result in below status

"Last synchronization completed with 8 non-fatal exceptions. Check Tivoli Identity Manager trace and message log files and application server log files for details"

After checking log files you may find CTGIMF007E and "LDAP: error code 32 - No Such Object" errors. This error occurs as ITIM LDAP contains a DN that no longer exists. One way to fix it by identifying and fixing them manually.

References:

http://www-304.ibm.com/support/docview.wss?uid=swg21303678

http://www-304.ibm.com/support/docview.wss?uid=swg21593082

DB2 HADR Setup and Failure Scenarios

DB2 HADR Setup and Failure Scenarios

By Vamshidhar K

High Availability Disaster Recovery (HADR)

HADR is a data replication feature that provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary, to a target database, called the standby. The two primary goals for HADR are fastest failover possible and easy to use.

Let us consider an example with  IBM Tivoli Identity Manager with HADR setup using DB2 database. In this scenario, ITIM Database is residing on two servers serverOne and serverTwo with a database name ITIMDB. HADR is setup between two servers with  serverOne as primary and serverTwo as standby. The two databases are in Peer state, Synchronous mode and the connection state is Connected.

The following configuration parameters would have been set during HADR setup:

Sl. #	Configuration Parameter	serverOne	serverTwo
1	HADR_LOCAL_HOST	serverOne	serverTwo
2	HADR_LOCAL_SVC	serverOnePort	serverTwoPort
3	HADR_REMOTE_HOST	serverTwo	serverOne
4	HADR_REMOTE_SVC	serverTwoPort	serverOnePort

The two possible failure scenarios that could occur are listed below and actions that need to be taken are detailed further in the article.

• The standby server fails
• The primary server fails

1)      The standby server fails

The primary server regularly sends log buffer over to the standby and will wait for the number of seconds defined by the HADR_TIMEOUT configuration parameter (by default it's 120 seconds). In the case of standby server failure, primary server will not receive any response for HADR_TIMEOUT seconds then the primary server will continue to process transactions and will not try to contact the standby again.

Impact:

The performance is impacted once when the primary server determines the standby server offline.

Solution:

There is no need to perform any action after the standby is online. As the standby will contact the primary to say it is alive and the standby will automatically resynchronize itself. Once it is back in Peer state, the primary will again ship log buffers to the standby.

2)      The primary server fails

When the primary server fails, the connections to that server will be severed

Impact:

When the primary has failed then all the transactions on primary must be routed to standby so that there are no loss of transactions and response to the requests.

Solution:

When the primary server fails, standby server can be made as primary by forceful takeover (run the TAKEOVER HADR ON DATABASE database_name BY FORCE command which will cause the standby server to become a primary server). The standby will apply the last log buffers that it has (if there are any left to apply), undo any in-flight transactions, and then open the database for connections. At this point the automatic client reroute will successfully establish a connection from the client application to the standby (now primary) server and inform the application that the most recent in-flight transaction has been rolled back.

Important DB2 Commands:

a)      To stop any applications connecting to databases and ensure that those other applications are not requesting and holding agents.

DB2 QUIESCE INSTANCE database_name IMMEDIATE FORCE CONNECTIONS

In quiesced mode, users cannot connect from outside of the database engine and the trace file is less cluttered.

b)      Another command to start an instance in a quiesced mode.

DB2START ADMIN MODE

c)       To restore user access to instances or databases which have been quiesced for maintenance or other reasons.

DB2 UNQUIESCE INSTANCE database_name

d)      To check the status of HADR.

DB2PD –DB database_name -HADR

e)      To display detailed information the current database manager configuration parameters.

DB2 GET DBM CFG

DB2 Commands to establish HADR between serverOne and serverTwo:

1)       Execute the following command from serverOne

DB2 TERMINATE

2)       Execute the following command from serverTwo

DB2 TERMINATE

3)       Execute the following command from serverOne

DB2 DEACTIVATE DATABASE serverOne

4)       Execute the following command from serverTwo

DB2 DEACTIVATE DATABASE servertWO

5)       Execute the following command from serverOne

DB2 START HADR ON DATABASE serverTwo USER user_name USING password AS STANDBY

6)       Execute the following command from serverOne

DB2 START HADR ON DATABASE serverOne AS PRIMARY

7)       Execute the following command from serverOne or serverTwo

DB2PD –DB serverOne -HADR

DB2PD –DB serverTwo -HADR

HADR Takeover:

The following command performs failover:

TAKEOVER HADR ON DATABASE database_name [BY FORCE]

Modes of takeover:

1)       Without the BY FORCE option, standby server and primary servers switch roles. (Current standby becomes new primary).

The standby server will send a message to tell the primary server to turn itself into a standby. The primary server will oblige by stopping in-flight transactions, sending over the last log buffer(s) to the standby, and turning itself into a standby. The initial standby server will wait for the final log buffers to arrive, apply them, and then turn itself into a primary server.

The client applications that were disconnected from the old primary will automatically reroute to this new primary and be connected. Then applications that were in-flight will be sent an error message telling them that they are still connected but their current transaction was rolled back. The proper response from an application (as with many error codes) would be to retry the transaction which will now succeed on the new primary server and the end user will be none the wiser.

If you do not use the BY FORCE option and the standby cannot contact the primary for any reason, then the takeover command will fail.

2)       With the BY FORCE option, the standby server itself turns its role to primary without coordinating any change of roles with the (current) primary server.