[javaee-spec users] Re: CDI support in JASPIC

From: arjan tijms <>
Date: Fri, 1 Feb 2013 00:10:33 +0100


On Thu, Jan 31, 2013 at 9:50 PM, Ron Monzillo <>wrote:
> Arjun is also correct that another core value proposition of the spi is
> that it provides for the integration of authentication
> agents within the servlet constraint processing and programming model; in
> a fashion analogous to the native
> required to be supported authentication mechanisms.

It's maybe a slightly different topic, but since these native
authentication mechanisms came up: what about requiring compliant Java EE
implementations in the future to implement these native mechanisms via

In that scenario, JASPIC would automatically be fully used, instead of
being a somewhat alternative API. These SAMs would not be portable of
course, since their implementation would still be vendor specific, but it
would mean users could work with them in the same way as custom JASPIC
SAMs. If additionally the class names of those SAMs would be standardized,
users could even stack or decorate them in a portable way.

> You can certainly bundle a SAM in you application, in which case, I think
> you would need to register an authconfigprovider for your app, and
> configure it with the auth module contained in your app, and I think you
> will need to do so, at the point where you application embedded sam is
> available for loading, and your application has not yet been initialized
> to receive requests.

Yes, this is exactly how I did this earlier. I blogged about it and some of
the issues I encountered here:

A big problem was which "appContext" identifier to use for the
registration. Maybe I'm missing something, but I couldn't find how to
portably compute this ID at the time of registration. From my article:

- start quote
Another hurdle is that the initial factory used for registering the
factory-factory requires an "appContext" identifier. This identifier is
specified to be either null, or be composed of the pattern [hostname]
[space] [context path]. When the identifier is null, the registration is
for all (web) applications, otherwise it's only for a specific one. Clearly
when an application registers its own internal authentication module the
latter form is needed. The problem is that this "hostname" part is not that
easy to guess when doing programmatic registration at startup time. It's
further defined as being a "logical host", but how does an app knows what
its own logical host is? The situation is further complicated by the fact
that all servers except JBoss EAP just use a constant here, which is simply
"server". JBoss EAP however uses
which is a value that's only available during request processing and not
during startup time. It seems likely that if internal application server
code is doing both the registration and the subsequent lookups, this is not
really a problem. The AS itself knows which key it used for registration
and can easily use the same one for lookups later. But when user code needs
to do a registration independent of the application server that later on
does the lookup, this becomes a problem. Maybe JBoss has interpreted the
spec wrongly and the logical host should really be the constant "server",
but then the spec needs to be clarified here. If it really should be a
logical host of some kind, then there also needs to be a way to express
that the application doesn't care about this (for example by specifying "*"
as a kind of bind-all). As it stands, the situation is highly confusing.
- end quote

> I think we should take a closer look at why the configuration has been
> difficult. In the JAAS based auth config provider that I mentioned. All one
> needs to do is
> add a config entry to a jaas config file, a default can be defined to
> cover all other apps. And jsr 196 also provides the ability to say that for
> some apps, the jaas config
> and its default do not apply.

Which JAAS based auth config provider is that exactly? If this config
provider is by default available in a Java EE implementation and the
mentioned config file can be embedded in the application archive, then it
might indeed sound like a solution.

The difficulty in the traditional vendor specific approach is mostly that
when a (new) user has to do this, he or she can't just read a Java EE text
book and apply that knowledge step by step. At some point a switch is
needed to some vendor specific documentation, which typically means wading
through several documents. For experienced users this might no be so big of
a deal (though it's often still a tedious job to find the right info for an
AS you aren't acquainted with), but it's a quite intimidating step for new

As for the Java EE 7 JASPIC MR issues (which came up at the JBoss site), I
hope the following would be possible:

- Clarify that HttpServletRequest#login is not supported by JASPIC for the
moment. An exception should be thrown instead of an invocation of some
default unrelated login module. If it would be possible to specify how
JASPIC can really handle HttpServletRequest#login then this would be even

- Clarify what should happen for HttpServletRequest#authenticate. JASPIC
implementations all seem to do the right thing already, but it's not in the

- An API or perhaps just a clarification for the appContext identifier, so
an application can portably register an AuthConfigProvider just for itself.

- Perhaps be more explicit about the fact that an application can register
such an AuthConfigProvider for itself, and then if it does it should run in
the same class loader as the application that registered it (most servers
already do this).

- Specify more clearly what the AS for the Servlet profile should or should
not 'remember' after a successful authentication between http request.
Various servers that I looked at behaved quite differently here (see the
above referenced blog).

Things that might be too big for a MR, but would all be great:

- A portable way to programmatically just register a SAM. Now application
code has to go through an AuthConfigProvider, ServerAuthConfig
and ServerAuthContext just to register a ServerAuthModule. The current way
is doable and gives the user great flexibility, but sometimes all that's
needed is to register that SAM, and then this is perhaps all a bit too much.

- A declarative standardized way to register just a SAM; for the Servlet
Profile, web.xml and optionally an annotation (like @DataSourceDefinition)
would be most suitable.

- Update of all APIs to use at least Java 5 syntax. Just using generics for
the various maps in the SPI would be a great start.

Thanks again for looking into this!

Kind regards,
Arjan Tijms