[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

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...


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat