It seems like there's a pretty strong consensus to try and get this in,
so I'll do my best to support that.
I want to make sure everyone understands the current timeline, though.
Based on the EE 8 schedule, we need be finished with our final ballot by
July 10, 2017. That's less than 4 months away, and EDR has just begun.
We can publish our Final Draft no later than mid-May, which is about two
months off. During that time, we also need to finish the RI, make it at
least somewhat production-ready, and develop a TCK that covers all APIs
sufficiently well (the latter tasks are largely on Oracle).
With regards to Arjan's question about the level of effort required, I
think there's more work than meets the eye in terms of, for example,
iterating through all the EE containers and ensuring we have an
implementation strategy (and RI code) for each, or else calling that
container out as an exception. Also, the authentication API in
SecurityContext amounts to a programming API for JASPIC authentication;
not, as I had earlier understood it, a fairly simple delegation to
HttpServletRequest.authenticate(). It will expose JASPIC interfaces and
behaviors, and an application that wants to use it may well need to
understand what SAMs are configured and how they behave. Those use cases
may already have been discussed and validated before I came on as spec
lead, but, if not, there's probably a discussion to be had. The contract
with JASPIC will have be specified (there's nothing now beyond the
soteria code, that I'm aware of), and we'll need to make sure that we
can do so without "breaking" the JASPIC Servlet Container Profile, which
currently specifies it's integration exclusively in terms of the servlet
container. And all that's before we get to the work of ensuring the
implementation is thorough and portable, and writing the tests.
The effort would be more manageable as a task for one engineer, or a
small team. We are a committee scattered across the globe, and must
reach consensus on changes. This introduces a lot of calendar-time
delay. For example, I sent out several emails with comments, questions,
and responses to previous emails a couple of weeks ago. When I published
the EDR, I also included some "review" items that I thought required
further discussion and clarification. So far, I haven't had any response
to either. That's not a knock on anyone -- we're all busy -- but it
slows the process considerably. Design decisions that a single engineer
could make quickly take longer in a committee. That, along with the
"hidden" work of Glassfish RI integration and TCK development -- which
also have to be complete in the June timeframe -- are what concern me most.
All that said, the support for keeping SecurityContext is clear, so
let's proceed on that basis. I'll need help from all of you -- please
have a look at the EDR spec, and my emails from a couple weeks ago
(though much of what's in the emails is also in the EDR), and think
about it. I'll be at Devoxx next week -- perhaps some of us could meet
-- but it would be great if we could meet via Hangouts (or similar) the
week after that, and try to work through some of the outstanding issues.
I'm also hoping to triage the open JIRAs and use that to manage the
remaining tasks, but it'll take me a little while to get through that.
Regards,
Will
On 03/19/2017 03:03 AM, Ivar Grimstad wrote:
> Hi,
>
> I think Arjan sums it up pretty well and I agree with him and Werner
> that it would be good to fit it into 1.0.
> From a developer's perspective, it can be really confusing not having
> a common platform-wide Security Context.
>
> Ivar
>
> On Sun, Mar 19, 2017 at 12:30 AM Werner Keil <werner.keil_at_gmail.com
> <mailto:werner.keil_at_gmail.com>> wrote:
>
> Arjan/all,
>
> Thanks, I think you covered most of the arguments.
> So on the question how strong I personally feel about it, I assume
> Arjan also agrees it would be good to try get it into 1.0.
>
> Proprietary quasi-standards like Spring Security offer this and it
> even contains an element called SecuritContext:
> http://docs.spring.io/spring-security/site/docs/3.0.x/reference/technical-overview.html
> Since 3.0 so it's been there quite a while.
>
> If it won't make it into Security API 1.0 the question would be,
> how soon the next version (likely a new JSR Security 1.x) could be
> expected. Similar with Java EE 9. Oracle hopes to introduce annual
> release trains for Java SE pretty soon, but I am not sure, if even
> a more Agile way of working and finer grained "profiles" than Java
> EE has right now will really get us to a new version every year
> and products picking it up so rapidly.
>
> Kind Regards,
>
> Werner
>
>
>
> On Sun, Mar 19, 2017 at 12:15 AM, arjan tijms
> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> Maybe one important question to start with; is there any kind
> of functionality, security context or otherwise, that can
> still be added at this point, or is because of the tight
> schedule and low availability of resources taking what's there
> now (maybe tuning it a little) the only really reasonably option?
>
> I'm asking since there are still some major things on the
> shelve, like the authorization rules, and the multiple
> authentication mechanisms. A while back Darran Lofthouse
> proposed the latter, but we haven't heard from him since.
>
> I prototyped the authorization rules and it actually works
> pretty well already, but some discussion about it would not hurt.
>
> >and doesn't work on Tomcat because HttpServletRequest isn't
> injectable.
>
> It was, of course, never the idea to depend on
> HttpServletRequest here. That aside,
> isn't HttpServletRequest injectable or obtainable (via the
> BeanManager) if a CDI implementation is added to Tomcat? Or
> are you referring to the TomEE (not Tomcat) bug here where the
> injection doesn't quite work as it should?
>
> >But I think it still requires significant work,
>
> I'm not exactly sure if the amount of work is
> still significant, but obviously that's a relative term. What
> would you approximately consider a significant amount of work
> expressed in time? Would it be e.g. 10 hours (discussion,
> spec, programming), 20 or something else?
>
> Just trying to get some ballpark estimate here so we
> can hopefully better schedule things around that.
>
> Also, quite important, what is the work you think would be
> required?
>
> Specifying an interface with getCallerPrincipal(),
> isCallerInRole() and authenticate() is not that much work, and
> the interface is even already there. Or are you referring here
> to a discussion about the finer details, like returning
> Principal vs CallerPrincipal, and e.g. the way options are
> passed into the authenticate() method?
>
> >Having just looked at the RI impl of authenticate, I'm also
> wondering about the level of dependence on JASPIC, vs. a
> simple layering on the servlet mechanism.
>
> The way to trigger authentication, possibly involving caller
> interaction, in a web module is done by layering on
> the servlet mechanism, there's no concept of that in JASPIC.
> JASPIC only defines how the Servlet Container should call
> (eventually) a SAM when the application has asked for
> authentication (has triggered the chain).
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Sat, Mar 18, 2017 at 9:40 PM, Will Hopkins
> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>
> I can see how this would be useful (although I don't see
> how we get to @RunAs based on getCallerPrincipal() or
> getCallerInRole() alone).
>
> My objection isn't to the functionality, it's to the
> effort required to complete the SecurityContext work, in
> light of the fact that there are existing ways to achieve
> the same thing, albeit with different syntax in different
> containers.
>
> The spec and the API are the easy parts, relatively
> speaking, but there is still RI and TCK work required. I
> just had a look at the impl in Soteria, and it's
> servlet-container-only at this point, and doesn't work on
> Tomcat because HttpServletRequest isn't injectable.
> Extending SecurityContext to other containers would
> presumably require the ability to inject appropriate
> context objects from those containers as well -- possibly
> limiting the containers for which SecurityContext could be
> supported -- or a non-CDI-based integration approach).
> Having just looked at the RI impl of authenticate, I'm
> also wondering about the level of dependence on JASPIC,
> vs. a simple layering on the servlet mechanism.
>
> All of this is not to say that we can't include
> ServletContext, or that it doesn't have value. But I think
> it still requires significant work, and given how tight
> the remaining schedule is, I'm concerned about investing
> that effort in functionality that's redundant to some
> degree, and could be undertaken, more thoughtfully, in the
> next security JSR. The HttpAuthenticationMechanism and
> IdentityStore, by contrast, feel much better defined to
> me, although there are still some details to work out.
>
> Arjan, Werner: How strongly do you feel about
> SecurityContext?
>
> Other experts: Any thoughts on this, one way or another?
>
> Will
>
>
> On 03/16/2017 02:20 PM, Werner Keil wrote:
>> I just did a presentation at the current client today
>> about the state of Java EE 8.
>>
>> And like several other gigs before, there are plenty of
>> use cases with something like
>> @RunAsUser(username="abc", department="xyz")
>> or similar.
>>
>> I'm not sure, if we manage to provide something like
>> those kinds of annotations, they often can get pretty
>> domain or company specific, but an underlying
>> isCallerInRole or getCallerPrincipal mechanism would be a
>> start to use and create them in a standard manner.
>>
>> If there was a strong disagreement on naming or what
>> should be there, I could understand leaving it for later,
>> but if that's not the case, I would try to leave it and
>> provide basic implementations. Maybe more to follow in EE
>> 9 or leave it up to individual products.
>>
>> Regards,
>>
>> Werner
>>
>>
>>
>> On Thu, Mar 16, 2017 at 6:50 PM, arjan tijms
>> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>> wrote:
>>
>> Hi,
>>
>> The original vision for security context was really
>> simple. Basically just isCallerInRole and
>> getCallerPrincipal.
>>
>> In fact it's basically done. There's some discussion
>> regarding how to implement it, especially in the
>> light of the "fear" (for lack of a better term) of
>> JACC. But that shouldn't really stand in the way of
>> the specification.
>>
>> All the other methods and features mentioned in the
>> issue were pretty much optional (nice to haves).
>>
>> So if we take what we have now, declare that to be
>> the draft spec and invite the EG to provide comments
>> for minor adjustments at most (no new features, but
>> perhaps change the names or option syntax somewhat),
>> then we should be there.
>>
>> I can try to do the GF implementation soon.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> On Thursday, March 16, 2017, Will Hopkins
>> <will.hopkins_at_oracle.com
>> <mailto:will.hopkins_at_oracle.com>> wrote:
>>
>> Hi All,
>>
>> I'm wondering if it makes sense to drop
>> SecurityContext from the spec, for these reasons:
>>
>> * As currently specified, it is completely
>> redundant. It does provide a uniform syntax
>> across containers, but all three methods (one
>> of which only works in the servlet container)
>> duplicate functions that already exist,
>> albeit with slightly different syntaxes, in
>> every container. The only value we're adding
>> here is syntactical uniformity.
>>
>> * As currently specified, SecurityContext
>> provides only a subset of the functionality
>> originally envisioned. I confess I'm not as
>> familiar with the earlier plans as I should
>> be, but based on more recent discussions it
>> seems clear that the original vision was for
>> a more complete set of functions. It might
>> make sense to avoid specifying any of the
>> functions until we can consider the API more
>> completely and wholistically and ensure that
>> it presents a concise and cohesive set of
>> functions.
>>
>> * The EE 8 schedule is very aggressive.
>> SecurityContext isn't extremely complicated,
>> but there is still significant work to
>> finalize the spec and the API, make sure the
>> RI is correct, and, for us here at Oracle,
>> integrate the RI with GlassFish and develop
>> the TCK. I think it's still possible to get
>> all that done for SecurityContext, but in
>> light of the fact that SecurityContext
>> doesn't add any net-new functionality, I
>> think it makes sense to drop SecurityContext
>> so we can focus completely on getting
>> HttpAuthenticationMechanism and IdentityStore
>> done. Those two pieces add a lot of value,
>> and is still significant work to do for them,
>> particularly IdentityStore.
>>
>> Let me know what you think.
>>
>> Regards,
>>
>> 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 <tel:%28781%29%20442-0310>
> Oracle Application Development
> 35 Network Drive, Burlington, MA 01803
>
>
>
> --
>
> Java Champion, JCP EC/EG Member, JUG Leader
>
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803