Liberty プロファイル上のアプリケーションの許可の構成

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

このタスクについて

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

手順

  1. server.xml ファイルで appSecurity-2.0 Liberty フィーチャーを使用可能にします。
    以下に例を示します。
        <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
  2. Liberty プロファイル・サーバーで認証用のユーザー・レジストリーを構成します。

    Liberty プロファイルでのユーザーの認証』を参照してください。

  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 にマップされます。これは、認証用に有効なクレデンシャルを指定すればどのユーザーでもアクセスできることを意味します。


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

インフォメーション・センターに関するご使用条件 | フィードバック


タイム・スタンプ・アイコン 最終更新: 2015 年 6 月 17日
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_sec_rolebased
ファイル名: twlp_sec_rolebased.html