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> 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>
> 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>
> 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>
> 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> 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 <+1%20781-442-0310>
> Oracle Application Development
> 35 Network Drive, Burlington, MA 01803
>
>
>
> --
> Will Hopkins | WebLogic Security Architect | +1.781.442.0310 <(781)%20442-0310>
> Oracle Application Development
> 35 Network Drive, Burlington, MA 01803
>
>
>
> --
Java Champion, JCP EC/EG Member, JUG Leader