Liberty プロファイル・バッチ環境の保護

Liberty バッチ・フレームワークでは、すべてのバッチ管理操作に対するロール・ベースの権限を構成することができ、バッチ・ジョブと関連付けられたメタデータおよびログを表示することもできます。

始める前に

バッチ・ロールがバッチ・コンテナーによって定義されています。1 人のユーザーが複数のバッチ・ロールを持つことが可能です。
batchAdmin
batchAdmin には、すべてのバッチ操作への無制限の権限があります。これには、 新規ジョブのサブミット、任意のユーザーのジョブの停止と再開、 バッチ・ドメイン内の任意のユーザーによってサブミットされた任意のジョブ・メタデータおよびジョブ・ログの表示、 および任意のジョブのパージを行う権限が含まれます。batchAdmin は、必ずしも WebSphere® Application Server 管理者である必要はありません。
[18.0.0.1 and later]batchGroupAdmin
[18.0.0.1 and later]batchGroupAdmin のロールを持っていて、ジョブが割り当てられた操作グループのメンバーであるユーザーは、それらのジョブのすべてのバッチ操作にアクセスできます。batchGroupAdmin のロールを持っているユーザーは、任意のジョブを停止、反復、再開、および表示できますが、batchSubmitter のロールも持っている場合を除いて、新規ジョブをサブミットすることはできません。batchGroupAdmin ユーザーは、ジョブのメタデータおよびジョブ・ログを表示でき、同じ操作グループの他のユーザーがサブミットしたジョブをパージすることもできます。batchGroupAdmin ユーザーは、必ずしも WebSphere Application Server 管理者である必要はありません。
batchSubmitter
batchSubmitter には、新規ジョブのサブミットを行う権限があり、 自分のジョブについてのみ、停止、再開、パージなどのバッチ操作を実行できます。batchSubmitter は、 他のユーザーのジョブの表示および変更を行うことはできません。例えば、user1 と user2 が batchSubmitter として定義されていて、 user1 がジョブをサブミットしたとすると、user1 のジョブと関連付けられたジョブ・インスタンス・データを user2 が表示することはできません。
batchMonitor
batchMonitor のロールを持つユーザーには、すべてのジョブに対する読み取り専用権限があります。このロールのユーザーは、 すべてのジョブ・インスタンスおよびジョブ実行を表示でき、すべてのジョブ・ログにアクセスできます。batchMonitor のロールを持つユーザーは、自分のジョブをサブミットすることはできず、どのジョブについても、停止、再開、パージを行うことはできません。
[18.0.0.1 and later]batchGroupMonitor
[18.0.0.1 and later]batchGroupMonitor のユーザーは、所属する操作グループと関連付けられているすべてのジョブに対する読み取り専用権限を持ちます。このロールのユーザーは、すべてのジョブ・インスタンスおよびジョブ実行を表示でき、ユーザーの操作グループの有効範囲内のジョブのすべてのジョブ・ログにアクセスできます。 batchGroupMonitor は、ジョブのサブミット、停止、再開、およびパージを行うことはできません。
注: バッチ・セキュリティーが有効にされると、リストを返す JobOperator API メソッドまたは REST 操作は、現行ユーザーに認可されたバッチ・ロールに基づいてフィルタリングされるようになります。例えば、batchSubmitter 権限のみを持つユーザーがすべてのジョブ・インスタンスのリストを要求した場合、現行ユーザーによってサブミットされたジョブ・インスタンスのみが返されます。

手順

  1. デフォルトでは、batch-1.0 フィーチャーはどのようなセキュリティーも有効にしません。認証されたユーザーかどうかにかかわらず、すべてのユーザーに対して JobOperator のメソッドは開かれています。それらのメソッドが開かれているのは開発目的のためのみであり、セキュリティー構成は必要ありません。 batchManagement-1.0 フィーチャーはバッチ REST API を使用可能にします。 REST API は、appSecurity-2.0 フィーチャーが有効になっていない場合であってもユーザーの認証を常に必要としますが、すべてのユーザーがバッチ管理者として扱われ、任意のジョブ・インスタンスですべてのバッチ操作を実行できます。appSecurity-2.0 が有効にされると、バッチ・ロール・ベースのセキュリティー許可が実行されるようになり、ユーザーは各自に与えられたバッチ・ロールによって定義されるバッチ操作しか実行できないよう制限されます。
    1. JobOperator API を通してバッチ・ロール・ベースのセキュリティーを有効にします。
      <featureManager>
      	<feature>batch-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
    2. REST API を通してバッチ・ロール・ベースのセキュリティーを有効にします。
      注: batchManagement-1.0 フィーチャーには、batch-1.0 フィーチャーが組み込まれています。
      <featureManager>
      	<feature>batchManagement-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
  2. ロール・ベースのセキュリティーをサポートするように server.xml ファイルを構成します。 以下の例は、一連のユーザーを定義する基本的なユーザー・レジストリーを示します。このレジストリーは、以下のバッチ・ロール・ベースのセキュリティー構成のサンプルで使用されています。
    <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>

    次の例では、1 人のユーザーが複数のロールを持ちます。

    <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>
    次の例では、1 人のユーザーが複数のロールを持ちます。すべてのユーザーが 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>
    次の例では、1 人のユーザーが複数のロールを持ちます。認証されていないユーザーも含めて、すべてのユーザーが 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>
    For z/OS platforms
    注: zosSecurity-1.0 フィーチャーが有効にされている場合、 バッチ・ロール・ベースの許可は SAF 許可プロバイダーによって処理されます。
    SAF 許可プロバイダーは、EJBROLE クラスに定義された SAF リソース・プロファイルへのクライアントのアクセス・レベルをチェックすることによって、 クライアントの許可を判別します。デフォルトでは、以下のリソース・プロファイルがバッチ・ロールと関連付けられます。
    batchAdmin:     BBGZDFLT.com.ibm.ws.batch.batchAdmin
    batchSubmitter: BBGZDFLT.com.ibm.ws.batch.batchSubmitter
    batchMonitor:   BBGZDFLT.com.ibm.ws.batch.batchMonitor

    クライアント ID には、対応するバッチ・ロールが認可されるよう、適切なリソース・プロファイルへの READ アクセス権限が付与される必要があります。

    次の例は、クライアント ID bob に batchAdmin ロールの許可を付与する RACF® コマンドを示します。

    RDEFINE EJBROLE BBGZDFLT.com.ibm.ws.batch.batchAdmin UACC(NONE)
    PERMIT BBGZDFLT.com.ibm.ws.batch.batchAdmin CLASS(EJBROLE) ID(bob) ACCESS(READ)

トピックのタイプを示すアイコン タスク・トピック

ファイル名: twlp_batch_securing.html