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

154
votes

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.

1
securityjakarta-eeglassfishauthorizationjacc
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... – perissf
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/… – Arjan Tijms
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. – Laird Nelson
@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. – jimhark
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. – Laird Nelson

1 Answers

3
votes

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.