[wildfly-dev] Preparation for requirements and capabilities.

[Darran Lofthouse]

On 25/03/15 15:34, Brian Stansberry wrote:
> On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>>
>>
>> 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?
>>
>
> Named capabilities.
>
> Examples where exclusivity is required:
>
> jacorb vs iiop-jdk, both providing IIOP capabilities
>
> web compatibility subsystem vs undertow, both providing various
> HTTP/servlet capabilities
>
> messaging vs the-new-one, both providing JMS

What I mean here is, my security realm would have both a name for the 
capability name e.g. org.wildfly.security.security_realm and a name for 
the instance, e.g. CorporateRealm.

For those examples if you don't have an instance name then yes I see 
exclusivity would be needed - those are following the lines of "I am the 
servers IIOP Provider"

>
>