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.

For z/OS platformsLorsque vous utilisez l'autorisation SAF (System Authorization Facility), les rôles sont mappés aux profils de ressource EJBROLE au moyen du mappeur de rôles SAF. Le serveur interroge SAF pour déterminer si l'utilisateur a l'accès READ requis sur le profil de ressource EJBROLE.

Procédure

  1. Activez la fonction appSecurity-2.0 Liberty dans le fichier server.xml.
    Exemple :
        <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
    For z/OS platformsRemarque :
    • Si vous utilisez le fournisseur d'autorisation SAF, incluez la fonction zosSecurity-1.0 et définissez un élément de configuration safAuthorization dans votre fichier server.xml. Exemple :
       <featureManager>
           <feature>appSecurity-2.0</feature>
           <feature>zosSecurity-1.0</feature>
       </featureManager> 
      
       <safAuthorization id="saf" />
  2. Configurez un registre d'utilisateurs pour l'authentification sur le serveur Liberty.

    Voir Authentification des utilisateurs dans Liberty.

    For z/OS platformsSi vous utilisez le fournisseur d'autorisation SAF, vous devez utiliser également le registre SAF et le serveur doit être autorisé à utiliser les services autorisés SAF. Voir Activation et configuration du registre SAF sur z/OS.

  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 sujets spéciaux sont EVERYONE et ALL_AUTHENTICATED_USERS. Lorsqu'un rôle est mappé au sujet spécial EVERYONE, il n'y a aucune sécurité car tout le monde est autorisé à accéder et vous n'êtes pas invité à entrer vos données d'identification. Lorsqu'un rôle est mappé au sujet spécial ALL_AUTHENTICATED_USERS, tout utilisateur authentifié par le serveur d'application peut accéder à la ressource protégée.

    Voici un exemple de code configurant l'utilisateur et le groupe à une mappage de rôle 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.

    For z/OS platformsRemarque : Lorsque vous activez l'autorisation SAF, vous ne pouvez pas utiliser les sujets spéciaux ALL_AUTHENTICATED_USERS et EVERYONE.
    For z/OS platforms Si vous utilisez l'autorisation SAF, les rôles sont mappés aux profils de ressource EJBROLE au moyen du mappeur de rôles SAF. Le motif utilisé par mappeur de rôles SAF peut être configuré à l'aide de l'élément safRoleMapper dans le fichier server.xml. Voir Liberty : Contrôle de la manière dont les rôles sont mappés aux profils SAF. Par défaut, le rôle est mappé à un profil de ressource dont le nom a le format préfixe_profil.ressource.rôle, où :
    • préfixe_profil est défini par l'attribut profilePrefix de l'élément de configuration safCredentials. Par défaut, la valeur de l'attribut profilePrefix est BBGZDFLT.
    • ressource est le nom de la ressource ; par exemple, le nom de l'application.
    • rôle est le nom du rôle.
    Pour accéder à la ressource protégée, l'utilisateur doit avoir un accès READ sur le profil de ressource EJBROLE. Par exemple, pour que l'ID utilisateur gjones puisse accéder à une ressource protégée sous le rôle admin, si cette ressource est une application nommée myapp, l'utilisateur gjones doit avoir un accès READ sur le profil de ressource BBGZDFLT.myapp.admin de la classe EJBROLE dans le produit SAF.
    Remarque : Les profils de ressources EJBROLE sont sensibles à la casse.
    Voici des exemples de commandes RACF permettant d'autoriser un utilisateur :
    rdef EJBROLE BBGZDFLT.myapp.admin uacc(none)
    permit BBGZDFLT.myapp.admin class(EJBROLE) access(read) id(gjones)
  5. 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 conséquent, si le nom du rôle est manager par exemple, un utilisateur appartenant à un groupe manager peut accéder à 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.

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

Nom du fichier : twlp_sec_rolebased.html