Some comments ...
On 03/18/2017 07:15 PM, arjan tijms 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?
At this point I don't think there's any chance we can add more -- see my
other email re: timeframes.
> 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.
All of that stuff would be good to discuss, but at this point we're
bound to the EE 8 schedule, which requires us to be done (Final Ballot
finished, RI and TCK implementation and documentation done) by July 10,
2017.
> >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?
Yes, TomEE -- I based that on comments in the soteria code.
> >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.
Well, it's hard to estimate. There's how long it might take one engineer
to make the necessary decisions, code, and document, and there's how
long it would take a committee to agree, and how much participation we
can expect from the EG in terms of coding, authoring, etc. A logistical
problem for Oracle is that the people doing RI and TCK work need to be
finished a little before JSR spec is finished, but also need solid spec,
API, and RI code to work with for their development.
> 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?
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. 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.
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, whereas the Servlet Container
Profile was defined exclusively in terms of internal integration with
the servlet container. 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, 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.
I haven't had time to look at the implementation carefully side-by-side
with the JASPIC spec -- perhaps it all hangs together really well -- but
there are more open questions for SecurityContext than there are for
HttpAuthenticationMechanism and IdentityStore, where the
implementation/integration choices seem, to me, more straightforward and
obvious.
> >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).
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).
None of this is to say that it isn't a good idea, just that I think
there's complexity there. 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
Oracle Application Development
35 Network Drive, Burlington, MA 01803