-
Enhancement
-
Resolution: Duplicate
-
Critical
-
17.0.0.Beta4
-
None
-
undefined
I am flagging as an Enhancement as this will be new functionality but it is for an internal purpose - ideally end users should be unaware of it's existance.
Managed servers in a domain connect back to their host controller using the same management interface as is used to actually manage the server.
By default they use the JBOSS_LOCAL_USER mechanism, for legacy security realms if this mechanism is removed the server process was also passed a secret which could be used for username / password authentication - we then had a mechanism in place to insert this into a virtual domain which was created for the legacy reams.
We do not have this option for fully defined Elytron domains as they are defined in advance.
Reproducer
Once the management interfaces of a host controller are updated to use Elytron authentication factories disable local authentication with the following command:
/host=master/subsystem=elytron/sasl-authentication-factory=management-sasl-authentication:write-attribute(name=mechanism-configurations, value=[{mechanism-name=DIGEST-MD5, mechanism-realm-configurations=[{realm-name=ManagementRealm}]}])
Note: To connect using the CLI again a user will also need to be defined.
Rather than try and retrofit the old approach I think it is time to consider a new option.
1 - Bearer Token Authentication
As we already generate a secret and pass it to the client we could generate a full token. The managed server can then authenticate using the BEARER SASL mechanism.
Architecturally it should be easier to add a SASL mechanism to the supported mechanisms than intercept authentication for different mechanisms.
2 - JBOSS_SERVER Mechanism
The problem with option #1 is what happens once they enable BEARER authentication themselves, we are back at having a mechanism with mixed use - it may be cleaner to add a new mechanism JBOSS_SERVER - this will be a simple mechanism which can receive a token and validate it is from a managed server.
Combined with this it might be cleaner is JBoss Remoting could avoid advertising this internal mechanism in the challenge to clients although probably not a problem if it does as other clients would not recognise it. If it is not advertised we would also need a way for a Remoting client to force the use of a non advertised mechanism although this section could likely be an optional follow up later.