Liberty でのアプリケーションの許可の構成

アプリケーションの許可の構成は、ユーザーまたはグループが指定されたロールに属するかどうか、およびリソースにアクセスするための特権がこのロールにあるかどうかを確認するために行います。

このタスクについて

Liberty サーバーは、ユーザーおよびグループのマッピング情報をユーザー・レジストリーから抽出してから、アプリケーションの許可構成を検査して、必要なロールのいずれかにユーザーまたはグループが割り当てられているかどうかを判別します。次に、サーバーは、アプリケーションのデプロイメント記述子を読み取って、リソースにアクセスするための特権をユーザーまたはグループが持っているかどうかを判断します。

System Authorization Facility (SAF) 許可を使用している場合、ロールは SAF ロール・マッパーを使用して EJBROLE リソース・プロファイルにマップされます。サーバーは SAF に照会して、EJBROLE リソース・プロファイルに対する必要な READ 権限をユーザーが備えているかどうかを判別します。

手順

  1. server.xml ファイルで appSecurity-2.0 Liberty フィーチャーを使用可能にします。
    以下に例を示します。
    <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
    注:
    • SAF 許可プロバイダーを使用している場合は、zosSecurity-1.0 フィーチャーを組み込み、safAuthorization 構成エレメントを server.xml ファイルで定義します。以下に例を示します。
      <featureManager>
           <feature>appSecurity-2.0</feature>
           <feature>zosSecurity-1.0</feature>
       </featureManager>
       <safAuthorization id="saf" />
  2. Liberty サーバーで認証用のユーザー・レジストリーを構成します。

    Liberty でのユーザーの認証を参照してください。

    SAF 許可プロバイダーを使用している場合は、SAF レジストリーを使用する必要があり、またサーバーが SAF 許可サービスを使用する権限を備えている必要があります。z/OS での SAF レジストリーのアクティブ化および構成を参照してください。

  3. ご使用のアプリケーションのデプロイメント記述子に、セキュリティー制約および他のセキュリティー関連情報が確実に含まれるようにします。
    注: デプロイメント記述子を作成するには、Rational® Application Developer などのツールも使用できます。
  4. 許可情報 (ユーザーおよびグループからロールへのマッピングなど) を構成します。
    許可テーブルは次のようにして構成できます。
    • EAR ファイルがある場合は、許可構成の定義を ibm-application-bnd.xml ファイルまたは ibm-application-bnd.xmi ファイルに追加できます。
    • スタンドアロンの WAR ファイルがある場合は、許可テーブルの定義を server.xml ファイルの各アプリケーション・エレメント下に追加できます。 この操作は WebSphere® Application Server Developer Tools for Eclipseを使用して行うことができます。
    注:
    • EAR ファイルがある場合は、許可構成が既に存在する可能性があります。 現行の仕様に書き込まれた EAR ファイル内では、この情報は ibm-application-bnd.xml ファイルに保管され、それよりも古い EAR ファイル内では、この情報は ibm-application-bnd.xmi ファイルに保管されています。
    • EAR ファイルに ibm-application-bnd.xm* ファイルがまだ含まれていない場合、このファイルを作成するのは単純な作業ではないため、許可構成を server.xml ファイルに追加するほうが良いかもしれません。
    • EAR ファイルの許可構成が ibm-application-bnd.xm* ファイルに加えて server.xml ファイルでも定義されている場合は、2 つのテーブルがマージされます。 競合がある場合は、server.xml ファイルの情報が使用されます。
    • ユーザー・レジストリーを変更した場合は、必ず、必要な変更がないか、許可テーブルを確認してください。例えば、access-id エレメントを指定していて、レジストリーのレルム名を変更した場合は、access-id エレメントのレルム名も変更する必要があります。
    • server.xml ファイルに application-bnd エレメントを 指定した場合は、dropins フォルダーにアプリケーションが存在してはなりません。それを dropins フォルダーにそのまま置く場合は、 server.xml ファイルに以下を設定して、アプリケーション・モニターを使用不可にする必要があります。
      <applicationMonitor dropinsEnabled="false"/>

    ロールは、ユーザー、グループ、または特別な対象にマップすることができます。 特別な対象には 2 つのタイプ EVERYONEALL_AUTHENTICATED_USERS があります。 ロールが特別な対象 EVERYONE にマップされた場合、全員がアクセスを許可され、クレデンシャルの入力を求めるプロンプトが表示されないため、セキュリティーが存在しないことになります。 ロールが特別な対象 ALL_AUTHENTICATED_USERS にマップされている場合は、アプリケーション・サーバーによって認証されたすべてのユーザーが保護リソースにアクセスできます。

    以下に、server.xml ファイル内でユーザーおよびグループからロールへのマッピングを構成するコードの例を示します。
    <application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
    	<application-bnd>
    		<security-role name="user">
    			<group name="students" />
    		</security-role>
    		<security-role name="admin">
    			<user name="gjones" />
                <group name="administrators" />
    		</security-role>
    		<security-role name="AllAuthenticated">
    			<special-subject type="ALL_AUTHENTICATED_USERS"/>
    		</security-role>
    	</application-bnd>
    </application>

    この例では、admin ロールが、ユーザー ID gjones、およびグループ administrators のすべてのユーザーにマップされます。AllAuthenticatedRole は、特別な対象 ALL_AUTHENTICATED_USERS にマップされます。これは、認証用に有効なクレデンシャルを指定すればどのユーザーでもアクセスできることを意味します。

    注: SAF 許可を有効にする場合、 ALL_AUTHENTICATED_USERS および EVERYONE といった特別な対象は使用できません。
    SAF 許可を使用している場合は、ロールは SAF ロール・マッパーを使用して EJBROLE リソース・プロファイルにマップされます。SAF ロール・マッパー・パターンは、server.xml ファイルの safRoleMapper エレメントを使用して構成できます。『Liberty: ロールを SAF プロファイルにマップする方法の制御』を参照してください。デフォルトでは、ロールは、パターン profile_prefix.resource.role を使用してリソース・プロファイルにマップされます。ここで、
    • profile_prefix は、safCredentials 構成エレメントの profilePrefix 属性で定義されます。 デフォルトでは、profilePrefix の値は BBGZDFLT です。
    • resource は、リソース名です (例えば、アプリケーション名)。
    • role はロール名です。
    保護リソースにアクセスするには、ユーザーは、EJBROLE リソース・プロファイルに対する READ 権限を備えている必要があります。例えば、アプリケーション myapp でユーザー ID gjones がロール admin で保護リソースにアクセスするには、ユーザー gjones は、SAF 製品の EJBROLE クラスでリソース・プロファイル BBGZDFLT.myapp.admin に対する READ 権限を備えている必要があります。
    注: EJBROLE リソース・プロファイルでは、大/小文字が区別されます。
    以下のコード例に、ユーザーを許可するサンプルの RACF® コマンドを示します。
    rdef EJBROLE BBGZDFLT.myapp.admin uacc(none)
    permit BBGZDFLT.myapp.admin class(EJBROLE) access(read) id(gjones)
  5. オプション: アプリケーション・バインド情報がない場合の許可決定を構成します。
    保護アプリケーションに関するロール・マッピング・バインディングが指定されていない場合、デフォルトの許可エンジンは、リソースを保護しているロール名をそのロールに関連付けられるグループ名として使用します。そのため、例えば、ロール名が manager の場合、manager グループに属しているユーザーは、そのリソースにアクセスできます。 これは、server.xml またはアプリケーション・バイン ディング・ファイルのアプリケーション・バインド情報がこのアプリケーシ ョンに指定されていない場合にのみ適用されます。例えば、このバインディ ングを追加すると、グループ・バインディングへのセキュリティー ・ロールが無効になります。
    <application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
          <application-bnd>
    	     <security-role name="anyAppRoleName"/>
          </application-bnd>
    </application>
    注: ユーザー・レジストリーのグループ名が正常に許可されるためには、 ロール名は、構成されるレジストリーのグループのフルネーム (固有の名前) と一致している必要があり、 ショート・ネームであってはなりません。例えば、グループのショート・ネームが swGroup で、ユーザー・レジストリーでのフルネーム (固有の名前) が CN=swGroup,o=company,c=us の場合、正常に許可されるためには、ロール名として CN=swGroup,o=company,c=us を指定する必要があります。

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

ファイル名: twlp_sec_rolebased.html