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.
batchGroupAdmin
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.
batchGroupMonitor
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
- 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.
- 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 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>
Remarque : Si la fonction
zosSecurity-1.0 est
activée, l'autorisation basée sur les rôles par lots est
traitée par le fournisseur d'autorisation SAF.
Le fournisseur d'autorisation SAF détermine l'autorisation
du client en vérifiant le niveau d'accès du client
dans les profils de ressource SAF définis dans la classe
EJBROLE. Par défaut, les profils de ressource suivants sont
associés aux rôles par lots.
batchAdmin: BBGZDFLT.com.ibm.ws.batch.batchAdmin
batchSubmitter: BBGZDFLT.com.ibm.ws.batch.batchSubmitter
batchMonitor: BBGZDFLT.com.ibm.ws.batch.batchMonitor
L'identité du client doit disposer de l'accès
READ au profil de ressource approprié afin d'être autorisé sur le
rôle par lots correspondant.
L'exemple suivant illustre les commandes RACF que vous devez utiliser pour accorder à l'identité client,
bob, une autorisation sur le rôle batchAdmin.
RDEFINE EJBROLE BBGZDFLT.com.ibm.ws.batch.batchAdmin UACC(NONE)
PERMIT BBGZDFLT.com.ibm.ws.batch.batchAdmin CLASS(EJBROLE) ID(bob) ACCESS(READ)