Sécurisation de l'environnement de traitement par lots Liberty

L'infrastructure par lots de Liberty permet de configurer un accès basé sur les rôles à toutes les opérations de gestion par lots, mais aussi d'afficher les métadonnées et les journaux associés aux travaux par lots.

Avant de commencer

Des rôles par lots sont définis par le conteneur de lots. Un seul utilisateur peut avoir plusieurs rôles par lots.
batchAdmin
Un rôle batchAdmin a un accès non restreint à toutes les opérations de traitement par lots. Cela inclut le droit de soumettre de nouveaux travaux, d'arrêter et de redémarrer les travaux d'un utilisateur, d'afficher des métadonnées de travail et des journaux de travaux qui sont soumis par un utilisateur dans le domaine par lots et de purger des travaux. Un utilisateur batchAdmin n'est pas nécessairement un administrateur WebSphere Application Server.
[18.0.0.1 and later]batchGroupAdmin
[18.0.0.1 and later]Si des utilisateurs détiennent le rôle batchGroupAdmin et sont membres du groupe d'opérations dans lequel les travaux sont affectés, ils peuvent accéder à toutes les opérations de traitement par lots relatives à ces travaux. Les utilisateurs qui détiennent le rôle batchGroupAdmin peuvent arrêter, répéter, redémarrer et afficher n'importe quel travail, mais ils ne peuvent pas soumettre de nouveaux travaux sauf s'ils détiennent également le rôle batchSubmitter. Un utilisateur batchGroupAdmin peut afficher des métadonnées de travail et des journaux de travail, ainsi que des travaux de purge qui ont été soumis par d'autres utilisateurs du même groupe d'opérations. Un utilisateur batchGroupAdmin n'est pas nécessairement un administrateur WebSphere Application Server.
batchSubmitter
Un rôle batchSubmitter a le droit de soumettre de nouveaux travaux et peut uniquement effectuer des opérations de traitement par lots, comme l'arrêt, le redémarrage ou la purge de ses propres travaux. Il ne peut pas afficher ou modifier les travaux d'autres utilisateurs. Par exemple, si user1 et user2 sont définis avec le rôle batchSubmitters, et si user1 soumet un travail, user2 ne peut pas afficher les données d'instance de travail qui sont associées au travail de user1.
batchMonitor
Les utilisateurs disposant du rôle batchMonitor possèdent des droits de lecture seule sur tous les travaux. Les utilisateurs ayant ce rôle peuvent afficher toutes les instances et exécutions de travail et ils ont accès à tous les journaux de travail. Les utilisateurs possédant le rôle batchMonitor ne peuvent pas soumettre leurs propres travaux, ni arrêter, redémarrer ou purger des travaux.
[18.0.0.1 and later]batchGroupMonitor
[18.0.0.1 and later]Un utilisateur batchGroupMonitor possède des droits d'accès en lecture seule sur tous les travaux qui sont associés au groupe d'opérations auquel l'utilisateur appartient. Les utilisateurs ayant ce rôle peuvent afficher toutes les instances et exécutions de travail et ils ont accès à tous les journaux de travail relatifs aux journaux inclus dans la portée de leur groupe d'opérations. Un utilisateur batchGroupMonitor ne peut pas soumettre, arrêter, redémarrer ou purger des travaux.
Remarque : Une fois que la sécurité par lots est activée, toute méthode d'API JobOperator ou opération REST qui renvoie une liste est filtrée en fonction des rôles par lots accordés à l'utilisateur en cours. Par exemple, lorsqu'un utilisateur possédant uniquement des droits batchSubmitter demande une liste de toutes les instances de travail, seules les instances de travail soumises par l'utilisateur en cours sont renvoyées.

Procédure

  1. Par défaut, la fonction batch-1.0 n'active aucune sécurité. Les méthodes JobOperator demeurent ouvertes pour tous les utilisateurs qu'ils soient ou non authentifiés. Les méthodes sont laissées ouvertes à des fins de développement uniquement et elles ne requièrent aucune configuration de sécurité. La fonction batchManagement-1.0 active l'API REST par lots. L'API REST exige toujours qu'un utilisateur s'authentifie même lorsque la fonction appSecurity-2.0 n'est pas activée, cependant tous les utilisateurs sont traités en tant qu'administrateurs par lots et peuvent effectuer toutes les opérations par lots sur n'importe quelle instance de travail. Une fois que la fonction appSecurity-2.0 est activée, l'autorisation de sécurité basée sur les rôles est effectuée et les utilisateurs sont limités aux opérations par lots définies par les rôles par lots qui leur sont affectés.
    1. Activez la sécurité basée sur les rôles par lots via l'API JobOperator.
      <featureManager>
      	<feature>batch-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
    2. Activez la sécurité basée sur les rôles par lots via l'API REST.
      Remarque : La fonction batchManagement-1.0 inclut la fonction batch-1.0.
      <featureManager>
      	<feature>batchManagement-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
  2. Configurez votre fichier server.xml pour la prise en charge de la sécurité basée sur les rôles. L'exemple ci-après illustre un registre d'utilisateurs basique de base qui définit une liste d'utilisateurs. Ce registre est utilisé par les exemples de configurations des paramètres de sécurité basées sur des rôles de traitement par lots :
    <basicRegistry id="basic" realm="ibm/api">
    	<user name="alice" password="alicepwd" />
    	<user name="bob" password="bobpwd" />
    	<user name="jane" password="janepwd" />
    	<user name="joe" password="joepwd" />
    	<user name="phyllis" password="phyllispwd" /> 
    	<user name="kai" password="kaipwd" />
    </basicRegistry>

    Dans cet exemple, un utilisateur occupe plusieurs rôles.

    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<user name="jane" />
    		<user name="phyllis" />
    		<user name="bob" />
    	</security-role>
    	<security-role name="batchMonitor" >
    		<user name="joe" />
    		<user name="bob" />
    	</security-role>
    </authorization-roles>
    Dans cet exemple, un utilisateur occupe plusieurs rôles. Tous les utilisateurs ont le rôle batchSubmitter.
    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<special-subject type="ALL_AUTHENTICATED_USERS"/>
    	</security-role>
    	<security-role name="batchMonitor" >
    		<user name="joe" />
    		<user name="bob" />
    	</security-role>
    </authorization-roles>
    Dans cet exemple, un utilisateur occupe plusieurs rôles. Tous les utilisateurs, y compris ceux qui ne sont pas authentifiés, sont autorisés à avoir le rôle batchMonitor.
    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<user name="joe" />
    		<user name="bob" />
    	</security-role>
    	<security-role name="batchMonitor" >
    		<special-subject type="EVERYONE"/>
    	</security-role>
    </authorization-roles>

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

Nom du fichier : twlp_batch_securing.html