Help needed on Migrating EJB3 legacy security to Elytron security

[Arulkumar Ponnusamy]

Hi ,

Currently, we are in the process of migrating the EJB3 subsystem to Elytron security. we are using Wildfly 24 and we do not enforce any Roles restriction for accessing the EJB and we want it the same after migration to elytron too. 

Tried to follow this 

https://github.com/wildfly/quickstart/tree/main/ejb-security

But, it is asking to create users and corresponding roles which we don't want to do.

So, is it possible to allow the application to authenticate instead of wildfly? and allow roles also for all once authenticated?

my current configuration

        <subsystem xmlns="urn:jboss:domain:ejb3:9.0">

            ........

            <default-security-domain value="other"/>

            <application-security-domains>

                <application-security-domain name="other" security-domain="ApplicationDomain"/>

            </application-security-domains>

            <default-missing-method-permissions-deny-access value="true"/>

           ...........................

        </subsystem>

        <subsystem xmlns="urn:jboss:domain:remoting:4.0">

            <http-connector name="http-remoting-connector" connector-ref="remotinghttpslistener" sasl-authentication-factory="application-sasl-authentication"/>

        </subsystem>

any guide/reference on this ?

[Darran Lofthouse]

I am not following the questions here, where does the need for the application to handle authentication come from?  From your original sentence it sounds like you just don't assign roles to users - that should still be possible with an Elytron configuration.  The quickstart you references just uses roles as it is very common for EJB deployments to use role based permissions and it doesn't make sense to have two quickstarts one with and one without.

[Arulkumar Ponnusamy]

Hi Darran,

Thanks for quick response.  To give some background about our application, we use the default security domain "other" and uses a customized login module which extents javax.security.auth.spi.LoginModule  for authentication. The principal propagated using the Picketbox "SecurityContextAssociation". 

After Elytron migration, the problem comes, when the remote client(different JVM) trying to accessing the EJB. my sample client code is like this,

try{
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
jndiProperties.put(Context.PROVIDER_URL, "http-remoting://localhost:1099");
jndiProperties.put(Context.SECURITY_PRINCIPAL, "username");
jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");
final Context context = new InitialContext(jndiProperties);
ChangeDetectionRemote ch = (ChangeDetectionRemote)context.lookup(EjbNames.getRemoteJndiLookupName(EjbNames.ChangeDetection));
System.out.println(ch.getChangeDetectionStateMessage());
}catch (Exception e){
e.printStackTrace();
}

The client code works only if I add user into the property files. if the user is not available then, getting the below error

Suppressed: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication

at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:736)

at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:578)

at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)

at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)

at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)

I don't want to add user credentials in properties files. 

not sure, do we really needs to use custom realm .  My understanding is that, the Elytron ApplicationDomain is equivalent of legacy security domain "other"

[Darran Lofthouse]

So the error you are reporting is just at the point where the connection is being established using the remoting connector.

Prior to moving to the sasl-authentication-factory which security realm was the remoting connector referencing?  Was this security realm a default configuration or also referencing the "other" jaas security domain?

[Arulkumar Ponnusamy]

Prior to moving to the sasl-authentication-factory, our remoting configuration is like below

        <subsystem xmlns="urn:jboss:domain:remoting:4.0">

            <http-connector connector-ref="remotinghttpslistener" name="http-remoting-connector"/>

        </subsystem>

and the http-connector is like below

   <http-listener enable-http2="true" max-parameters="${abcd.maxParameters:200000}" max-post-size="${abcd.maxPostSize:4294967296}" name="remotinghttpslistener" socket-binding="httpremotingbinding"/>

and my http remotingbinding is like below

<socket-binding name="httpremotingbinding" port="${abcd.remoting.http.port:1099}"/>

[Darran Lofthouse]

Your old configuration means you have completely disabled any authentication for clients connecting using JBoss Remoting, once these clients have connected they will be able to access all services such as EJBs, Naming, and Transactions.  Also if the JMX subsystem has been changed management of the server might be accessible as well.

Was this the intent with your configuration?

[Arulkumar Ponnusamy]

oh.. Definitely not!!.. our intention is that to refer the security domain "other" and then authenticate via our JAAS Module.

[Darran Lofthouse]

So for the older configuration (Prior to WildFly 25) the way you would achieve this is to define a legacy security realm, for authentication it is possible to specify jaas and from here reference the "other" security domain.  The remoting connector should then reference this newly defined security realm - authentication would then occur by delegating to the security realm definition.

For WildFly Elytron this equivalent behaviour would presently need to be implemented in a custom security realm, I think you have been on some other threads where we are working to add an integration with custom login modules but that is not yet available.  At the moment in the default Elytron configuration the ApplicationDomain references a security realm which is backed by the properties file, this can be swapped out by a reference to a custom realm.  At that point the SASL authentication will likely need switching to use PLAIN rather than DIGEST but that will be a second step - the first would be the custom realm.

[Arulkumar Ponnusamy]

Thanks Darran for the suggestion. As part of wildfly-elytron, i see a JaasSecurityRealm implementation class which seems to be fitting into my use cases(as per the test cases). any idea, why this is not documented in elytron-migration guides?

[Darran Lofthouse]

That realm is not documented as it is not presently exposed via the subsystem model.  Work is underway hopefully for WildFly 26 to provide an alternative.