jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] SecurityContext#hasAccessToResource

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Wed, 2 Dec 2015 10:19:11 +0100

Hi

For the planned SecurityContext (
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12) I envisioned among
others a method that can be used to check if the current caller will have
access to a specific resource.

E.g.

@Inject SecurityContext context;

boolean access = context.hasAccessToResource("/experts/drafts");

The use case for this method is e.g. not rendering links that a user does
not have access to, without having to duplicate the knowledge of which role
has access to which URL pattern in the rendering code. This is an often
requested feature and in response we have implemented a version of it in
OmniFaces by manually parsing web.xml.

Naturally the (web) container internally already implements such
functionality, since it needs to call exactly this when doing the
authorization check when the resource is actually requested.

I asked the Servlet EG to expose this method:
https://java.net/jira/browse/SERVLET_SPEC-61

The spec lead (Shing Wai) remarked that it can already be done via a
WebResourcePermission in JACC. This is by itself true. Although the
necessary code doesn't look so nice, it can be hidden away in a utility
method like this one:
https://github.com/javaee-samples/javaee7-samples/blob/master/jaspic/jacc-propagation/src/main/java/org/javaee7/jaspic/jaccpropagation/jacc/JACC.java#L35

The problem is however, as mentioned in the comments on SERVLET_SPEC-61,
that even though that code should be portable for full Java EE
implementations, in practice vendors have set up their servers in such a
way that it doesn't work.

For instance, in WebLogic the API that this code relies on has to be
activated first in a proprietary way outside the application. In Liberty
the necessary API implementation is completely missing (Liberty only allows
custom JACC providers, but omits shipping the required default one). On
JBoss (WildFly) it should theoretically work, but in practice doesn't
because of 2 severe bugs.

There are a couple of ways to solve this problem:

1. Ask the vendors to solve the current implementation problems so the
existing WebResourcePermission check works in a default container config
2. Ask the Servlet EG to expose their internal "hasAccess" method in a
portable way anyway
3. Something else?

As we have representatives from the various vendors on this EG I feel 1.
should not have to be impossible, it is after al what the spec already
mandates.

Thoughts?

Kind regards,
Arjan Tijms