Sounds like there's consensus support for including OAuth in some form.
Werner, are you open to including server-side features in the universe
of OAuth functionality we consider for JSR 375? As part of the process
we'll need to think about and decide on specifics, which could result in
dropping server-side features for reasons of size or complexity, but it
seems like we should at least start by considering all the options.
That way, even if we defer some features, we've at least done some
initial thinking about them.
Clarifying question: When we talk about server-side features, my
assumption is we are only talking about support for servers/applications
consuming OAuth tokens -- i.e., it does not include OAuth Authorization
Server functionality. Is that everyone else's view as well? We could
certainly discuss whether EE should include an AS, but the AS is
typically standalone and external to both client and server, and has far
more complex requirements. We could presumably standardize client and
server without any requirement to standardize the AS (except to the
extent that we wanted to standardize a mechanism for declaring/managing
scopes known to an AS).
Thoughts?
On 11/06/2016 12:21 PM, Ivar Grimstad wrote:
> Hi,
>
> I haven't seen the survey results yet, but if Oauth/OpenID Connect is
> ranked third there I really think we should try to fit it into JSR375.
> As you say, these are widely adopted technologies that Java EE should
> provide good support for.
>
> There is also the aspect of respecting the community survey and
> regaining some of the trust lost the last year. If we choose to leave
> Oauth/OpenID Connect to JSR-Next, we should be prepared for a great
> deal of negative response in terms of "/...they're ignoring the
> community again.../" etc.
>
> To sum up, I am all for including Oauth/OpenID Connect in JSR 375,
> thus doing it sooner rather than later.
>
> Ivar
>
> On Fri, Nov 4, 2016 at 9:39 PM Werner Keil <werner.keil_at_gmail.com
> <mailto:werner.keil_at_gmail.com>> wrote:
>
> 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
> <mailto: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 <mailto: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 <tel:%2B1.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
> <mailto:jsr375-experts+unsubscribe_at_googlegroups.com>.
> To post to this group, send email to
> jsr375-experts_at_googlegroups.com
> <mailto:jsr375-experts_at_googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jsr375-experts/CAAGawe2%3DCucATjBE_dmG%3D-b_envxACM%2BudB%3DE_-ZehnZ2V2KJg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe2%3DCucATjBE_dmG%3D-b_envxACM%2BudB%3DE_-ZehnZ2V2KJg%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
Oracle Cloud Application Foundation
35 Network Drive, Burlington, MA 01803