+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 regardsRudy
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.
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.
For more options, visit https://groups.google.com/d/optout.