Hi,
I think CDI is more than an implementation detail.
As Rudy mentioned earlier, for the e.g. the multi store epic it's important
to be able to provide your own handler.
If we say the handler *must* be a CDI bean, we don't have to specify
anything else for how a user can wrap or replace the default handler. By
virtue of being a CDI bean it *must* be possible to use a decorator or an
@Alternative for this.
Kind regards,
Arjan Tijms
On Wed, Nov 23, 2016 at 12:26 PM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
wrote:
> Hi,
>
> I agree with Werner here. It would be nice if we could make CDI optional
> from the spec's point of view and leave that to the implementer. We can
> always make recommendations to use CDI, but mandating would be nice to
> avoid. For Soteria, CDI is obvious to use.
>
> Ivar
>
> On Wed, Nov 23, 2016 at 11:27 AM Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Of course the RI (Soteria) should use CDI, but while it seems quite OK
>> for JSON-B to mandate the support of all Date/Time APIs of Java SE 8
>> (java.util, java.time) because it is based on SE/EE8 I am not sure, we
>> should force that everywhere in the Spec. A wording that recommends it but
>> allows e.g. another implementation to pass the TCK without using CDI seems
>> better for acceptance by the community. You (Rudy) heard the questions
>> after our JSON talk in Sofia, and while we may not convince every "de facto
>> standard" in this area to implement JSR 375 and follow-up standards, it
>> would be good to make it as easy and comfortable for them if they want to
>> support it.
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>> On Wed, Nov 23, 2016 at 7:48 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I agree with Arjan that we should use CDI because our aim is to have a
>> "Java EE" security thing in place. Security is already handled (not as
>> completely maybe as it could be) in the different specs.
>>
>> And the annotations, like @LdapIdentityStoreDefinition, could also be
>> picked up by any other framework (read Spring security) as long as they
>> scan or retrieve the classes in some way.
>>
>> Best Regards
>> Rudy
>>
>> On 22 November 2016 at 16:46, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>> Hi,
>>
>> On Tue, Nov 22, 2016 at 3:12 PM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>> Another good example would be Bean Validation.
>> Under "Integration" the spec mentions relevant CDI aspects:
>> http://beanvalidation.org/1.1/spec/#integration-cdi
>>
>>
>> I noticed that, although bean validation can still do that within the
>> Java EE realm, as e.g. bean validation constraints can also be applied to
>> JPA entities which are not (and should not be) managed by CDI.
>>
>> In this case, within the Java EE realm, there would not be much reason I
>> think to shy away from CDI. As Java EE we should be proud on our "own"
>> technology and not abstract from it when not strictly needed, at least
>> IMHO. We're after all the "Java EE" Security spec, and not the general Java
>> Security Spec ;)
>>
>> I mostly followed the MVC lead here and also asked one of their spec
>> leads for advice. There the same discussion came up, where it was suggested
>> that Controllers should be abstract from CDI so they could also be Spring
>> beans etc. But there they firmly decided that these Controllers would be
>> CDI based since MVC was a Java EE spec.
>>
>> That said, it would likely be possible to abstract from CDI somewhat, but
>> I think that would mean that we explicitly have to specify things that we
>> can kinda take for granted when saying we're just based on CDI. For
>> example, in the API we do use @InterceptorBinding from the Interceptor
>> spec, which by default apply to CDI beans. Without us saying that an
>> HttpAuthenticationMechanism is a CDI bean, we'd have to specify it's "some
>> kind of ... something" to which interceptors will apply.
>>
>> Also, for the "factory annotations" (like e.g.
>> @LdapIdentityStoreDefinition) there's an open request to add attributes for
>> setting the name and enabled state of the Bean that's added in response to
>> encountering that annotation. All of these things are easy to define when
>> the beans that are created are CDI beans. If the spec must assume they can
>> also be other things outside Java EE, it's going to be a bit harder to
>> specify what "named" and "enabled" etc means.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I would prefer if we do that in a similar way and not refer to CDI as
>> mandatory in particular functional chapters like Identity Store or Security
>> Context.
>>
>> Happy to change that unless e.g. Arjan wants to do it first?
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>> On Tue, Nov 22, 2016 at 2:44 PM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>> Arjan/all,
>>
>> Thanks for the pointer.
>> In most chapters CDI is mentioned as mandatory requirement. I don't see a
>> dependency in the API other than JUnit, so I think it may not apply to the
>> API.
>> The spec may make recommendations for implementation, but the API does
>> not seem to prevent e.g. some implementation to use Spring (Spring Security
>> of course covers a lot, but who knows it could pick up some of JSR 375 like
>> it happened with other standards e.g. Bean Validation, JBatch or JPA)
>>
>> Agorava Core shows this https://github.com/agorava/agorava-core with a
>> separation into "api", "impl" and "cdi-impl" where only the "cdi-impl"
>> module requires CDI, the others could be based on other DI mechanisms like
>> Spring, Guice, etc. I would try to make that clearer, either by mentioning
>> it in some kind of "implementation note" or drop it from the spec.
>>
>> In JSRs like 354 or 363 we have separate RI guides. There requirements or
>> contstraints of the RI are mentioned, but the spec itself is neutral.
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>> On Tue, Nov 22, 2016 at 2:06 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> p.s.
>>
>> The current draft chapters are:
>>
>> * https://github.com/arjantijms/spec-api/blob/master/spec/src/main/doc/
>> identitystore.asciidoc
>> * https://github.com/arjantijms/spec-api/blob/master/spec/src/main/doc/
>> authenticationMechanism.asciidoc
>> * https://github.com/arjantijms/spec-api/blob/master/spec/src/
>> main/doc/securityContext.asciidoc
>>
>> The JavaDoc is also part of the spec, it can be reviewed here in source
>> form:
>>
>> * https://github.com/javaee-security-spec/soteria/tree/
>> master/api/src/main/java/javax/security
>>
>> Would be really great if someone from the EG could give some (early)
>> feedback on that text.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 22, 2016 at 11:40 AM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> On Tue, Nov 22, 2016 at 11:14 AM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>> That is similar as e.g. CDI taking certain responsibilities from e.g.
>> EJB. It may take time.
>>
>>
>> Indeed, this is pretty much the same thing. At least in JSF I was able to
>> deprecate the native managed bean annotations in favour of the CDI version
>> ;)
>>
>>
>>
>> The Soteria build seems to fail now. Does that have to do with the new
>> methods?
>>
>>
>> Nope, it's only the TomEE build that always fails on:
>>
>> "Failed to read artifact descriptor for org.apache.tomee:javaee-api:jar:7.0-1-SNAPSHOT:
>> Could not transfer artifact org.apache.tomee:javaee-api:pom:7.0-1-SNAPSHOT
>> from/to codehaus-snapshots (https://nexus.codehaus.org/snapshots/):
>> nexus.codehaus.org: Unknown host nexus.codehaus.org"
>>
>> Usually if I restart just the TomEE job manually again it does succeed.
>>
>>
>>
>> I cloned it and after adjusting some formats in classes or POM files
>> tried to commit, but it seems that does not work. Soteria is not a copy of
>> a java.net repository, so what's the reason some or all EG members
>> cannot push to it?
>>
>>
>> We have to check the rights then. All EG should be able to push.
>>
>>
>>
>> There are also many pull requests in the pipeline, so if that was the
>> only way to do this right now, I wonder, if that works or why some (e.g.
>> Rudy mentioned he found a problem during the demo in Sofia) are not merged
>> for some time?
>>
>>
>> Mostly time as far as myself am concerned. I typically try to squash in
>> some time to work on Soteria during my commute, but there's only so much I
>> can do then until I'm welcomed to the barrage of tickets at work or the
>> mountain of chores at home.
>>
>> In case of the current open PRs there's also the question of the person
>> doing them waiting for the confirmation of signing the OCA, and then us
>> doing the multi store commit that conflicted with those PRs, so then have
>> to be rebased/redone I think.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> Kind Regards,
>>
>> Werner
>>
>>
>> On Tue, Nov 22, 2016 at 11:01 AM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> Since JAX-RS resources can be injected with CDI beans, a JAX-RS artefact
>> should be able to inject and use the JSR 375 SecurityContext.
>>
>> Whether we can convince the other specs to formally deprecate their own
>> versions is another thing. For that it's perhaps a pity that there's not
>> really a concept of an umbrella spec in Java EE that sets guidelines for
>> those things. (I know there's an umbrella spec, of course, but in practice
>> it doesn't seem to concern itself much with matters like this)
>>
>> I just added the two methods to the SecurityContext btw:
>> https://github.com/javaee-security-spec/soteria/commit/
>> d41b141fef232c8d2689c7e5bb260dc19f74d933
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 22, 2016 at 10:45 AM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> It would of course be good to have that sooner, but if e.g. JAX-RS 2.1
>> (also facing Renewal Ballot now AFAIK) could leverage that now hard to say.
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>> On Tue, Nov 22, 2016 at 10:38 AM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> On Tue, Nov 22, 2016 at 12:44 AM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>> While OpenID Connect offers to add some optional metadata a concept of
>> roles seems undefined right now, so we may not require it for certain use
>> cases, but others would certainly benefit from it.
>> JAX-RS has its own SecurityContext https://jax-
>> rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/SecurityContext.html
>>
>>
>> Indeed, so as per the JIRA issue the first and foremost goal of the
>> SecurityContext is essentially a cross-spec version of the JAX-RS
>> SecurityContext.
>>
>> Basically if it has the isCallerInRole and getCallerPrincipal methods,
>> it's 95% there.
>>
>> Those two methods are now found in more or less identical versions in 4
>> different specs.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> Looking at Spring Security the SecurityContext interfact there is
>> somewhat closer to the one in JSR 375 but it also has a getter for an
>> Authentication object.
>> In https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12 this could be
>> getCallerPrincipal(), getAuthMethod() or similar but they do not currently
>> exist in SecurityContect.
>>
>> Kind Regards,
>> Werner
>>
>>
>> On Mon, Nov 21, 2016 at 11:07 PM, Will Hopkins <will.hopkins_at_oracle.com>
>> wrote:
>>
>> Experts,
>>
>> While I've received some input for the spec from Arjan (thanks!), and
>> there may be some coming from Werner as well, I haven't been able to put
>> the terminology section in place, and the content we have so far is, I
>> think, too thin to release as an EDR.
>>
>> I therefore propose we move forward with the renewal ballot, indicating
>> that the EDR is taking shape and expected to be released soon, and that the
>> expert group is active and involved in producing the EDR, as well as the
>> API and an associated RI. It's my understanding that there is unlikely to
>> be a problem getting the renewal ballot approved.
>>
>> What say you all?
>>
>> Will
>>
>> --
>> Will Hopkins | Platform Security Architect | +1.781.442.0310
>> Oracle Cloud Application Foundation
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jsr375-experts/CAAGawe04QWmHBt5xKR0P_02NOHwgrQ_e8pWGfEjUvPzWoAtJ4w%
>> 40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe04QWmHBt5xKR0P_02NOHwgrQ_e8pWGfEjUvPzWoAtJ4w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jsr375-experts/CAAGawe29mXKPNeDGky3ti%3DPYp%
>> 2B2igkUVDz2E4kBfwEWCWPL4FA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe29mXKPNeDGky3ti%3DPYp%2B2igkUVDz2E4kBfwEWCWPL4FA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jsr375-experts/CAE%3D-AhCfwmYGCUdj59a5cOL_
>> tgritx5RTErdOJ7cZDngvg%3DL%3DA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAE%3D-AhCfwmYGCUdj59a5cOL_tgritx5RTErdOJ7cZDngvg%3DL%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jsr375-experts/CAL%2Bwt-6%3DawnMxL7FcPg5pf2rKF%
>> 2BGPj5rqRi4G22cTOze4%2BnG0g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-6%3DawnMxL7FcPg5pf2rKF%2BGPj5rqRi4G22cTOze4%2BnG0g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jsr375-experts/CAAGawe1g9d9bCeL%3DRfoGjQhd7U-
>> 16TyMT0f3UGsfGpRNkKkSHQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe1g9d9bCeL%3DRfoGjQhd7U-16TyMT0f3UGsfGpRNkKkSHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jsr375-experts/CAOAQAPp7zv03GJ4mBpSpfLtK1RisE
> Ncde8-wBGS9P3pKC9LKfw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAOAQAPp7zv03GJ4mBpSpfLtK1RisENcde8-wBGS9P3pKC9LKfw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>