[wildfly-dev] Preparation for requirements and capabilities.

Darran Lofthouse darran.lofthouse at jboss.com
Wed Mar 25 11:28:19 EDT 2015



On 25/03/15 15:00, Brian Stansberry wrote:
> 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".

For the capabilities we are talking about at the moment we are really 
talking about named capabilities or model references - for these do we 
have examples where exclusivity would be required?

> Just brainstorming here...
>
>



More information about the wildfly-dev mailing list