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

Trois 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 rôle batchAdmin 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
Un rôle batchMonitor dispose de droits en 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. Un rôle batchMonitor ne peut pas soumettre ses propres travaux, ni arrêter, redémarrer ou purger des travaux.
Remarque : Lorsque 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 ne disposant que de rôles batchSubmitter demande une liste de toutes les instances de travail, seules les instances de travail soumises par l'utilisateur en cours sont renvoyées.

Pourquoi et quand exécuter cette tâche

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 toujours traités en tant qu'administrateurs par lots et peuvent effectuer toutes les opérations de traitement 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 suivants de configuration de la sécurité basée sur les rôles 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



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_batch_securing
Nom du fichier : twlp_batch_securing.html