users@javaee-spec.java.net

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

From: Kevin Sutter <sutter_at_us.ibm.com>
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 (
http://jcp.org/en/jsr/detail?id=375).

----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter
STSM, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/
 

arjan tijms <arjan.tijms_at_gmail.com> wrote on 12/02/2014 09:33:37 AM:

> From: arjan tijms <arjan.tijms_at_gmail.com>
> To: users <users_at_javaee-spec.java.net>
> 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-
> 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