How can a JACC provider use the Principal-to-role mapping facilities of the server it's deployed on?

Question

I am writing a JACC provider.

Along the way, this means implementing a PolicyConfiguration.

The PolicyConfiguration is responsible for accepting configuration information from the application server, such as which permissions accrue to which roles. This is so that a Policy later on can make authorization decisions when handed information about the current user and what he's trying to do.

However, it is not part of the PolicyConfiguration's (atrocious) contract to maintain a mapping between roles and their permissions, and Principals that are assigned to those roles.

Typically--always, really--an application server houses this mapping. For example, on Glassfish, you affect this mapping by supplying things like sun-web.xml and sun-ejb-jar.xml and so on with your Java EE modules. (These vendor-specific files are responsible for saying, e.g., superusers is a group that is to be assigned the application role of admins.)

I would like to reuse the functionality these files supply, and I would like to do so for as wide an array of application servers as possible.

Here is--totally arbitrarily--IBM's take on the matter, which appears to confirm my suspicion that what I want to do is essentially impossible. (More ammunition for my case that this particular Java EE contract is not worth the paper it's printed on.)

My question: how do I get at this principal-to-role-mapping information in--for starters--Glassfish and JBoss from within a PolicyConfiguration? If there's a standard way to do it that I'm unaware of, I'm all ears.

Elemi

Have you made any progress on this issue? I'd like to write a JACC provider too, and also a JASPIC authentication provider in order to build portable web applications... – Maynardmayne

This doesn't sound very promising either: Because JSR-115 does not define how to address role mapping, WebLogic JACC classes are used for role-to-principal mapping. See docs.oracle.com/cd/E24329_01/web.1211/e24485/… – Mothy

My take on this at the moment is that you have to always make sure your JACC provider is coupled to a JASPIC provider that you are therefore also obligated to write. I haven't gone this route yet but it's on my table to try. – Elemi

@LairdNelson, if you have time, you should probably write up an answer around your JASPIC comment. This sounds promising, and there's a 300 reputation bounty on this question. – Hundredweight

It would be interesting to see what you have in mind with the JASPIC/JACC combo. As far as I can see, with JASPIC you use a GroupPrincipalCallback which normally suffers from the same mandatory role mapping. But if JACC can do something here that it can't do for a proprietary module, then it would be interesting to share. – Mothy

Hi; not trying to keep anyone in suspense. :-) I don't have an answer here that I could whip up in a hurry. I just recall Ron Monzillo advising me that the only way to get principal-to-role assignments "into" a JACC provider in a way that it can understand is to have the JASPIC implementation effectively coupled to it. – Elemi

you could simply parse the config file, but that would limit you to a specific application server, and/but it might be possible to determine which server you run on, or check for the different files... – Pieria

Have you tried here? – Capel

One more piece of information related to this. From the JEUS 7 security manual: The JACC interface does not contain any implementation related to principal-to-role mapping, but only for role-to-resource mapping. The user must implement a separate JEUS-specific interface to implement the mapping, and JEUS provides the isjeus.security.impl.aznrep.JACCPrincipalRoleMapper interface for this purpose. – Mothy

Looking at JACC anew I wonder if we could do something like this in the specification without requiring new code or even a maintenance release: What If It Were Mandated that if you passed in a delimited set of principal names as a String to PolicyContext#getContext(String) and were assured that you would get back a Set<String> of corresponding roles if there were an appropriate policy context handler installed for that key? No new interfaces, no backwards compatibility issues. No grosser than the existing String parsing that is already required for EJBMethodPermission. – Elemi

Answer 1

The short answer is: there's no standard way to do it.

Although Glassfish and JBoss support principal-to-role mappings, JACC does no assume all containers do, and so it delegates the responsibility of keeping those mappings to the JACC provider implementation. From the docs (see: PolicyConfiguration.addToRole method):

It is the job of the Policy provider to ensure that all the permissions added to a role are granted to principals "mapped to the role".

In other words, you need to implement that yourself inside your JACC provider for each container. For JBoss, for example, you could use one of the subclasses of AbstractRolesMappingProvider.

Karakoram

As an aside, a portable provider could choose to ignore container role mapping; it could e.g assume that any principal implies an application role of the same name, unless the application somehow (via a PolicyContextHandler specifically registered by the provider for that purpose, for instance) conveys otherwise. Another provider could as well disregard the notion of roles altogether (and hence the container-provided PolicyConfiguration), instead operating solely on (application-provided) principal-to-permission mappings (and where those permissions need not be limited to JACC's ones). – Rainey

Side note #2: As of Java EE 8, 1:1 group-to-role mapping has become the new default (which however only gets us halfway there, as roles must still be statically declared upfront -- assuming no custom JACC provider is in effect). – Rainey