Why not use optional capabilities? That would more closely match old behavior. > On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > > While working on moving the EJB subsystem to support Elytron, I > encountered a dilemma regarding cap/req. > > Elytron exposes security domains as capabilities. EJB deployments have > the ability to specify which security domain is used for authorization > purposes. This specification is by name. > > The dilemma is: > > 1) Allow EJB deployments to directly reference security domain names, > thus implicitly causing the EJB subsystem to require all or none of the > security domains that are or could be configured > 2) Require the EJB subsystem to declare (in the model) what security > domains it uses, thus requiring only security domains that are used > > Option 1 seems disadvantageous because if EJB requires no domains, it is > possible to break deployments without getting so much as a warning, but > if it requires all, then you can never make significant changes to your > security domain configuration. > > Option 2 requires an extra level of configuration, but on the other > hand, it also allows tricks like providing a "local" name for each > security domain which the deployment can reference, which grants a small > but potentially useful degree of flexibility, and it has a better degree > of in-model referential integrity. > > Option 2 also requires that any run-time operation to remove a security > domain from the EJB subsystem be verified against current deployments. > I wonder if we can do this with runtime-only resources and cap/req too? > > I guess I've just talked myself into Option 2, but I'm thinking that > this is not going to be the only case like this as we further develop > cap/req-enabled subsystems. > > Thoughts? > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

If that happened it would down the deployment because capabilities are translated to hard service deps Sent from my iPhone > On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > > I don't like this because if a domain is removed at runtime, it could have unpredictable effects. I'd rather force the model to stay consistent whenever we can. > >> On 09/18/2015 08:31 AM, Jason T. Greene wrote: >> Why not use optional capabilities? That would more closely match old behavior. >> >>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >>> >>> While working on moving the EJB subsystem to support Elytron, I >>> encountered a dilemma regarding cap/req. >>> >>> Elytron exposes security domains as capabilities. EJB deployments have >>> the ability to specify which security domain is used for authorization >>> purposes. This specification is by name. >>> >>> The dilemma is: >>> >>> 1) Allow EJB deployments to directly reference security domain names, >>> thus implicitly causing the EJB subsystem to require all or none of the >>> security domains that are or could be configured >>> 2) Require the EJB subsystem to declare (in the model) what security >>> domains it uses, thus requiring only security domains that are used >>> >>> Option 1 seems disadvantageous because if EJB requires no domains, it is >>> possible to break deployments without getting so much as a warning, but >>> if it requires all, then you can never make significant changes to your >>> security domain configuration. >>> >>> Option 2 requires an extra level of configuration, but on the other >>> hand, it also allows tricks like providing a "local" name for each >>> security domain which the deployment can reference, which grants a small >>> but potentially useful degree of flexibility, and it has a better degree >>> of in-model referential integrity. >>> >>> Option 2 also requires that any run-time operation to remove a security >>> domain from the EJB subsystem be verified against current deployments. >>> I wonder if we can do this with runtime-only resources and cap/req too? >>> >>> I guess I've just talked myself into Option 2, but I'm thinking that >>> this is not going to be the only case like this as we further develop >>> cap/req-enabled subsystems. >>> >>> Thoughts? >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > - DML

On Sep 18, 2015, at 9:11 AM, Jason T. Greene <jason.greene(a)redhat.com&gt; wrote: Yeah TBH I have always wondered if the ability to reference a non existent security domain, and the fallback to a default policy is a good thing. > On Sep 18, 2015, at 8:43 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > > Fair enough. In terms of cap/req though - if this is the desired behavior, it would almost be better to just have no requirement at all. But anything that does any detection (now or in the future) like "hey is anything using this resource?" will return a false negative if it's used by a deployment. If we went the other way and had an optional requirement on all security domains, we'd need some hook to automatically add new requirements every time a domain was added. Either way seems not so good to me... maybe there's another approach though? > >> On 09/18/2015 08:38 AM, Jason T. Greene wrote: >> If that happened it would down the deployment because capabilities are translated to hard service deps >> >> Sent from my iPhone >> >>> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >>> >>> I don't like this because if a domain is removed at runtime, it could have unpredictable effects. I'd rather force the model to stay consistent whenever we can. >>> >>>> On 09/18/2015 08:31 AM, Jason T. Greene wrote: >>>> Why not use optional capabilities? That would more closely match old behavior. >>>> >>>>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >>>>> >>>>> While working on moving the EJB subsystem to support Elytron, I >>>>> encountered a dilemma regarding cap/req. >>>>> >>>>> Elytron exposes security domains as capabilities. EJB deployments have >>>>> the ability to specify which security domain is used for authorization >>>>> purposes. This specification is by name. >>>>> >>>>> The dilemma is: >>>>> >>>>> 1) Allow EJB deployments to directly reference security domain names, >>>>> thus implicitly causing the EJB subsystem to require all or none of the >>>>> security domains that are or could be configured >>>>> 2) Require the EJB subsystem to declare (in the model) what security >>>>> domains it uses, thus requiring only security domains that are used >>>>> >>>>> Option 1 seems disadvantageous because if EJB requires no domains, it is >>>>> possible to break deployments without getting so much as a warning, but >>>>> if it requires all, then you can never make significant changes to your >>>>> security domain configuration. >>>>> >>>>> Option 2 requires an extra level of configuration, but on the other >>>>> hand, it also allows tricks like providing a "local" name for each >>>>> security domain which the deployment can reference, which grants a small >>>>> but potentially useful degree of flexibility, and it has a better degree >>>>> of in-model referential integrity. >>>>> >>>>> Option 2 also requires that any run-time operation to remove a security >>>>> domain from the EJB subsystem be verified against current deployments. >>>>> I wonder if we can do this with runtime-only resources and cap/req too? >>>>> >>>>> I guess I've just talked myself into Option 2, but I'm thinking that >>>>> this is not going to be the only case like this as we further develop >>>>> cap/req-enabled subsystems. >>>>> >>>>> Thoughts? >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> - DML > > -- > - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev