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
> <mailto: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
> <mailto:werner.keil_at_gmail.com>>
> Date: 2/23/17 6:53 AM (GMT-05:00)
> To: users_at_javaee-spec.java.net <mailto:users_at_javaee-spec.java.net>
> Cc: users_at_javaee-security-spec.java.net
> <mailto:users_at_javaee-security-spec.java.net>, Java EE Security API
> - JSR 375 - Experts <jsr375-experts_at_googlegroups.com
> <mailto: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
> <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 <mailto: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
> <mailto:werner.keil_at_gmail.com>>
> Date: 2/23/17 5:24 AM (GMT-05:00)
> To: jsr375-experts_at_javaee-security-spec.java.net
> <mailto:jsr375-experts_at_javaee-security-spec.java.net>
> Cc: Java EE Security API - JSR 375 - Experts
> <jsr375-experts_at_googlegroups.com
> <mailto: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
> <http://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 <mailto: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 <tel:+1%20781-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