L'infrastructure par lots du profil Liberty
vous 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 à vos 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 travai 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 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
- 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.
- 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>
- 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>
- 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 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="olivier"/>
</security-role>
<security-role name="batchMonitor" >
<user name="joe" />
<user name="olivier"/>
</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="olivier"/>
</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="olivier"/>
</security-role>
<security-role name="batchMonitor" >
<special-subject type="EVERYONE"/>
</security-role>
</authorization-roles>