EAP 7: Server-to-server remote EJB & Elytron config

the current JBoss EAP and even WildFly docs describe the configuration to enable server-to-server remote EJB calls only with the legacy security subsystem in mind, see especially

https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html/developing_jakarta_enterprise_beans_applications/clustered_jakarta_enterprise_beans#remote_clients_on_another_instance

https://docs.wildfly.org/26.1/Developer_Guide.html#packaging-the-client-application-on-the-client-server

These scenarios make use of jboss-ejb-client.xml which looks like:

<jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd">
  <client-context>
    <ejb-receivers>
      <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" />
      <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" />
    </ejb-receivers>

    <clusters>
      <cluster name="ejb" security-realm="ejb-security-realm-1" username="quickuser1">
        <connection-creation-options>
          <property name="org.xnio.Options.SSL_ENABLED" value="false" />
          <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />
        </connection-creation-options>
      </cluster>
    </clusters>
  </client-context>
</jboss-ejb-client>

As you can see, it makes use of the security-realm and username elements which are used by the legacy security subsystem.

When one wants to use Elytron instead, the configuration should be somehow different, but this isn't documented anywhere, not even in the migration guides. Only standalone client configuration with wildfly-config.xml is covered there.

What is the server-to-server config supposed to look like at the client side?

So far I've found only this 5 years old article: https://developer.jboss.org/people/fjuma/blog/2017/09/08/getting-started-with-ejbs-and-elytron-part-2 which might be the closest to it, but there are few things that I'm not sure about, for example the absence of any cluster-related client-side config and any separation of multiple connections (to multiple clusters) which is known to cause performance issues if not configured properly (different cluster names need to be configured for each). It may be fine when using Elytron due to different implementation being used, but in any case it's completely missing in the docs so currently it's more a trial & error sort of thing.

yes you can add authentication context as described in the blog post you found.

Authentication context can have rules configured in it where you can specify which authentication configuration to use when https://docs.wildfly.org/26/wildscribe/subsystem/elytron/authentication-context/index.html . These match rules can be used to configure different configs for different pots, hostnames, paths protocols etc.

You can create an issue in the jira https://issues.redhat.com/projects/ELY/issues to enhance the documention or migration documentation