Sounds OK. I am not sure, if JCP.next would still allow you to be listed,
but if you already are on OTN, I guess that is fine as for your ability to
help with Soteria.
Regards,
Werner
On Mon, Dec 12, 2016 at 4:20 PM, Will Hopkins <will.hopkins_at_oracle.com>
wrote:
> Sounds, good -- thanks, Guillermo!
>
> On 12/10/2016 02:36 PM, Guillermo González de Agüero wrote:
>
> Hi Will,
>
> I just want to be a contributor. I just signed the Oracle Contributor
> Agreement for Soteria, and I got listed on http://www.oracle.com/
> technetwork/community/oca-486395.html. I didn't join the JCP at all.
>
>
> Regards,
>
> Guillermo González de Agüero.
>
> On Fri, Dec 9, 2016 at 8:38 PM, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
>> Hi Guilermo,
>>
>> Are you requesting to be on the EG, or simply a contributor?
>>
>> Will
>>
>>
>> On 11/22/2016 08:31 AM, Guillermo González de Agüero 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.co
>>>>>>>> m.
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Will Hopkins | Platform Security Architect | +1.781.442.0310 <+1%20781-442-0310>
>> Oracle Cloud Application Foundation
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>
> --
> Will Hopkins | Platform Security Architect | +1.781.442.0310 <+1%20781-442-0310>
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>