Configuration de l'autorisation pour les applications dans le profil 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 de profil 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

  1. Activez la fonction Liberty appSecurity-2.0 dans le fichier server.xml.
    Exemple :
        <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
  2. Configurez un registre d'utilisateurs pour l'authentification sur le serveur de profil Liberty.

    Voir Authentification des utilisateurs dans le profil Liberty.

  3. 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.
  4. 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" />

    Un rôle peut être mappé à un utilisateur, un groupe ou un sujet spécial. Les deux types de sujet spécial sont EVERYONE et ALL_AUTHENTICATED_USERS. Lorsqu'un rôle est mappé au sujet spécial EVERYONE, la sécurité est inexistante, car tous les utilisateurs sont autorisés à accéder à la ressource sans qu'il leur soit demandé de justificatifs. Lorsqu'un rôle est mappé avec le sujet spécial ALL_AUTHENTICATED_USERS, tout utilisateur qui a été authentifié par le serveur d'application peut accéder à la ressource protégée.

    Voici un exemple de code réalisant le mappage de rôles à des utilisateurs et des groupes dans le fichier server.xml :
    <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.


Icône indiquant le type de rubrique Rubrique Tâche

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_sec_rolebased
Nom du fichier : twlp_sec_rolebased.html