Tito Paiva recently published a tutorial on the developerWorks Recipes site. The tutorial shows how to provide the identity of the end-user of Java EE applications that are running on WebSphere Liberty and calling CICS programs using WebSphere Optimized Local Adapters (WOLA). Here, he summarises the problem that he’s addressing in the tutorial.


By Tito Paiva

WOLA enables local and bidirectional communication between a Liberty (or WebSphere Application Server traditional) server and processes in z/OS, which can be batch jobs, IMS, or CICS servers. A Java EE application can access a z/OS native application, or be accessed by it, provided that both run on the same partition (LPAR).

The identity problem

Back-end system access from Java Enterprise applications is usually made by using a service (or generic) user, whose ID and password are configured in the connection factory object and passed by the software when establishing the connection. The following diagram shows an example with CICS:


tito

When Elisa or Carlos (in the diagram) uses the Java application in WAS, they are required to authenticate. In this example, Liberty is configured to perform authentication on an LDAP server (Lightweight Directory Access Protocol). Then the Java application calls a CICS program but the user’s identity that the CICS application runs under is the generic user (GENUSER in the diagram), no matter who is the actual user.

This way is simple and efficient because the same connection can be used in successive transactions by different users without having to authenticate again. On the other hand, we lose tracking. Database updates, messages sent, log messages, or any other actions taken by the CICS program will not carry the identities of real users.

In a Liberty server using WOLA, the relevant server.xml settings would look like this:

<connectionFactory jndiName="eis/legacy" containerAuthDataRef="olaauth">
 	<properties.ola  RegisterName="OLASERVER”/>
</connectionFactory>
<authData id="olaauth" user="genuser" password="{xor}Lz4sLCgwLTtt" />
  • genuser is a user ID on the z/OS security system authorized to access business logic in CICS, a COBOL program for example.
  • genuser‘s password is encoded just to avoid accidental exposure. It is not a cryptographic protection and it is easily reversed.
  • OLASERVER represents the CICS server.

In addition, the configuration file must be protected, even from reading. Its exposure opens the door to several transactions in CICS environment. Even protected, though, the infrastructure personnel will always have access to this information.

Using identity assertion

To avoid these problems, application servers like Liberty support identity assertion. Identity assertion tells the partner system which identity is to be used, without any password checking. For remote systems, this requires secure communication and certificate authentication. As WOLA is local, no communication security concerns apply.

The tutorial discusses three ways of implementing identity assertion. It then shows how to implement a simple Java EE application with identity assertion that you can run and test.

Join The Discussion

Your email address will not be published. Required fields are marked *