Hi,
I think we need to clarify the terms so we are on the same page when
talking about client/server-side etc. Will also asked this in his
clarifying question below.
What I have understood is that we would like to standardize how we *consume
OAuth tokens on the server* and not the Oauth Authorization Server itself.
As Rudy also points out, the protocol is already standardized.
Is this the same as the client-side oauth you are talking about, Werner?
One more thing. No matter how we decide to proceed with this, I don't think
we should consider delaying JSR-375 an option. EE8 needs to be delivered as
proposed and I am pretty sure that any further delays won't be received
well.
Ivar
On Tue, Nov 8, 2016 at 6:43 AM Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> All,
>
> So it is the idea to add an OAuth2/OpenIDConnect server to all the Java EE
> certified application servers?
>
> I agree that an OAuth2 client is a very good idea for JSR375 but
> - Almost everyone uses a separate server for OAuth2, most of the time not
> even managed by the company itself.
> - When created and maintained by the company itself, it is always on a
> separate server instance which doesn't need any Java EE capabilities.
>
> So, for me, an OAuth2 server shouldn't be standardized within Java EE
> security API also because the protocol is already standardized somewhere
> else.
>
> Best regards
> Rudy
>
>
> On 7 November 2016 at 22:19, Werner Keil <werner.keil_at_gmail.com> wrote:
>
> Will,
>
> Thanks for the update. I forwarded the message to Antoine who mentioned
> concerns about the complexity of an OAuth Provider (while e.g. Agorava only
> consumes OAuth services as of now)
>
> This is a list of projects implementing the server-side on StackOverflow:
>
> http://stackoverflow.com/questions/10296681/is-there-an-oauth-2-0-provider-implementation-in-java-not-oauth-client
>
> It sounds a bit similar as e.g. the situation of the (not yet filed) Java
> Config JSR related to efforts like Apache Tamaya, Commons Configuration or
> maybe Netflix Archaius.
>
> All of those use the Apache License, while at the moment (despite e.g.
> David's initial approach in the "sandbox" claiming those examples were
> Copyright Apache Foundation and under the Apache License;-) e.g. JSR 375
> aims at the "Glassfish" system and license scheme. Where suddenly changing
> the RI to Apache could be a challenge. If it was possible (JCache is so far
> the only recent exception where Greg and Oracle decided to go with the
> Apache License except for the TCK, it may actually be double- or
> triple-licensed, maybe an option here, too?) then projects like Apache Oltu
> sound very interesting http://oltu.apache.org/ and could speed things up
> quite a bit.
>
> Kind Regards,
>
> Werner
>
>
> On Mon, Nov 7, 2016 at 9:56 PM, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
> 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> 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> 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
>
>
>
> --
> 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/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
>
>
> --
> 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/CAAGawe2dOAT3h7LrQQNoXKrTSnw%2BoyOeb4s4X89X3u%2BdYuPeQA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe2dOAT3h7LrQQNoXKrTSnw%2BoyOeb4s4X89X3u%2BdYuPeQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/CAL%2Bwt-4oiZyz1P7-HxogzTC1cSdLox-tpetcUFxr%3DuZKRLaqiw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-4oiZyz1P7-HxogzTC1cSdLox-tpetcUFxr%3DuZKRLaqiw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>