Wildfly SSLContext in domain mode

[bshorty]

Hi,

this should probably be an easy one to answer, but am struggling to find any documentation that does.

Having migrated configuration for a standalone setup to use the Elytron SSLContext for HTTPS given that the security-realm attribute of HTTPS listeners is marked as deprecated (and has been for some time) I was eager to do the same for a clustered domain configuration.

Attempting to do so informs me that the SSLContext capability simply isn't available on the listener when trying to set it on the domain controller for any profile. I have hunted around for something that explains why this is the case, but can't find anything.

I would really like to move away from the legacy security realm configuration and unify our approach so that both standalone and domain modes use Elytron, the new key-store configuration, and SSLContexts for HTTPS. Is there something I have missed, is this possible - or if not, why is this the case for domain mode, is this something that is to be added at a later date (especially as Wildfly itself emits warnings about the use of security-realm when using this configuration).

Many thanks to anyone who can shed some light on this.

Cheers!

[dlofthouse]

For this capability you will need to be defining an SSLContext within the Elytron subsystem, this in turn depends on key and trust managers and key stores as required to assemble a full configuration.

One thing to be aware of now is that the Elytron subsystem lives in two locations: -

1. The host.xml
2. Within profiles in the domain.xml

For other resources defined in the host.xml you should define the SSLContext within the subsystem definition also in the host.xml.

e.g For Management interfaces.

For resources defined in a domain.xml profile you should define the SSLContext within the subsystem definition within that profile.

e.g. For Undertow HTTPS listener

[bshorty]

Hey Darran,

thank you very much for the response. Given the previous requirement that you had to define the security-realm on the host side, but the https-listener on the domain side when doing this for domain mode, I had automatically done down that same road.

Having defined the SSLContext, key-store, and key-manager in the elytron subsystem in the host configuration, when attempting to set the SSLContext for the https-listener on the domain profile side I got an error about the capability to do this not being present which threw me - I was expecting an error about not finding the context if anything. It seemed to indicate it simply wasn't possible, rather than it being a case of needing dependant components defined first.

Having now realised they elytron subsystem exists both on the host and in the profile as you say, and adjusted my understanding I have worked out where I was going wrong. I was actually wanting to add the SSLContext to an https-listener in the load-balancer profile, which by default does not have the elytron subsystem at all. I have now worked out that if I add the elytron subsystem to the load-balancer profile, add the key-store to that, and then set the SSLContext on the listener everything works!

So the main confusion was I needed to do this before I started anything else:

/profile=load-balancer/subsystem=elytron:add(disallowed-providers=[OracleUcrypto])
/profile=load-balancer/subsystem=elytron/provider-loader=elytron:add(module=org.wildfly.security.elytron)
/profile=load-balancer/subsystem=elytron:write-attribute(name=final-providers,value=elytron)
/profile=load-balancer/subsystem=elytron/file-audit-log=local-audit:add(path=audit.log,relative-to=jboss.server.log.dir,format=JSON)
/profile=load-balancer/subsystem=elytron/provider-http-server-mechanism-factory=global:add(providers=elytron)

Is there something in the documentation that points this out as I didn't see it, definitely something worth considering highlighting if not as feels like a case of 'obvious when you know'

Cheers for the help!