I will defer to the other folks more involved in the specification on this. My relatively uninformed view is telling me your approach is reasonable.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Will Hopkins <will.hopkins_at_oracle.com> Date: 2/23/17 11:45 AM (GMT-05:00) To: users_at_javaee-security-spec.java.net Subject: [javaee-security-spec users] Re: [javaee-spec users] Re: [jsr375-experts] Re: Final Call for Comments for EDR
All,
There are a number of concerns expressed in this thread, and in a
separate branch that went to experts instead of users. Let me try to
summarize my responses:
Yes, I believe this JSR can be completed consistent with the
EE 8 schedule, although it is ambitious.
I was asked if I thought the JSR would fit in the proposed
schedule. My response was that I thought it would, with the
assumption that scope was constrained to the pieces which were
largely already in place; i.e., the pieces in the current draft
document.
The plan would be to escalate resources if needed to meet the
schedule.
I agree with Werner's view that it's best to keep security
"close to the core".
On the question of scope, Arjan said the following in a different
thread:
The "ambitious" Java EE 8 release goal is
indeed "ambitious", or perhaps "sudden" ;)
Nevertheless, what we have now would still be very useful. We
could do a couple of things from this point on:
1. Only streamline what we have, don't add much new
functionality
2. Adding the missing features for the Security Context, then
do 1.
3. Ambitiously integrate the authorization proposal and the
multiple authentication mechanism proposal, both presented and
essentially okay'ed by the EG earlier.
Given the schedule, I don't think we can consider adding *any* new
functionality. In fact, I'm wondering, based on the recent technical
discussion around SecurityContext, if it might be worth dropping
SecurityContext completely. As currently spec'd, it doesn't provide
any net-new functionality -- the behaviors it provides are already
present, albeit with slightly different syntaxes, in each of the
relevant containers -- and it presents some significant
implementation challenges. It might be better to defer
SecurityContext until we can more fully define it, to make sure it's
providing real value over and above what exists today. (I do agree
that a standardized API has value in and of itself, but I'm not sure
that alone justifies the implementation complexity.)
Dropping SecurityContext would also allow the JSR to focus very
narrowly on authentication and identity store, where the existing
proposals do add some real value.
It's certainly reasonable to discuss whether it's worth putting out
a JSR with very constrained scope. We could declare that JSR-375
won't make EE 8, and open up the scope again. Or, we could petition
Oracle management to delay the schedule, to enable additional scope
-- but the chances of getting schedule movement are exceeding small
(and the likelihood of getting enough time to add features like
OAuth/OIDC is essentially zero).
On balance, my view is that it's best to proceed with what we have,
potentially dropping SecurityContext, and leave the rest for EE 9. I
think we will have achieved something useful even if all we do is
standardize HttpAuthenticationMechanism and IdentityStore.
Thoughts?
Will
On 02/23/2017 07:24 AM, Werner Keil
wrote:
While 107 despite Oracle being a co-spec lead must
have gone that way (it was mentioned in the original JSR 366
proposal but has not even published the MR sorting out the
license issue which makes it unacceptable to Eclipse and
projects like MicroProfile as of now;-) there are good reasons
to keep aspects of security close to the "Java EE core" or
platform.
On Thu, Feb 23, 2017 at 1:14 PM,
reza_rahman <reza_rahman_at_lycos.com>
wrote:
Quite honestly, part of me also can't help but
wonder if this specification is not better off going
the MVC route - driven independent of Java EE by the
community. It could be determined later in Java EE 9
if the specification is included in the umbrella
release if Java EE 9 is really still targeted for 2018
as Oracle announced at JavaOne. To my understanding,
Java EE 9 is really what Oracle cares more about
anyway due to their cloud/PaaS/microservices business
goals.
Just thinking out loud so others can also chime in.
I have to say this worries me and we need some
substantive open dialog with Oracle to get this piece
sorted out properly.
Sent
via the Samsung Galaxy S7, an AT&T 4G LTE
smartphone
-------- Original message --------
From: Werner Keil <werner.keil_at_gmail.com>
Date: 2/23/17 6:53 AM (GMT-05:00)
To: users_at_javaee-spec.java.net
Cc: users_at_javaee-security-spec.java.net,
Java EE Security API - JSR 375 - Experts <jsr375-experts_at_googlegroups.com>
Subject: [javaee-spec users] Re:
[javaee-security-spec users] [jsr375-experts]
Re: Final Call for Comments for EDR
Thanks, that's a good point.
I have not heard back from him but
fellow JSR 375 EG member Adam is
supposed to be on a panel at JavaLand
I'm invited to moderate.
According to the schedule:
https://www.javaland.eu/konferenz/konferenzplaner/konferenzplaner_details.php?id=522447&locS=0&vid=529321
Rudy has a JSR 375 talk there (should be
right afterwards) followed by Gunnar and BV
2.0 (another "question mark" for EE 8 based
on that new, tight schedule) as well as
David Delabassee having a Java EE
talk that day.
The panel is in parallel to regular
talks but I hope there will be enough space
(I heard it might be a little bigger) and
that all of the EE related speakers could
also join us if they're not too busy
preparing their sessions?;-)
Cheers,
Werner
On Thu, Feb 23, 2017 at
12:45 PM, reza_rahman <reza_rahman_at_lycos.com>
wrote:
When I heard about the schedule, this
is the specification that worried me
most. Did Oracle solicit feedback from
Will before they decided on that
announcement? What can really be done in
the time frame mentioned with the
current resource levels? Is the plan to
significantly escalate resource
commitments? Significantly scale down
scope yet once again?
It would also be good to hear
feedback from the major vendors on this.
In the original Java EE 8 survey the
security JSR ranked the highest in
importance. Although the new survey did
not ask about all the security JSR
features, the security features that
were mentioned also ranked extremely
high. I would say this JSR is important
enough to delay the overall release
train if needed.
What do others think?
Sent via the Samsung Galaxy
S7, an AT&T 4G LTE smartphone
-------- Original message
--------
From: Werner Keil <werner.keil_at_gmail.com>
Date: 2/23/17 5:24 AM (GMT-05:00)
To: jsr375-experts_at_javaee-security-spec.java.net
Cc: Java EE Security API - JSR
375 - Experts <jsr375-experts_at_googlegroups.com>
Subject: [javaee-security-spec
users] [jsr375-experts] Re: Final
Call for Comments for EDR
Will/all,
Thanks, that's good news. Despite
the ball now rolling (and I think
several requirements are pretty
solid) do you think 375 will make
it for the new "ambitious" Java EE
8 release goal (to be Final by
July) or should 375 as a whole be
considered more likely for the
next Java EE umbrella release?
I copied the Google Group, is there
any official mailing list or similar
channel in sight that woudl replace
the java.net list
when it's gone?
Regards,
Werner
On
Thu, Feb 23, 2017 at 2:06
AM, Will Hopkins <will.hopkins_at_oracle.com>
wrote:
EG,
I'd like to put out an
EDR this week, or
perhaps Monday. I
think, based on the
comments and
discussion so far,
that I've got a good
enough understanding
to update the spec for
that purpose. There
are some outstanding
issues to be resolved,
though, so please do
reply to my latest
comments in the
"Comments on Current
Spec Content (take 3)"
thread, or start a new
thread, if you have
input you'd like to
see reflected in the
EDR.
Thanks,
Will
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803