As a transaction manager, CICS offers excellent support of security and dynamic workload management for traditional applications. The default solution is, however, a little awkward for CICS Web services providers.
Web service provider transaction
By default, incoming Web services requests run under utility transaction CPIH. This is fine for a basic implementation, but it tends to hinder other useful facilities such as dynamic transaction routing and security, and it makes chargeback difficult as well.
There are a couple of ways to specify a transaction for inbound Web requests. First, use CICS' Web services assistant DFHWS2LS to specify the transaction for Web services requests. Thus, when CICS matches an incoming Uniform Resource Identifier (URI) to a Web service, it starts the transaction name it finds in the Web service's bind file. Specifying the transaction ID in the bind file has the advantage of being simple and avoids writing message handlers. The bad ...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
news is all the transactions for that Web services will run under CICS' default user ID (specified in System Initialization Table parameter DFLTUSER), which short circuits individual accountability and auditing.
Alternatively, you can write your own message handler and change the Web service's pipeline to invoke it. Thus, CICS invokes the message handler, which decides on a new transaction code and updates container DFHWS-TRANID with the new transaction name. When the message handler returns, CICS sees the changed DFHWS-TRANID, then starts a new task under the transaction name to complete the processing.
The message handler option has a lot of downsides. Not only does someone have to write the code, but he or she must update the pipeline's configuration file to call the program. It also doesn't get around the problem of running an application transaction under the default user ID. The chief advantage is that the transaction ID can be chosen at run time instead of being hard coded.
Web service security
It wouldn't be the mainframe or CICS without security. Out of the box, CICS supports several different levels of Web services security, from basic auth to signed certificates. Even better, all a shop has to do enable security is alter the pipeline's configuration file to denote the authentication type. CICS takes care of the rest by validating the credentials and starting a new task running in the proper security context.
On the surface this is a great thing, but looking a little deeper reveals some odd bits. For instance, using the default Web services transaction means that everyone in the enterprise, including customers, needs access to transaction CPIH. This is not good if you use transaction name-based security -- it leaves you with the alternative of using resource-level security to keep people out of files or databases they shouldn't be touching. If an installation specifies the transaction ID in the bind file or message handler, it still means the application transaction must run under the default user ID until CICS manages to authenticate the security credentials, which defeats the purpose.
Two Birds with One Stone
A third option is to code a message handler for both security checking and changing the transaction ID. In this scheme, an incoming Web request starts under transaction CPIH until it gets to the custom message handler. At that point, the message handler retrieves and authenticates the security credentials in the Simple Object Access Protocol (SOAP) message header. If that goes well, it then decides which transaction ID the rest of the pipeline should run under. Ultimately, the message handler updates the user ID (DFHWS-USERID) and the transaction ID (DFHWS-TRANID) containers and returns. CICS notices the updated containers and helpfully starts a new task under the new transaction ID with the proper security context.
This approach serves security well in several of ways. First, the default user ID need only be authorized to run CPIH. Conversely, the default user ID doesn't need access to the second transaction because the message handler asks CICS to start it with user credentials. Finally, the transaction runs under a user context maintaining individual accountability.
In addition, this way allows for the most freedom in choosing a new transaction ID. Instead of a hard-coded transaction ID, the message handler will be able to pick one based on such things as the authenticated user ID, the source IP address or Web services name. The differentiated transaction code also comes in handy for dynamic workload balancing and routing.
Of course, this isn't without risk or pitfalls. Anyone who's looked at eXtesible Markup Language, or XML, messages understands how verbose and arcane they can be. Parsing SOAP messages is not trivial, as a program must look for the beginning and ending tags bracketing each value and carefully calculate the length of each.
Authenticating the security credentials is no picnic either. Basic authority with a user token consisting of an ID and password is easy enough to do with the EXEC CICS VERIFY PASSWORD command. More advanced methods, such as encryption or signed certificates, may get hairy and involve calls to cryptographic services. Invoking a trust client may be a little easier, as CICS provides a utility program that a message handler can link to for contacting the security server.
Next month I'll go into a little more detail about writing a custom message handler for this purpose.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
