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/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.
>>>>>
>>>>
>>>>
>>>
>>
>