I don't have a lot of insight into the EE 9 plans generally, but I agree
that security is a no-brainer for inclusion, especially given the latest
survey results around OAuth and OIDC, and I think it's seen that way
broadly within Oracle.
On 03/18/2017 07:38 PM, Reza Rahman wrote:
>
> 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
>>
>>
>>
>
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803