Liberty でのアプリケーションの許可の構成
アプリケーションの許可の構成は、ユーザーまたはグループが指定されたロールに属するかどうか、およびリソースにアクセスするための特権がこのロールにあるかどうかを確認するために行います。
このタスクについて
Liberty サーバーは、ユーザーおよびグループのマッピング情報をユーザー・レジストリーから抽出してから、アプリケーションの許可構成を検査して、必要なロールのいずれかにユーザーまたはグループが割り当てられているかどうかを判別します。次に、サーバーは、アプリケーションのデプロイメント記述子を読み取って、リソースにアクセスするための特権をユーザーまたはグループが持っているかどうかを判断します。
手順
- server.xml ファイルで appSecurity-2.0
Liberty フィーチャーを使用可能にします。 以下に例を示します。
<featureManager> <feature>appSecurity-2.0</feature> </featureManager>
- Liberty サーバーで認証用のユーザー・レジストリーを構成します。
Liberty でのユーザーの認証を参照してください。
- ご使用のアプリケーションのデプロイメント記述子に、セキュリティー制約および他のセキュリティー関連情報が確実に含まれるようにします。 注: デプロイメント記述子を作成するには、Rational® Application Developer などのツールも使用できます。
- 許可情報 (ユーザーおよびグループからロールへのマッピングなど) を構成します。 許可テーブルは次のようにして構成できます。
- 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 つのタイプ EVERYONE と ALL_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 にマップされます。これは、認証用に有効なクレデンシャルを指定すればどのユーザーでもアクセスできることを意味します。
- オプション: アプリケーション・バインド情報がない場合の許可決定を構成します。 保護アプリケーションに関するロール・マッピング・バインディングが指定されていない場合、デフォルトの許可エンジンは、リソースを保護しているロール名をそのロールに関連付けられるグループ名として使用します。そのため、例えば、ロール名が 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