[wildfly-dev] Preparation for requirements and capabilities.

Darran Lofthouse darran.lofthouse at jboss.com
Wed Mar 25 10:54:17 EDT 2015



On 25/03/15 14:44, Brian Stansberry wrote:
> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>> The case I have now is say the Elytron subsystem is installed and the
>> KeyCloak subsystem is installed - it is quite conceivable that both
>> would provide capabilities for
>> 'org.wildfly.extension.security.security-realm'
>>
>
> That's fine so long as they don't appear in the configuration in the
> same "context". Context meaning the same profile. A domain can have
> both, just not in the same profile. A standalone server of course only
> has one profile.

I am kind of thinking these would be the same profile, i.e. you could 
have security realms defined in Elytron used for one set of deployments 
and then KeyCloak could provide a realm used by a different deployment.

Although we may be able to find a way around this example if we step 
back from the realm.

The Elytron subsystem will be exposing SecurityDomains as a capability, 
strictly speaking it is these that secured resources will have a 
dependency on.

A SecurityDomain will reference one or more SecurityRealm instances.  So 
within the Elytron subsystem I need to be able to reference security 
realms defined within the Elytron subsystem - but also have the ability 
to reference security realms defined in other subsystems, but I also 
don't want the Elytron subsystem to need knowledge of the other 
subsystems beyond values that are set in the model.

This pattern could also repeat for KeyStore, KeyManager and TrustManager 
which are also ideal candidates for other subsystems to provide their 
own implementations of.



More information about the wildfly-dev mailing list