Frankly I am wondering about the same. Continuing the security
specification seems like one of the most non-controversial, no-brainer
parts of Oracle's Java EE 9 plans. This certainly includes support for
OAuth and OpenID, not to mention all the changes that folks here have
been working on for such a long time now.
On 3/18/17 7:30 PM, Werner Keil 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
> <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
>
>
>