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

Products

• Gen
• Gen - Run Time Distributed

Issue/Introduction

Is it possible to implement J2EE security roles for a Gen 8.6 EJB/EJB Web Service deployed in WebSphere 9.0.5?

For deployed Gen EJBs the expected Detail Properties option "Security role to user/group mapping" is not visible/missing, so do Gen EJBs not support J2EE role-based security?


WebSphere Application Server 9.0.5 doc. page references:
Security role references in web applications
Security role to user or group mapping

Environment

Gen 8.6 EJB EAR files
WebSphere Application Server 9.0.5

Cause

Support checked their example Gen EJB deployments on WebSphere 9.0.5.10 and for Detail Properties, the option "Security role to user/group mapping" is always missing.
Gen EJB EAR files have XML descriptor files (e.g. ejb-jar.xml) that do not contain security role tags to enable securing of the EJBs on the deployed Application Server (J2EE authorization). That explains why the option "Security role to user/group mapping" is not visible.

Resolution

Gen Engineering confirmed that there is currently no support for adding security role information into the Gen EAR XML descriptor file.
The only option would be to manually modify the XML descriptor within the EAR file to provide the required security roles.
Potentially the relevant Build Tool Assemble script in the directory "%Gen86%\Gen\bt\scripts" could be customized to automate that process.

• The main assemble script is deploy_ear.scr which customizes the ejb-jar.xml file that is initially created during the build step (directory model_name.ief\java\S1\META-INF) for inclusion into the EAR file.
• For WebSphere, deploy_ear.scr calls other scripts deploy_ear_websphere_ejb.scr (EJB) , deploy_ear_websphere_ejbws.scr and deploy_ear_websphere_wsd.scr (EJB Web Services) to create additional XML descriptor files.

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.

If this feature is considered important for Gen to do out of the box, then the advice would be to create an Idea on the Ideas Community (Category=Gen) to request an enhancement for Gen. That Idea could then be voted on by other Gen users.

Additional Information

If using EJBRMI as the communications middleware i.e. Gen Java client to Gen Java server EJB, it is also 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_CRENDENTIALS".
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.   
===

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 2 options:

1. Use the Gen client/server Web Services coopflow where "Application Security" can be implemented e.g. as follows 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.
      NOTE: 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.
      
      
   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. Use the CALL EXTERNAL statement to call the EJB Web Service where an SSL option is supported - Consume a Secure Web Service.