users@javaee-spec.java.net

[javaee-spec users] What about JACC?

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 2 Dec 2014 16:33:37 +0100

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-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html),
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