Hi,
On Sun, Mar 19, 2017 at 10:08 PM, Will Hopkins <will.hopkins_at_oracle.com>
wrote:
>
> 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?
>
> Yes, TomEE -- I based that on comments in the soteria code.
>
That's in this case clearly a TomEE bug, not a general problem with any
specification or integration.
>
> getCallerPrincipal() and isCallerInRole() are pretty straightforward. I
> was mostly thinking about container integration -- if injecting
> container-specific context objects is the approach, then we need to iterate
> over all the EE containers and make sure there's a context we can inject,
> and support for those operations, or we need to call that container out as
> an exception.
>
I think this is largely an implementation issue. Soteria is under no
obligation to support any other server than GlassFish, is it? Other servers
have to do their own integration, or, of course, implement the spec from
scratch and do everything their own way.
What about JMS? JCA? JMX? Or is this really just a Servlet/EJB context?
> Making sure we've covered all the bases, and working through any
> container-specific issues that come up, could take some time.
>
There's no truly spec compliant existing way to get the caller principal in
all cases, but clearly it's technically possible as it's possible in these
containers to obtain the caller principal. It "just" has to be done with
server specific (proprietary) code.
So with a small SPI interface (like e.g. the CDI RI (Weld) and the JSF RI
(Mojarra) also have) this should be possible.
I'll do a quick implementation of such an SPI in Soteria as a draft
proposal, so we can base further discussion on that.
>
> Beyond that, I think authenticate() has complexity that may or may not
> have been considered already. It looks to me like it's essentially exposing
> a programming API to JASPIC
>
That's not correct. ServletContext#authenticate() fully depends on
HttpServletRequest#authenticate(), it just adds a way to pass parameters
with that call and it provides a richer return value, but it's 100% based
on HttpServletRequest#authenticate().
> That may be fine, or it may expose conflicts between what JASPIC SCP says
> a container must do, and what we want it to do. It would also seem to make
> security more complex, not simpler, for applications, in that it's exposing
> the complexity of JASPIC, and some of its types
>
We discussed this before in the EG. Indeed, the return value is now
directly the JASPIC AuthStatus, but we can replace that with an enum that's
largely the same, but is owned by JSR 375 (so that there are no JASPIC
imports in the interface).
> , and it relies on being able to pass data back and forth between the
> configured SAM using HTTP request attributes; that's a reliable pipe, but
> the behavior of the API depends on the SAM understanding it there's an
> implied contract there.
>
A pure JSR 196 SAM is not supposed to pick up any of these parameters. They
are only supposed to be used in a portable way by a JSR 375 HAM and its
HttpMessageContext.
> Right, and again, I haven't had time to look carefully, but it looks like
> the authenticate() implementation relies on signaling between
> SecurityContext and whatever SAM(s) are configured, using HTTP request
> attributes to pass information back and forth. It also exposes the JASPIC
> message-processing model to the application, which must look for
> SEND_CONTINUE, SEND_SUCCESS, etc. and manage the dialog with the client
> itself (rather than allowing the container to do so).
>
In the programmatic variant in Servlet, as well as FORM, the application
must already handle some of these things.
In the Servlet version of authenticate(), the return values are true,
false, and exception. These basically stand for the same things. JSR 375
just gives them names, as true/false/exception is a bit obscure.
In other words, if an application triggers authentication, it must know if
authentication succeeded right away, failed, or that the container and/or
authentication module "took over" the response, so that the application is
not longer allowed to write to the response.
This is a bit different from the application actually actively
participating in the dialog. This is not the case here. The container
informs the application about a fairly high level outcome, but does not
give full control to the application code here.
> None of this is to say that it isn't a good idea, just that I think
> there's complexity there
>
What I think might be an open task here is taking away any potential
perception that there's (extra) complexity, since that should not be there.
It's 99.99% just naming and clarifying the existing outcomes of
HttpServletRequest#authenticate.
Hope this makes it a bit more clear ;)
Kind regards,
Arjan Tijms
> . Part of the problem is that I came on as spec lead late in the game, and
> missed whatever discussions you all have already had about this.
>
>
>
> 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 <%28781%29%20442-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
>
>