Hi,
Thanks for the update.
I assume, if some who raise PRs or plan to do so in the future joined the
JCP as Associate Members (e.g. Reza himself who I recall did so), that
would also be an option? Or do they also need an OCA in addition to that?
Regards,
Werner
On Tue, Nov 22, 2016 at 2:31 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> Hi,
>
> My OCA was already approved (thanks to Reza Rahman and David Delabasse).
> I'll have to check my pull requests to see if they are still relevant and
> rebase them if needed. Sorry for not telling you before.
>
>
> Regards,
>
> Guillermo González de Agüero.
>
> 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>