Das Liberty-Stapelframework ermöglicht die Konfiguration rollenbasierter Zugriffe auf alle Stapelverwaltungsoperationen und bietet die Möglichkeit, Metadaten und Protokolle zu Ihren Stapeljobs anzuzeigen.
Vorbereitende Schritte
Für den Stapelcontainer sind drei Stapelrollen definiert. Ein einzelner Benutzer kann mehrere Stapelrollen haben.
- batchAdmin
- Ein Stapeladministrator, batchAdmin, hat unbeschränkten Zugriff auf alle Stapelverarbeitungsoperationen. Dazu gehört
die Berechtigung, neue Jobs zu übergeben,
die Jobs eines Benutzers zu stoppen und erneut zu starten,
Jobmetadaten und Jobprotokolle eines Benutzers in der Stapeldomäne anzuzeigen und beliebige Jobs zu löschen.
Ein Stapeladministrator (batchAdmin) ist nicht unbedingt ein
WebSphere Application Server-Administrator.
- batchSubmitter
- Ein batchSubmitter (Benutzer, der einen Stapel übergibt) hat die Berechtigung, neue Jobs zu übergeben. Er kann
nur Stapeloperationen für eigene Jobs ausführen, z. B. Jobs stoppen, erneut starten oder löschen.
Ein batchSubmitter kann die Jobs anderer Benutzer weder anzeigen noch ändern. Wenn z. B. Benutzer1 und Benutzer2
als batchSubmitter definiert sind und Benutzer1 einen Job übergibt, kann Benutzer2 die Jobinstanz, die dem Job von Benutzer1 zugeordnet ist, nicht anzeigen.
- batchMonitor
- Ein
batchMonitor (Benutzer, der einen Stapel überwacht) hat die Leseberechtigung für alle Jobs.
Benutzer mit dieser Rolle können alle Jobinstanzen und Ausführungen anzeigen und haben Zugriff
auf alle Jobprotokolle. Ein batchMonitor kann keine eigenen Jobs übergeben oder Jobs stoppen, erneut starten oder löschen.
Anmerkung: Wenn die Stapelsicherheit aktiviert ist,
wird jede
JobOperator-API-Methode oder REST-Operation, die eine Liste zurückgibt, basierend auf den Rollen für den aktuellen Benutzer gefiltert.
Wenn z. B.
ein Benutzer mit batchSubmitter-Berechtigung eine Liste mit allen Jobinstanzen anfordert, werden nur Jobinstanzen zurückgegeben, die vom aktuellen
Benutzer übergeben wurden.
Informationen zu diesem Vorgang
Vorgehensweise
- Mit dem Feature batch-1.0 ist standardmäßig keine Sicherheit aktiviert.
Die JobOperator-Methoden sind für alle Benutzer offen, unabhängig davon, ob diese authentifiziert oder nicht authentifiziert sind.
Die Methoden werden für Entwicklungszwecke offen gelassen und benötigen keine Sicherheitskonfiguration. Mit dem Feature
batchManagement-1.0 wird die Stapel-REST-API aktiviert.
Die REST-API erfordert immer eine Authentifizierung eines Benutzers, selbst dann, wenn das Feature
appSecurity-2.0 nicht aktiviert ist. Alle Benutzer werden jedoch als Stapeladministratoren behandelt und können
alle Stapeloperationen für jede Jobinstanz ausführen.
Sobald das Feature
appSecurity-2.0 aktiviert ist,
findet eine rollenbasierte Stapelsicherheitsberechtigung statt und die Benutzer dürfen nur die Stapeloperationen ausführen, die von ihren
Stapelrollen definiert sind.
- Aktivieren der rollenbasierten Stapelsicherheit über die JobOperator-API
<featureManager>
<feature>batch-1.0</feature>
<feature>appSecurity-2.0</feature>
</featureManager>
- Aktivieren der rollenbasierten Stapelsicherheit über die REST-API
Anmerkung: Das Feature
batchManagement-1.0 enthält das Feature batch-1.0.
<featureManager>
<feature>batchManagement-1.0</feature>
<feature>appSecurity-2.0</feature>
</featureManager>
- Konfigurieren Sie die Datei
server.xml für die Unterstützung der rollenbasierten Sicherheit. Das folgende Beispiel veranschaulicht eine Basisbenutzerregistry, die eine Liste mit Benutzern definiert.
Diese Registry wird von den folgenden rollenbasierten Stapelsicherheitskonfigurationen im Beispiel verwendet.
<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>
In diesem Beispiel hat ein Benutzer mehrere Rollen.
<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>
In diesem Beispiel hat ein Benutzer mehrere Rollen. Alle Benutzer haben die Rolle
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>
In diesem Beispiel hat ein Benutzer mehrere Rollen. Alle Benutzer, einschließlich derjenigen, die nicht authentifiziert sind,
dürfen die Rolle batchMonitor verwenden.
<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>