Liberty-Stapelumgebung schützen

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.
[18.0.0.1 und höher]batchGroupAdmin
[18.0.0.1 und höher]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.
[18.0.0.1 und höher]batchGroupMonitor
[18.0.0.1 und höher]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

  1. 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.
    1. Aktivieren der rollenbasierten Stapelsicherheit über die JobOperator-API
      <featureManager>
      	<feature>batch-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
    2. 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>
  2. 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>
    Für z/OS-Plattformen
    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)

Symbol das den Typ des Artikels anzeigt. Taskartikel

Dateiname: twlp_batch_securing.html