Access to SecurityDomain object in user defined modules

[kumaran L]

I have a use case where I have to invoke an EJB with escalated privilege from a JAAS login module. I have created a separate module for these JAAS login modules classes. At runtime, I see that SecurityDomain.getCurrent() returns null and hence I cannot create a SecuirtyIdentity. Also, even if I manage to create a  SecurityDomain and create a  SecuirtyIdentity, it doesn't get propagated to EJB and EJB call fails eventually. Also, I noticed that SecurityDomain is registered only for the class loaders of deployed ears and wars based on elytron configuration. Our use case is to deploy only one application in wildfly and have a common elytron security domain for the entire application.

Is there a way to access this common security domain in user defined modules?

Regards,

Kumaran   

[Diana Krepinska]

Hello Kumaran,

Regarding the first point about accessing the current SecurityDomain object from the custom JAAS login modules, can you please create a jira issue https://issues.redhat.com/projects/ELY/issues for it ? Thanks!

About the propagation of securityIdentity to EJBs, are you using the runAs methods for the call?

[kumaran L]

Hi Diana, 

Thanks for the reply. As suggested, I have created a jira issue (https://issues.redhat.com/browse/ELY-2588). Regarding securityIdentity propagation to EJB, I tried both authenticate and runas both didn't work when you invoke EJB from from a context classloader other than that of ear, ejb-jar and war. Wildfly module containing JAAS custom login class is one such example where the context classloader will be that of the module. 

Regards,

Kumaran

[Diana Krepinska]

Hi,

Thank you for creating this topic. However, after some discussion, this issue may be closed. The reason for this is that the same jaas-realm definition can be configured for different security domains. And a single jaas realm should not work with different security domains depending on which deployment is using it. 

About the securityIdentity propagation to EJB - since the JAAS realm runs in the management space of the application server and not in a scope of the deployment, it should be done the same way as any other EJB client would do it. So the module that contains the custom LoginModule implementations can have a dependency on the remote interface of that EJB and do the remote invocation