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/SecurityCo
>>>>>> ntext.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/CAAGawe04QW
>>>>>> mHBt5xKR0P_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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>