Hi,
I believe, that's what Antoine meant, when he said, Agorava only handles
the client-side (aka "consuming" OAuth).
Of course Java especially Java EE is full of "wrappers" around existing
standards, just take JSON-P and other JSRs that get updated also for Java
EE 8 based on multiple RFCs, or HTTP 2 support coming to Servlets or even
Java SE.
We don't have to replicate RFCs like those behind OAuth or OpenID
For OAuth2 (same exists for 1) you see under OAuth 2 Provider:
https://projects.spring.io/spring-security-oauth/docs/oauth2.html
what types and elements Spring Security has. While not always identical,
certain annotations, classes or interfaces would be not so different in a
Java EE / CDI world.
If JWT (JSON Web Token, that, keep in mind has no RFC yet, it's only a
draft as we discussed in the JSON-P call with Dmitry) support was desired,
there could be additional elements, but IMHO I would e.g. leave that to EE
9 despite some popularity, because there is no standard for it yet.
For OAuth Client, both OAuth 2 and 1a are fully supported by Agorava, so
beside Spring Security in that paragraph you can also check out Agorava to
get an idea what could be necessary for JSR 375. The devil always lies in
details, often it's major services considering your server-side OAuth
consumer a possible spam or DDOS intruder and lock you out after
authorization has already worked, but in general Agorava works and such
issues can be seen more client or application specific, nothing e.g. this
JSR would have to deal with.
Werner
On Tue, Nov 8, 2016 at 8:20 AM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
wrote:
> 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.
>>
>