My thinking, and my understanding of the EG's thinking, is that JSR 375
would consider:
* Client-side OAuth support -- acquire tokens on behalf of a client
for use in accessing an application
* Server-side OAuth support -- consume tokens to identify and
authorize clients of an application
We would not consider (at least for now):
* OAuth Authorization Server -- the standalone server that
authenticates users and issues tokens
Will
On 11/08/2016 01:50 AM, reza_rahman wrote:
> +1. Definitely agree with Rudy's observations.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Rudy De Busscher <rdebusscher_at_gmail.com>
> Date: 11/8/16 6:43 AM (GMT+01:00)
> To: Werner Keil <werner.keil_at_gmail.com>
> Cc: jsr375-experts_at_javaee-security-spec.java.net, Java EE Security API
> - JSR 375 - Experts <jsr375-experts_at_googlegroups.com>
> Subject: [javaee-security-spec users] [jsr375-experts] Re: Add OAuth2
> and/or OpenID Connect Support to JSR-375?
>
> 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
> <mailto: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
> <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/
> <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 <mailto: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 <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
>> <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
>> <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
>> <https://groups.google.com/d/optout>.
>>
>
> --
> 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/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
> <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