Gen EJBs and client-server security options
search cancel

Gen EJBs and client-server security options

book

Article ID: 277781

calendar_today

Updated On:

Products

Gen Gen - Run Time Distributed

Issue/Introduction

Is it possible to implement J2EE security roles for the Gen 8.6 deployed EJB .ear file 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?

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. For all communication types, the EJBRMISecurityExit is called again after the EJB has started but that is too late for the Web Services option.

Additional Information

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

  1. If this is something that 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.

  2. 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.   
    ===

  3. If using Web services as the communications middleware it is expected that SSL/TLS will be used to secure access to the EJB Web Services. However "Application Security" can also be implemented as follows:e.g. Gen GUI C client to 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.
    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. Per the options on the Client Security Processing page, the selection of Standard or Enhanced Security can be done in user exit WRSECTOKEN. See doc. page: WRSECTOKEN - Client Security Token User Exit (Windows)