Re: [wildfly-dev] Preparation for requirements and capabilities.

On 3/25/15 9:54 AM, Darran Lofthouse wrote: > > 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. > Hmm, so some sort of non-exclusive capability thing. Or some way that a capability can declare the context in which it must be exclusive, one option being "NONE".

Just brainstorming here...