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

From: Kevin Sutter <>
Date: Tue, 2 Dec 2014 11:02:59 -0600

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 (

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

> 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