The Wildfly client libraries (Naming client, EJB client and Transaction client) allow a user to access EJB beans deployed on Wildfly via the creation of client-side proxies.

These proxies can be created in two ways:

• using the Wildfly Naming Client to configure and use a JNDI context to look up a proxy
• using the EJB client API to create a proxy programmatically

In the case of remote clients, creating a proxy involves creating an authenticated, possibly encrypted, connection between the client and the server. This means that both approaches to creating proxies need to allow the user to configure authentication and encryption.

Elytron permits configuration of a wide range of security features, including authentication and encryption, via the definition of custom AuthenticationContexts. These contexts may be created programmatically or via a configuration file.

The Wildfly Client Configuration library provides a general purpose method of configuring all client libraries (naming, ejb-client, http-client, authentication-client, etc) via a wildfly-config.xml file.

It should be the case that a user could choose to configure authentication and encryption for a client application:

• using a pure JNDI approach, described here (c.f. [SSL and Custom Sockets|https://docs.oracle.com/javase%2Ftutorial%2F/jndi/ldap/ssl.html])
• using a pure Wildfly Client Configuration approach, by creating a custom AuthenticationContext.

In practice, a combination of both approaches is often used; a very common scenario is to create a JNDI context which specifies a PROVIDER_URL
and an INITIAL_CONTEXT_FACTORY on the one hand, and a wildfly-config.xml to provide user credentials and SSLContext on the other.

What I have found is that this combined approach allows configurations which result in incorrect behavior which are not flagged as exceptions, leading to a lot of debugging and wasted time on the part of the user.

Here is one example that I ran into:

• create a wildfly-config.xml which provides a valid authentication-configuration and a valid SSLContext for the client
• create a JNDI context specifying an INITIAL_CONTEXT_FACTORY and a PROVIDER_URL

This combined approach for configuring authentication and encryption works as expected. In other words, the user credentials and the SSL context from the wildfly-config.xml are used to establish an authenticated, encrypted connection

If we now add a SECURITY_PRINCIPAL and SECURITY_CREDENTIAL to the JNDI context, the combined approach does not work as expected. This configuration results in a variety of SSL handshake errors. A reproduce for this problem can be found by using the ejb-mutual-tls example from elytron-examples and adding in a principal and credential to the existing configuration.

This issue could be due to one of two things:

• programming error in implementing a supported combined approach for configuring authentication and encryption
• a non-supported combined approach which is not identified and handled by raising an exception for the user

In providing a solution to this issue, agreement is required on what are the supported combined approaches to configuring authentication and encryption for a Wildfly client application together with a JNDI naming context.