SYSTEMS MANAGEMENT TIPS
Ensuring CICS security with the Web Services Security standard
Robert Crawford
11.21.2008
Rating: --- (out of 5)
One of the wonderful things about the World Wide Web is its almost anonymous openness, allowing browser clients to access remote servers all over the world. In the 1990s, however, the very openness of the Web threatened commerce, and the search for ways to securely exchange personal information began. The same is true for Web services, which promises to allow universal peer-to-peer communication without regard to the underlying system's structure. To address this need, the Web Services Security (WSS) Simple Object Access Protocol (SOAP) message standard was developed.
WSS provides a framework for three types of SOAP message security. It allows you to:
CICS supports all three WSS objectives. For authentication, CICS provides both basic and X.509.
CICS support of WSS authentication
As you may know, CICS Web services support includes the concept of a message pipeline. A message pipeline consists of a chain of programs invoked by CICS to process the inbound or outbound SOAP message. Every message processor has a turn at the message to either extract or insert XML.
The WSS standard specifies the proper XML tags for authentication. For CICS it becomes a matter of creating message handlers to manipulate the XML tags that the SOAP message is moving through the pipeline. For inbound messages, the handler must be able to retrieve the authentication information out of the SOAP header and perform the validation. For service requests, of course, a message handler must insert the security context into the header.
The CICS Web Services manual documents the requirements for writing your own message handlers. It may be simpler, however, to use an IBM-supplied, security-functional message handler such as DFHWSSE1. This tool does the work for you.
DFHWSSE1 can manage basic and X.509 authentication. Basic authentication utilizes a user token, usually consisting of a user ID and password, in the SOAP header. DFHWSSE1 retrieves the logon ID and pass
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
word and validates the pair with an external security manager, such as Resource Access Control Facility (RACF). If the verification works, the message gets passed on to the next message handler and the service provider transaction runs with the specified user context. If it doesn't work DFHWSSE1 tells CICS to return a SOAP fault.
As you might have guessed, X.509 is more involved. For inbound messages you must first import the requester's certificate into RACF as an Integrated Cryptographic Service Facility (ICSF) key. Then, attach the newly imported certificate to a keyring via the RACF RACDCERT (RACDigitalCertificate) command. For CICS' use the certificate's keyring must match the KEYRING parameter specified in the System Initialization Table (SIT). Also note the RACDCERT may optionally connect a logon ID to the certificate. CICS will use this ID as the security context for the Web service transaction. If a user ID isn't connected through RACDCERT, CICS uses the keyring's default ID.
Similarly, if you want to sign outbound messages, you must generate a certificate in RACF and attach it to the SIT keyring. Then you must import the certificate to the service provider's servers.
After the certificates are in place it becomes a matter of changing the pipeline configuration file for authentication. You may specify authentication options within the section, which is where you would include the name of a custom message handler. For DFHWSSE1, the particulars are sandwiched between tags within the section. Among the options are:
If done properly, DFHWSSE1 knows what to do and Web services security may be implemented without changes to the application. Even better, security remains at the system level and outside programmer control.
Note that DFHWSSE1 may also be used for message cryptography, also controlled through the pipeline configuration file. In this case, the XML must specify the encryption algorithm as well as the certificate or key to use. CICS can decrypt either parts of or the entire SOAP body. The only outbound option is to encrypt the entire body. The encryption and decryption message handler must be the first or last in the pipeline. This makes sense; inbound XML can't be processed until it is decrypted. It makes no sense to encrypt data that may be changed by a later handler.
Fortunately for us, CICS decided to support WSS to standard. The use of certificates makes the security stronger than dodges used for other protocols such as clear text logon IDs and passwords for TCP/IP. As always, the strength and type of security you choose depends on regulatory requirements and the trustworthiness of the communicating systems.
Do you agree with this tip? Do you have feedback to share? Contact Site Editor Matt Stansberry with your data center concerns.
|
|
|
|
|
|
