No J2EE security roles in deployed Gen EJB EAR file (WebSphere)
search cancel

No J2EE security roles in deployed Gen EJB EAR file (WebSphere)

book

Article ID: 277781

calendar_today

Updated On:

Products

Gen

Issue/Introduction

We would like to know how to implement 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.

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.
Gen Engineering confirmed that there is currently no support for automatically adding security role information into the Gen EAR XML descriptor file.

Resolution

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.

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 to include some default security roles in the scripts that create the XML descriptor and provide suggestions for the content of those defaulted roles. 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.   
===
NOTE: This is not possible if using EJB Web Services to connect a Gen C client to a Gen Java server EJB because EJBRMI is not used. It is expected that SSL/TLS will be used to secure access to the EJB Web Services.