I agree beyond some due diligence the RI need not work with every implementation on day one. I don't know of any RI that actually makes effort to ensure that. Maybe Jersey? It's definitely not required from a JCP standpoint.
-------- Original message --------From: arjan tijms <arjan.tijms_at_gmail.com> Date: 3/19/17 6:17 PM (GMT-05:00) To: jsr375-experts_at_javaee-security-spec.java.net Subject: [javaee-security-spec users] [jsr375-experts] Re: Drop SecurityContext from the spec?
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
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
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803