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
Der Stapelcontainer definiert Stapelrollen. 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.
batchGroupAdmin
Wenn Benutzer die Rolle "batchGroupAdmin" haben und Mitglieder der Operationsgruppe sind, der die Jobs zugeordnet sind, können Sie auf alle Stapeloperatoinen für diese Jobs zugreifen. Benutzer mit der Rolle "batchGroupAdmin" können jeden beliebigen Job stoppen, wiederholen, erneut starten und anzeigen. Sie können jedoch keine neuen Jobs übergeben, es sei denn, sie haben auch die Rolle "batchSubmitter". Ein Benutzer mit der Rolle "batchGroupAdmin" kann Jobmetadaten und Jobprotokolle sowie Löschjobs anzeigen, die andere Benutzer in derselben Operationsgruppe übergeben haben. Ein Stapelgruppenadministrator (batchGroupAdmin) 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
- Benutzer mit der Rolle "batchMonitor" haben die Leseberechtigung für alle Jobs. Benutzer mit dieser Rolle können alle Jobinstanzen und Ausführungen anzeigen und haben Zugriff
auf alle Jobprotokolle. Benutzer mit der Rolle "batchMonitor" können keine eigenen Jobs übergeben, oder Jobs stoppen, erneut starten oder löschen.
batchGroupMonitor
Benutzer mit der Rolle "batchGroupMonitor" haben für alle Jobs, die mit der Operationsgruppe, zu der der Benutzer gehört, die Berechtigung "schreibgeschützt". Benutzer mit dieser Rolle können alle Jobinstanzen und Ausführungen anzeigen und haben Zugriff auf alle Jobprotokolle für Jobs innerhalb des Geltungsbereichs Ihrer Operationsgruppe.
Ein Benutzer mit der Rolle "batchGroupMonitor" kann keine Jobs übergeben, stoppen, neu 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, der nur batchSubmitter-Berechtigungen hat, eine Liste aller Jobinstanzen anfordert, werden nur Jobinstanzen zurückgegeben, die vom aktuellen Benutzer übergeben werden.
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 Beispielstapelanwendungen mit einer auf Rollen basierten Sicherheitskonfigurationen 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>

Anmerkung: Wenn das Feature
zosSecurity-1.0 aktiviert ist, wird die
rollenbasierte Stapelberechtigung vom SAF-Berechtigungsprovider ausgeführt.
Der
SAF-Berechtigungsprovider ermittelt die Berechtigung des Clients, indem er
die Ebene des Clientzugriffs auf die in der Klasse EJBROLE definierten
SAF-Ressourcenprofile prüft.
Standardmäßig sind den Stapelrollen folgende Ressourcenprofile zugeordnet.
batchAdmin: BBGZDFLT.com.ibm.ws.batch.batchAdmin
batchSubmitter: BBGZDFLT.com.ibm.ws.batch.batchSubmitter
batchMonitor: BBGZDFLT.com.ibm.ws.batch.batchMonitor
Die Clientidentität muss über Lesezugriff (READ) auf das entsprechende Ressourcenprofil verfügen, damit
sie für die zugehörige Stapelrolle berechtigt wird.
Das folgende Beispiel zeigt die RACF-Befehle, mit denen der Clientidentität bob die Berechtigung für die Rolle
batchAdmin erteilt wird.
RDEFINE EJBROLE BBGZDFLT.com.ibm.ws.batch.batchAdmin UACC(NONE)
PERMIT BBGZDFLT.com.ibm.ws.batch.batchAdmin CLASS(EJBROLE) ID(bob) ACCESS(READ)