Liberty-Repository[8.5.5.6 oder höher]

Stapelumgebung des Liberty-Profils schützen

Das Stapelframework des Liberty-Profils 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

  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 den 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>

Symbol das den Typ des Artikels anzeigt. Taskartikel

Nutzungsbedingungen für Information Center | Feedback


Symbol für Zeitmarke Letzte Aktualisierung: 25.08.2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_batch_securing
Dateiname: twlp_batch_securing.html