Comment un fournisseur JACC peut-il utiliser les fonctionnalités de mappage principal-rôle du serveur sur lequel il est déployé?

154

J'écris un JACCfournisseur.

En cours de route, cela signifie mettre en œuvre un PolicyConfiguration.

Le PolicyConfigurationest responsable de l'acceptation des informations de configuration du serveur d'applications, telles que les autorisations accordées à quels rôles. Ceci afin qu'un Policyplus tard puisse prendre des décisions d'autorisation lorsqu'il lui est remis des informations sur l'utilisateur actuel et ce qu'il essaie de faire.

Cependant, il ne fait pas partie du PolicyConfigurationcontrat (atroce) de maintenir un mappage entre les rôles et leurs permissions, et Principalsqui sont assignés à ces rôles.

En règle générale - toujours, vraiment - un serveur d'applications héberge ce mappage. Par exemple, sur Glassfish, vous affectez cette cartographie en fournissant des choses comme sun-web.xmlet sun-ejb-jar.xmlet ainsi de suite avec vos modules Java EE. (Ces fichiers spécifiques au fournisseur sont chargés de dire, par exemple, superusersest un groupe auquel le rôle d'application doit être attribué admins.)

Je voudrais réutiliser les fonctionnalités fournies par ces fichiers, et je voudrais le faire pour un éventail de serveurs d'applications aussi large que possible.

Voici - de manière totalement arbitraire - l'opinion d'IBM sur la question, qui semble confirmer mon soupçon que ce que je veux faire est essentiellement impossible . (Plus de munitions pour mon cas que ce contrat Java EE ne vaut pas le papier sur lequel il est imprimé.)

Ma question: comment puis-je obtenir ces informations de mappage principal-rôle dans - pour commencer - Glassfish et JBoss à partir d'un PolicyConfiguration? S'il y a une façon standard de le faire que je ne connais pas, je suis toute oreille.

security jakarta-ee glassfish authorization jacc Laird Nelson
la source
7
Avez-vous fait des progrès sur cette question? J'aimerais aussi écrire un fournisseur JACC, et aussi un fournisseur d'authentification JASPIC afin de créer des applications Web portables ...
perissf
Cela ne semble pas très prometteur non plus: Because JSR-115 does not define how to address role mapping, WebLogic JACC classes are used for role-to-principal mapping.voir docs.oracle.com/cd/E24329_01/web.1211/e24485/…
Arjan Tijms
2
Mon opinion à ce sujet pour le moment est que vous devez toujours vous assurer que votre fournisseur JACC est associé à un fournisseur JASPIC que vous êtes donc également obligé d'écrire. Je n'ai pas encore emprunté cette voie mais c'est sur ma table d'essayer.
Laird Nelson
@LairdNelson, si vous avez le temps, vous devriez probablement rédiger une réponse autour de votre commentaire JASPIC. Cela semble prometteur, et il y a une prime de 300 réputation sur cette question.
jimhark
5
Salut; ne pas essayer de garder qui que ce soit en haleine. :-) Je n'ai pas de réponse ici que je pourrais préparer à la hâte. Je me souviens juste que Ron Monzillo m'avait dit que la seule façon d'obtenir des attributions de principal à rôle "dans" un fournisseur JACC d'une manière qu'il puisse comprendre est d'avoir l'implémentation JASPIC effectivement couplée à celui-ci.
Laird Nelson

Réponses:

3

La réponse courte est: il n'y a pas de méthode standard pour le faire.

Bien que Glassfish et JBoss prennent en charge les mappages principal-rôle, JACC ne suppose pas que tous les conteneurs le font, et délègue donc la responsabilité de conserver ces mappages à l'implémentation du fournisseur JACC. À partir de la documentation (voir: PolicyConfiguration.addToRoleméthode ):

Il incombe au fournisseur de stratégie de s'assurer que toutes les autorisations ajoutées à un rôle sont accordées aux principaux «mappés sur le rôle».

En d'autres termes, vous devez l'implémenter vous-même dans votre fournisseur JACC pour chaque conteneur. Pour JBoss, par exemple, vous pouvez utiliser l'une des sous-classes de AbstractRolesMappingProvider.

Diego
la source
En passant, un fournisseur portable pourrait choisir d'ignorer le mappage de rôle de conteneur; il pourrait par exemple supposer que n'importe quel principal implique un rôle d'application du même nom, à moins que l'application d'une manière ou d'une autre (via un PolicyContextHandlerenregistrement spécifiquement enregistré par le fournisseur à cette fin, par exemple) n'indique le contraire. Un autre fournisseur pourrait également ignorer complètement la notion de rôles (et donc celui fourni par le conteneur PolicyConfiguration), fonctionnant uniquement sur les mappages principal à autorisation (fournis par l'application) (et lorsque ces autorisations ne doivent pas être limitées à celles de JACC).
Uux
Note d'accompagnement n ° 2: à partir de Java EE 8, le mappage de groupe à rôle 1: 1 est devenu la nouvelle valeur par défaut (ce qui ne nous amène cependant qu'à mi-chemin, car les rôles doivent toujours être déclarés statiquement à l'avance - en supposant qu'aucun fournisseur JACC personnalisé n'est en effet).
Uux