BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
JAM Documentation | JAM Reference Guide | Previous Topic | Next Topic | Contents | Index

Security

BEA WebLogic Java Adapter for Mainframe (JAM) supports the basic Application Program-to-Program Communication (APPC) style of sign-on security. You can configure a gateway to use one of three types of sign-on security for each link that is defined. The security options are defined in the JC_LINKS section of the jcrmgw.cfg file. Refer to the BEA WebLogic Java Adapter for Mainframe Configuration and Administration Guide for more information. The selected level of security determines which combination of user ID and password is used for transactions across the link.

Supported Security Options

JAM supports the following security options:

- LOCAL

All security is handled by the local system and the link itself has no security requirement.

- IDENTIFY

A user ID is passed to the mainframe. This user ID can originate with the client application or it can be a default user ID supplied at Java gateway startup by the -u option.

- VERIFY

A user ID and password are passed to the mainframe. The user ID can originate with the client application or it can be a default user ID supplied at Java gateway startup by the -u option. The password must be supplied by the client application.

Note: For more information about the startup class, refer to the "Configuring the Gateway" section of the BEA WebLogic Java Adapter for Mainframe Configuration and Administration Guide.

In addition, an alternate mirror transaction is supported on each Distributed Program Link (DPL). The mirror transaction can be used to associate different Resource Access Control Facility (RACF) profiles with different services.

Refer to IBM RACF documentation for more specific information about establishing and administrating mainframe security.

Controlling User IDs and Passwords through Business Logic or Client Classes

User IDs and passwords used for mainframe requests can be controlled from business logic within client EJBs or from normal client classes. In order for this security credential control to work, you must have your gateway security level set to VERIFY.

Note: Following are the limitations of JAM security credential control:

- Individual control of security credentials from servlets that directly invoke services is not available.

- Encryption of the TCP/IP link between the WebLogic server and the CRM is not supported. Passwords are passed as clear text.

- Encryption of the SNA link between the CRM and the mainframe is not supported. Passwords are passed as clear text.

- Secure requests from the mainframe are not supported.

Controlling Security Credentials from Client EJB Code

Business logic within client EJB code can be used to control the security credentials used for mainframe requests. Client EJB implementations generated by eGen COBOL provide two routines, setUserid() and setPassword(), to adjust the user ID and password parameters.

The following listings are based upon the samples provided with JAM. They demonstrate the use of the setUserid() and setPassword() routines.

Listing 4-1 shows an eGen COBOL script used to generate a client EJB.

Listing 4-1 eGen COBOL Script to Generate a Client EJB

>     #-------------------------------------------------------------------------
>     # empclient.egen
>     # JAM script for a client EJB application.
>     #
>     # $Id: empclient.egen,v 1.1 2000/01/21 22:02:40  Exp $
>     #-------------------------------------------------------------------------

>     # Dataviews (typed data records)

>     view sample.EmployeeRecord from emprec.cpy

>     # Services

>     service sampleCreate
>         accepts EmployeeRecord returns EmployeeRecord

>     service sampleRead
>         accepts EmployeeRecord returns EmployeeRecord

>     service sampleUpdate
>         accepts EmployeeRecord returns EmployeeRecord

>     service sampleDelete
>         accepts EmployeeRecord returns EmployeeRecord

>     # Clients and servers

>     client ejb sample.SampleClient my.sampleBean
>     {
>         method newEmployee
>             is service sampleCreate

>         method readEmployee
>             is service sampleRead

>         method updateEmployee
>             is service sampleUpdate

>         method deleteEmployee
>             is service sampleDelete
>     }

When this script is passed to eGen COBOL, several files are generated, one of which is SampleClientBean.java, the EJB implementation. Listing 4-2 shows an example of this file.

Listing 4-2 Example of SampleClientBean.java File

>     // SampleClientBean.java
>     //
>     // EJB generated by EgenCobol on Dec 6, 2000.
>     //

>     package sample;

>     // Imports
>     //
>     import java.io.IOException;
>     import com.bea.jam.egen.EgenClientBean;
>     import com.bea.sna.jcrmgw.snaException;
>     import com.bea.base.io.MainframeWriter;
>     import com.bea.base.io.MainframeReader;

>     /**
>      * EJB implementation.
>      */
>     public class SampleClientBean extends EgenClientBean
>     {
>         // deleteEmployee
>         //
>         public sample.EmployeeRecord deleteEmployee(sample.EmployeeRecord commarea)
>             throws IOException, snaException
>         {
>             // Make the remote call.
>             //
>             byte[] inputBuffer = commarea.toByteArray(new MainframeWriter());
>             byte[] rawResult = callService("sampleDelete", inputBuffer);
>             sample.EmployeeRecord result =
>                  new sample.EmployeeRecord(new MainframeReader(rawResult));
>             return result;
>         }

>         // updateEmployee
>         //
>         public sample.EmployeeRecord updateEmployee(sample.EmployeeRecord commarea)
>             throws IOException, snaException
>         {
>             // Make the remote call.
>             //
>             byte[] inputBuffer = commarea.toByteArray(new MainframeWriter());
>             byte[] rawResult = callService("sampleUpdate", inputBuffer);
>             sample.EmployeeRecord result =
>                  new sample.EmployeeRecord(new MainframeReader(rawResult));
>             return result;
>         }

>         // readEmployee
>         //
>         public sample.EmployeeRecord readEmployee(sample.EmployeeRecord commarea)
>             throws IOException, snaException
>         {
>             // Make the remote call.
>             //
>             byte[] inputBuffer = commarea.toByteArray(new MainframeWriter());
>             byte[] rawResult = callService("sampleRead", inputBuffer);
>             sample.EmployeeRecord result =
>                  new sample.EmployeeRecord(new MainframeReader(rawResult));
>             return result;
>         }

>         // newEmployee
>         //
>         public sample.EmployeeRecord newEmployee(sample.EmployeeRecord commarea)
>             throws IOException, snaException
>         {
>             // Make the remote call.
>             //
>             byte[] inputBuffer = commarea.toByteArray(new MainframeWriter());
>             byte[] rawResult = callService("sampleCreate", inputBuffer);
>             sample.EmployeeRecord result =
>                  new sample.EmployeeRecord(new MainframeReader(rawResult));
>             return result;
>         }
>     }

>     // END SampleClientBean.java

Note that the four service routines all invoke the callService method to perform their work. Listing 4-3 illustrates a class that extends the generated EJB implementation to provide security credentials to the gateway during these operations.

Listing 4-3 Example of Class with Security Credentials

>     // ExtClientBean.java
>     //

>     package sample;

>     // Imports
>     //
>     import java.io.IOException;
>     import com.bea.sna.jcrmgw.snaException;

>     /**
>      * EJB implementation.
>      */
>     public class ExtClientBean extends SampleClientBean
>     {
>         protected byte[] callService(String svc, byte[] input)
>                 throws snaException, IOException
>         {
>                 setUserid("JAMUSER");
>                 setPassword("JAMPASS");

>                 return super.callService(svc, input);
>         }
>     }

>     // END ExtClientBean.java

In order to deploy the extended EJB, the XML deployment descriptor must be edited to modify the ejb-class field. Listing 4-4 illustrates this file with the class name that must be changed marked in bold.

Listing 4-4 Extended EJB with Modified XML Deployment Descriptor

>     <?xml version="1.0"?>
>     <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
>     <ejb-jar>
>         <enterprise-beans>
>           <session>
>             <ejb-name>SampleClient</ejb-name>
>             <home>sample.SampleClientHome</home>
>             <remote>sample.SampleClient</remote>
>             <ejb-class>sample.ExtClientBean</ejb-class>
>             <session-type>Stateless</session-type>
>             <transaction-type>Container</transaction-type>
>           </session>
>         </enterprise-beans>
>         <assembly-descriptor>
>           <container-transaction>
>        <method>
>          <ejb-name>SampleClient</ejb-name>
>          <method-intf>Remote</method-intf>
>          <method-name>*</method-name>
>        </method>
>        <trans-attribute>NotSupported</trans-attribute>
>           </container-transaction>
>         </assembly-descriptor>
>     </ejb-jar>

Controlling Security Credentials from Client Class Code

Client classes generated by eGen COBOL may be extended to specify security credentials used for requests. The parent class for generated client code provides setUserid() and setPassword() routines with the same signatures as those in the EJB model. These may be extended in the same manner. Refer to Controlling Security Credentials from Client EJB Code for examples of the EJB model code.

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.