Hi Arjan,
On 03/19/2017 06:17 PM, arjan tijms wrote:
> Hi,
>
> On Sun, Mar 19, 2017 at 10:08 PM, Will Hopkins
> <will.hopkins_at_oracle.com <mailto: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.
OK, just wondered if it was an indication that the API might not be
completely portable.
> 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.
Well, yes and no. We aren't obligated to implement for every vendors'
server, but we do have an obligation to not specify something that would
extremely hard to implement in some vendors' containers. But I wasn't
thinking so much about other vendors as I was containers for other
application types.
> 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.
Sure, caller principal will be available; caller roles are probably less
certain, though, and, in any case, this is additional work that must be
done, at least for the Glassfish RI.
> So with a small SPI interface (like e.g. the CDI RI (Weld) and the JSF
> RI (Mojarra) also have) this should be possible.
A small SPI interface that's not currently specified. The concern I have
isn't that SecurityContext isn't feasible or a good idea, just that
completing it is a non-trivial effort.
> I'll do a quick implementation of such an SPI in Soteria as a draft
> proposal, so we can base further discussion on that.
OK. There are still open issues in HttpAuthenticationMechanism and
IdentityStore to consider as well ...
> 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().
I haven't had time to fully understand the implementation, but it
appeared to also depend on passing data back and forth between the
calling context and the configured SAM, which must understand the
implied contract and adhere to it. Some of the JASPIC types are exposed
(AuthStatus at a minimum), and the message-processing model (handling of
SEND_SUCCESS, SEND_FAILURE, and SEND_CONTINUE).
> 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.
Implying that SecurityContext.authenticate() is only usable when a HAM
is configured, which makes the API seem rather narrowly targeted.
> 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.
FORM is a special case; not sure what you mean by the programmatic
variant ....
> 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.
So the application is not expected to respond to SEND_CONTINUE, for
example, and prepare to continue the conversation by calling
authenticate() again on the next request? If so, why expose any of that
complexity? The semantics of the existing HSR.authenticate() call would
seem to be sufficient ...
> 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 ;)
It's getting there ... ;)
>
> 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 <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 <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