Gen EJB/EJB Web Service and client/server security options

Products

• Gen
• Gen - Run Time Distributed

Issue/Introduction

What options are available for using client/server security to a Gen EJB or EJB Web Service.

Environment

Gen 8.6 EJB/EJB Web Service

Resolution

EJBRMI

If using EJBRMI as the communications middleware i.e. Gen Java client to Gen Java server EJB, it is possible to use the EJBRMI user exits to enable J2EE security:
EJBRMIContextExit - Web Generation EJB RMI Context Exit
EJBRMISecurityExit - Web Generation EJB RMI Security Exit
===
In J2EE security, access to a specific EJB is controlled by the Principal/Credential supplied by the client (initially provided by the manager of the server.)
The context of an EJB is a set of properties that are provided at runtime. Method System.getProperty("NAME") looks up a property NAME on the system properties list.
If it returns null or blank, that indicates that those properties have not been defined or have no value.
The spelling of the property names is important only because it matches whatever properties have been defined for the application server.
The Gen runtime invokes EJBRMIContextExit before creating an initial context for the EJB instance. It contains example code for property names "SECURITY_PRINCIPAL" and "SECURITY_CREDENTIALS".
The EJBRMISecurityExit is called after the InitialContext() is established.
These exits are available on both client and server side, so values can be set on the client side and retrieved on the server side.
The EJBRMISecurityExit shows how the user id and password might be incorporated into the runtime object, to be available for the server to verify. It might be required to translate specific userid/passwords at the client level into roles that could be used with standard J2EE security.   
===
NOTE:
This is only valid when using EJBRMI communications where the EJBRMISecurityExit and the EJBRMIContextExit user exits are both called prior to the EJB starting.
However that does not occur when using Web Services communication to an EJB Web Service. For all communication types, the EJBRMISecurityExit is called again after the EJB has started but that is too late for the Web Services option.

EJB WEB SERVICES

If the Java server has been generated with TP Monitor = "EJB Web Services" rather just "EJB" then it is possible to call the EJB as a web service for which there are currently these options:

1. Use the Gen client/server Web Services coopflow where "Application Security" can be implemented as follows:
   For example for the scenario of a Gen GUI C client calling a Gen Java Server EJB:
   1. The Gen C client application provides a way to get the end-user's credentials.
      
      
   2. The Gen C client application could then set the CLIENT_USER_ID and CLIENT_PASSWORD system attributes with the end-user's credentials.
      
      
   3. If the Gen C client uses Standard or Enhanced Security, then the CLIENT_USER_ID and CLIENT_PASSWORD system attributes will be sent to the EJB.
      NOTES:
      i .For the Gen Web Services Coopflow, the documented CFB Header limitation on page WRSECTOKEN - Client Security Token User Exit (Windows) does not apply. The Web Services Coopflow sends a SOAP message that matches the EJB Web Service's WSDL, so all 64 bytes of the CLIENT_USER_ID and CLIENT_PASSWORD system attributes are available. As long as either SecurityUsedStandard or SecurityUsedEnhanced is used in WRSECTOKEN, those system attributes will be sent to the EJB when using the Web Services Coopflow.
      ii. Use of a security token in WRSECTOKEN is not supported for EJB Web Services per article: Is a security token supported for Gen Web Services cooperative flow
      
      
   4. In the EJB's Procedure Step code, a user-written Action Block could be called to authenticate the end-user's credentials and verify they have permission to execute the EJB. This Action Block would need to be added to every EJB's Procedure Step code.
      
      
   5. Doc. reference: Security in Distributed Processing
      
      
      
2. SSL (https) and custom SOAP header are now supported for Web Services Coopflow GUI clients under the C runtime e.g. Windows PTF RTN86321/LU14790 ("Add support for https and custom SOAP header with client userid and password using user exit for web service flow") for GUI C, COM Proxy and C Proxy clients.
   There are also related UNIX PTFs for C proxy clients (see Gen 8.6 Solutions & Patches for details).
   NOTE: There is no equivalent server-side support for SSL (https) or custom SOAP header so their server-side processing has to be worked out by the user.
   
   
   
3. Use the CALL EXTERNAL statement to call the EJB Web Service where an SSL option is supported - Consume a Secure Web Service.

Additional Information

Also see article: Using J2EE security roles in a deployed Gen EJB EAR file (WebSphere)