Invoke Remote EJB from different machine without authentication in wildfly 26

[Pankaj Kumar]

Hello,

We have multiple EJBs which is deployed on Wildfly 26. We want to invoke some of these EJBs without authentication from remote machine. For EJB invocation with authentication we are using authenticationContext with JAAS, but do not want to use this for open EJBs.

When we try this from same machine(wildfly and remote client) then it works well for both the EJBs(without authentication context and with authentication context) but when we configure same to Linux machine and try to invoke the open EJB without authentication it is throwing JBOSS-LOCAL-USER: javax.security.sasl.SaslException: ELY05128: Failed to read challenge file [Caused by java.io.FileNotFoundException: \home\jboss\standalone\tmp\auth\local1211839583212539848.challenge (The system cannot find the path specified)].

How to skip authentication for open EJBs to fix this issue?

Note: We don't want to put any security configuration in jboss-ejb3.xml

Thanks,

Pankaj K.

[Darran Lofthouse]

The authentication is actually not tied directly to the invocation, as the two servers establish a connection it is the connection which is authenticated.

When you are running on the same machine by default it is the JBOSS_LOCAL_USER authentication mechanism which is running to authenticate the connection so that is why it works for the co-hosted scenario.

For truly remote machines you would still need authentication otherwise anyone that can connect to the HTTP port of your server would be able to connect to any of the services managed using JBoss Remoting.

Assuming the default configuration is in use here the option would be to add a user to the application realm to represent the client server, then I assume you are using a remote outbound connection definition?  The outbound connection definition should then use an authentication context for the identity which represents the application server - this should all be possible at the subsystem level leaving your deployment untouched and unaware of this server level authentication.

Darran.

[Pankaj Kumar]

Hi Darran,

Thanks for your quick response!

I agree with your points.

Assuming the default configuration is in use here the option would be to add a user to the application realm to represent the client server, then I assume you are using a remote outbound connection definition?  The outbound connection definition should then use an authentication context for the identity which represents the application server - this should all be possible at the subsystem level leaving your deployment untouched and unaware of this server level authentication.

--> yes, we have added application realm user but when we invoke the Non authenticated EJBs it goes to JAAS authentication instead of applicationRealm to authenticate the connection. Here is the configuration

<subsystem xmlns="urn:jboss:domain:remoting:4.0">
            <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="my-application-sasl-authentication"/>
            <outbound-connections>
                <remote-outbound-connection name="ejb-outbound-connection" outbound-socket-binding-ref="ejb-outbound" authentication-context="ejb-outbound-context"/>
            </outbound-connections>
        </subsystem>

<sasl-authentication-factory name="my-application-sasl-authentication" sasl-server-factory="configured" security-domain="jaasSD">
                        <mechanism mechanism-name="JBOSS-LOCAL-USER" realm-mapper="local"/>
                        <mechanism mechanism-name="DIGEST-MD5">
                            <mechanism-realm realm-name="jaasRealm"/>
                        </mechanism>
                    </mechanism-configuration>

After this configuration, when we hit the non authenticated EJBs with application user credentials, it goes to JAAS authentication to authenticate the connection and fails. are we missing anything here?

can you suggest the right server configuration for application realm and Jaas realm working together?

Thanks,

Pankaj K.