Hi,
I had a chat with CDI Spec Lead Antoine at JavaOne about OAuth and he
pointed out, what we did at Agorava (based on CDI) was Client-side OAuth
and that Server-side OAuth or OpenID connect support would be more complex
and sophisticated. Probably among the reasons, it's been intended for a
future Security JSR.
Maybe sticking to the client-side could work for JSR 375.
Check out Agorava-core
https://github.com/agorava/agorava-core
It is based mainly around standard technologies. A few aspects like Jackson
could likely use the new JSON-B JSR for Java EE 8.
Kind Regards,
Werner
On Fri, Nov 4, 2016 at 9:18 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> For OAuth support an issue was created in the tracker some time ago, see
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-13
>
> So this doesn't seem quite out of scope and would be a really welcome
> addition.
>
> There is of course the question about time and resourcing, but an OAuth
> feature is something that could be worked on fairly independently from some
> of the other open issues.
>
> OAuth is also clearly a more user visible feature and could help with
> making JSR 375 more attractive to a general group of developers. Some of
> the other open issues are more about somewhat technical gaps in the EE
> security architecture like the standardised type for the user/caller
> principal and the role mapper. While quite important, such things may not
> directly capture the imagination of the largest group of developers.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> On Fri, Nov 4, 2016 at 8:28 PM, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
>> Experts,
>>
>> I have been asked to get a sense of how the EG would feel about adding
>> OAuth2 and/or OpenID Connect support to JSR-375.
>>
>> Our plan of record has been to defer OAuth/OpenID Connect until the next
>> security JSR, so that we can wrap up JSR-375 quickly and move on to
>> cloud-oriented technologies, including OAuth/OpenID Connect, as
>> expeditiously as possible. That still seems like a good plan to me --
>> anything we do with OAuth/OpenID Connect is likely to require significant
>> time and effort to get right, and we don't want to put out something
>> half-baked and have to fix it (or support it) later. Deferring it allows us
>> to release the existing features of JSR-375 quickly, and move on to
>> JSR-Next -- which is more than just OAuth/OpenID Connect -- as soon as
>> possible.
>>
>> That said, OAuth/OpenID Connect ranked third, after ReST services and
>> HTTP/2, in the most recent EE community survey. Clearly, the community
>> wants OAuth/OpenID Connect support in EE. Both are strategic security
>> technologies with wide acceptance and adoption in real-world applications
>> today. We could decide to take that on in JSR-375, and probably make it
>> available sooner than if we waited for JSR-Next. Or, we could do a smaller
>> piece in JSR-375 -- perhaps just OpenID Connect, which is a simpler model
>> (authentication only) -- and then add OAuth2 proper in JSR-Next.
>>
>> Either way, we're talking about substantial additional time, effort, and
>> complexity to add any part of OAuth/OpenID Connect to JSR-375. There may be
>> other considerations as well -- for example, are there ramifications in
>> terms of adding brand new technology areas that were not mentioned in the
>> original JSR proposal? We'd have to work through those issues before
>> making a final decision. I don't think the upcoming EDR deadline is an
>> obstacle -- worst case, we could add a TBD placeholder section for OAuth.
>>
>> So. There are pros and cons to any course of action here. It would be
>> great to wrap up JSR-375 quickly and move on, but given the importance of
>> OAuth/OpenID Connect, so doing it sooner rather than later might be the
>> right decision even if it delays JSR-375.
>>
>> What do you all think?
>>
>> Will
>>
>> --
>> Will Hopkins | Platform Security Architect | +1.781.442.0310
>> Oracle Cloud Application Foundation
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>