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
>>
>>
>