Configuration de l'autorisation pour les applications dans Liberty
Le but de la configuration de l'autorisation pour une application est de vérifier si un utilisateur ou un groupe appartient à un rôle spécifique et si ce rôle a le droit (ou le privilège) de demander une ressource fournie par cette application.
Pourquoi et quand exécuter cette tâche
Le serveur Liberty extrait les informations de mappage d'utilisateur et de groupe depuis un registre d'utilisateurs, puis consulte la configuration des autorisations pour l'application afin de déterminer si un utilisateur ou un groupe est associé à l'un des rôles requis. Le serveur lit ensuite le descripteur de déploiement de l'application pour déterminer si l'utilisateur ou le groupe a le droit d'accéder à la ressource qu'il demande.
Procédure
- Activez la fonction
appSecurity-2.0
Liberty dans le fichier server.xml. Exemple :
<featureManager> <feature>appSecurity-2.0</feature> </featureManager>
- Configurez un registre d'utilisateurs pour l'authentification sur le serveur Liberty.
- Assurez-vous que le descripteur de déploiement de votre application inclut
des contraintes de sécurité et d'autres informations en rapport avec la sécurité. Remarque : Vous pouvez aussi utiliser un outil tel que Rational Application Developer pour créer le descripteur de déploiement.
- Configurez les informations d'autorisation telles que le mappage d'un utilisateur et d'un groupe à un rôle. Vous pouvez configurer la table d'autorisations de différentes manières :
- Si vous possédez un fichier EAR, vous pouvez ajouter la définition de configuration d'autorisation dans le fichier ibm-application-bnd.xml ou ibm-application-bnd.xmi.
- Si vous avez des fichiers WAR autonomes, vous pouvez ajouter les définitions de la table d'autorisations au fichier server.xml, sous l'élément 'application' approprié. Vous pouvez utiliser WebSphere Application Server Developer Tools for Eclipse à cet effet.
Remarques :- Si vous possédez un fichier EAR, il se peut que la configuration des autorisations existe déjà. Dans les fichiers EAR écrits selon la spécification actuelle, ces informations sont stockées dans un fichier ibm-application-bnd.xml ; dans les fichiers EAR plus anciens, elles sont stockées dans un fichier ibm-application-bnd.xmi.
- Si votre fichier EAR ne contient pas de fichier ibm-application-bnd.xm* et la création d'un tel fichier étant complexe, il est recommandé d'ajouter la configuration des autorisations au fichier server.xml.
- Si la configuration des autorisations pour le fichier EAR est définie à la fois dans un fichier ibm-application-bnd.xm* et dans le fichier server.xml, les deux tables sont fusionnées. Si des conflits sont générés, les informations provenant du fichier server.xml sont utilisées.
- Si vous modifiez votre registre d'utilisateurs, veillez à passer en revue la table d'autorisations pour y appliquer les changements nécessaires. Par exemple, en supposant qu'un élément access-id soit spécifié, si vous changez le nom de domaine du registre, vous devez penser à répercuter ce changement dans l'élément access-id.
- Si vous spécifiez l'élément application-bnd dans le fichier server.xml, votre application ne doit pas se trouver dans le dossier dropins. Si vous la laissez dans le dossier dropins, vous devez désactiver la surveillance des applications comme suit dans le fichier server.xml :
<applicationMonitor dropinsEnabled="false" />
A role can be mapped to a user, a group, or a special subject. The two types of special subject are EVERYONE and ALL_AUTHENTICATED_USERS. When a role is mapped to the EVERYONE special subject, there is no security because everyone is allowed access and you are not prompted to enter credentials. When a role is mapped to the ALL_AUTHENTICATED_USERS special subject, then any user who is authenticated by the application server can access the protected resource.
Here is example code for configuring the user and group to role mapping in the server.xml file:<application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war"> <application-bnd> <security-role name="user"> <group name="students" /> </security-role> <security-role name="admin"> <user name="gjones" /> <group name="administrators" /> </security-role> <security-role name="AllAuthenticated"> <special-subject type="ALL_AUTHENTICATED_USERS" /> </security-role> </application-bnd> </application>
Dans cet exemple, le rôle admin est mappé à l'ID utilisateur gjones et à tous les utilisateurs membres du groupe administrators. Le rôle AllAuthenticated est mappé au sujet spécial ALL_AUTHENTICATED_USERS, ce qui signifie qu'un utilisateur a accès à l'application dès lors qu'il est authentifié en fournissant des justificatifs valides.
- Facultatif : Configurez une décision d'autorisation si aucune information de liaison d'application n'existe. Si les informations de liaison des mappages de rôles d'une application protégée ne sont pas fournies, le moteur d'autorisation par défaut utilise le nom de rôle qui protège la ressource en tant que nom de groupe associé à ce rôle. Par exemple, si le nom de rôle est manager, un utilisateur appartenant à un groupe de gestionnaires a accès à cette ressource. Ceci s'applique uniquement si aucune information de liaison d'application, dans le fichier server.xml ou le fichier de liaison d'application, n'est spécifiée pour l'application. Par exemple, l'ajout de cette liaison désactive la liaison du rôle de sécurité au groupe :
<application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war"> <application-bnd> <security-role name="anyAppRoleName"/> </application-bnd> </application>
Remarque : Pour qu'une autorisation réussisse avec un nom de groupe dans le registre utilisateur, le nom de rôle doit correspondre au nom unique ou complet du groupe dans le registre qui est configuré et non au nom abrégé. Par exemple, si le nom abrégé du groupe est swGroup mais le nom unique ou complet figurant dans le registre utilisateur est CN=swGroup,o=company,c=us, vous devez spécifier CN=swGroup,o=company,c=us comme nom de rôle pour que l'autorisation réussisse.

Nom du fichier : twlp_sec_rolebased.html