[javaee-spec users] Re: What about JACC?

From: arjan tijms <>
Date: Tue, 2 Dec 2014 18:44:30 +0100


On Tue, Dec 2, 2014 at 6:02 PM, Kevin Sutter <> wrote:
> Hi Arjan,
> I would agree that both JACC and JASPIC should be considered for possible
> "deprecation" as part of the new Security 1.0 JSR discussions
> (

While there are issues with JASPIC for sure, I don't think it should
be considered for deprecation at all. There's nothing really planned
in the Security API 1.0 to define a custom auth module, which is the
thing that implements an auth mechanism (not just a repository) via
which authentication takes place. The Security API does proposes a
replacement for the JAAS login module.

In general JASPIC auth modules in fact do work great. They basically
need some convenience APIs layered on top of them to make them easier
to use, a few artefacts in JASPIC need a default implementation and
things like CDI needs to be available before an auth module is called
by the container.

The first two things are something that the Security API can indeed
provide, while the latter may be a Servlet issue.

See this example for what a JASPIC auth module looks like with just a
few convenience methods added:

So, I think it's better to have the Security API use JASPIC as a lower
level foundation than have it invent what JASPIC already does right
all over again.

Kind regards,
Arjan Tijms

> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Kevin Sutter
> STSM, Java EE and Java Persistence API (JPA) architect
> mail:, Kevin Sutter/Rochester/IBM
> phone: tl-553-3620 (office), 507-253-3620 (office)
> arjan tijms <> wrote on 12/02/2014 09:33:37 AM:
>> From: arjan tijms <>
>> To: users <>
>> Date: 12/02/2014 09:34 AM
>> Subject: [javaee-spec users] What about JACC?
>> Hi,
>> I wonder what the general opinion here is about the status of JACC
>> in Java EE. Does anyone uses it or even knows of someone who uses it?
>> I've studied JACC for a while (see eg http://arjan-
>> ), but found the usability problems and gaps in the spec to be so
>> severe that I've almost never been able to actually use it in practice.
>> The promise of JACC remains attractive though; it's basically a
>> repository of all permissions related to Servlet auth constraints
>> and EJB method constrains (@RolesAllowed), where you can both query
>> the repo (eg "will the current user have access to this url"), and
>> programmatically hook into the permissions (eg "url x is accessible
>> to role y during week days).
>> Unfortunately JACC only specifies an SPI. There's no actual
>> repository present that portable code can rely on (a couple of
>> servers does ship with one, just not all). Furthermore if one wants
>> to install a JACC provider it has to be done at the JVM level, even
>> though authorization is often highly specific for a single app. This
>> makes it also nearly impossible to use JACC for cloud deployments.
>> To cut a very long story short, JACC could be really useful for many
>> types of applications, but currently it's not.
>> The usefulness of JACC could already be improved by simply layering
>> some convenience methods on top of it and providing a default
>> implementation that code can rely upon (this doesn't necessarily
>> have to be done in the JACC spec, the Security API could do this
>> too), but the JVM level issue can probably only be fixed within JACC
>> itself.
>> IMHO leaving JACC as-is at the moment is mostly adding deadweight to
>> the spec, but maybe I'm missing something.
>> What do people here think about this?
>> Kind regards,
>> Arjan Tijms