| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Security サービスの開発 > 認可プロバイダ |
|
WebLogic Security サービスの開発
|
認可とは、ユーザの ID などの情報に基づいて、ユーザと WebLogic リソースとのやり取りを管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Server では、認可プロバイダはユーザと WebLogic リソースとの対話を制限して、整合性、機密性、および可用性を確保します。
以下の節では、認可プロバイダの概念と機能、およびカスタム認可プロバイダの開発手順について説明します。
認可プロバイダを開発する前に、以下の概念を理解しておく 必要があります。
認証プロバイダの LoginModule と同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作を WebLogic リソースに対して実行するパーミッションをサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答を PERMIT、DENY、または ABSTAIN のいずれかで返します。
注意: アクセス決定の詳細については、AccessDecision SSPI を実装するを参照してください。
図 6-1 に、認可プロセスにおける認可プロバイダ (および関連する裁決プロバイダとロール マッピング プロバイダ) と WebLogic Security フレームワークとの対話を示します。その後、この図について説明します。
注意: リソース コンテナは、セキュリティ プロバイダと WebLogic リソースで説明されている WebLogic リソースのいずれかを処理するコンテナです。
注意: ContextHandler の詳細については、ContextHandler と WebLogic リソースを参照してください。アクセス決定の詳細については、アクセス決定を参照してください。ロール マッピング プロバイダの詳細については、ロール マッピング プロバイダを参照してください。
リソース コンテナは、サブジェクト、リソース、そして場合によっては決定用の追加入力を提供する ContextHandler オブジェクトを渡して WebLogic Security フレームワークを呼び出します。
ロール マッピング プロバイダは、Callback オブジェクトに格納されている値、サブジェクト、およびリソースを用いて、リクエスト元のサブジェクトに付与されるロールを計算し、該当するロールを WebLogic Security フレームワークに渡します。
注意: 裁決プロバイダの詳細については、裁決プロバイダを参照してください。
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 認可プロバイダが含まれています。WebLogic 認可プロバイダは、このバージョンの WebLogic Server の認可機能をデフォルトで適用するものです。WebLogic 認可プロバイダは、特定のユーザが保護対象の WebLogic リソースへのアクセスを許可されているかどうかを判定するためのポリシーベースの認可エンジンを使用して、アクセス決定を返します。また、WebLogic 認可プロバイダは、システム内のセキュリティ ポリシーのデプロイメントとアンデプロイメントもサポートしています。自社の既存の認可メカニズムを使用する場合は、カスタム認可プロバイダを作成してそれを既存のメカニズムに結合できます。
WebLogic 認可プロバイダが開発者の要求を満たさない場合、次の手順でカスタム認可プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダの実行時クラスを作成します。
注意: セキュリティ レルムでは、少なくとも 1 つの認可プロバイダが DeployableAuthorizationProvider SSPI を実装する必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
カスタム認可プロバイダの実行時クラスの作成例については、例 : サンプル認可プロバイダの実行時クラスの作成を参照してください。
AuthorizationProvider SSPI を実装する
AuthorizationProvider SSPI を実装するには、「Provider」SSPI の目的を理解するで説明されているメソッドと以下のメソッドの実装を提供する必要があります。
AuthorizationProvider SSPI および getAccessDecision メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
DeployableAuthorizationProvider SSPI を実装する
DeployableAuthorizationProvider SSPI を実装するには、「Provider」SSPI の目的を理解するおよびAuthorizationProvider SSPI を実装するで説明されているメソッドと以下のメソッドの実装を提供する必要があります。
DeployableAuthorizationProvider SSPI および deployPolicy メソッドと undeployPolicy メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
AccessDecision SSPI を実装する際には、以下のメソッドの実装を提供する必要があります。
AccessDecision SSPI および isAccessAllowed メソッドと isProtectedResource メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
レルム アダプタ認証プロバイダと互換性のあるカスタム認可プロバイダの開発
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループは、認可プロバイダなどの他のタイプのセキュリティ プロバイダによってサブジェクトから抽出されます。 セキュリティ レルムでコンフィグレーションされている認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは若干異なる方法でサブジェクトに格納されます。 そのため、こうしたユーザおよびグループの情報の抽出も、若干異なる方法で行う必要があります。
サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかを調べるためにカスタム認可プロバイダで使用できるコードをリスト6-1 に示します。 このコードは、isAccessAllowed メソッドおよび isProtectedResource メソッドに記述できます。
コード リスト 6-1 サブジェクトがユーザ名またはグループ名に一致するかどうかを調べるためのサンプル コード
/**
* サブジェクトがユーザ名またはグループ名に一致するかどうかを調べる
*
* @param principalWant このロールのプリンシパル名を含む文字列
* (つまり、ロール定義)
*
* @param subject リソースにアクセスしようとしているユーザおよびそのユーザのグループを
* 識別するプリンシパルを含むサブジェクト
*
* @return ブール値。現在のサブジェクトがロールのプリンシパルに
* 一致する場合は true、それ以外の場合は false
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// まず、グループ名が一致しているかどうかを調べる
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// 次に、ユーザ名が一致しているかどうかを調べる
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// 一致しなかった場合
return false;
}
リスト6-2 は、サンプル認可プロバイダの実行時クラスである SampleAuthorizationProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
注意: リスト6-2 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 6-2 SampleAuthorizationProviderImpl.java
package examples.security.providers.authorization;
import java.security.Principal;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AccessDecision;
import weblogic.security.spi.DeployableAuthorizationProvider;
import weblogic.security.spi.Direction;
import weblogic.security.spi.InvalidPrincipalException;
import weblogic.security.spi.Resource;
import weblogic.security.spi.ResourceCreationException;
import weblogic.security.spi.ResourceRemovalException;
import weblogic.security.spi.Result;
import weblogic.security.spi.SecurityServices;
public final class SampleAuthorizationProviderImpl implements DeployableAuthorizationProvider, AccessDecision
{
private String description;
private SampleAuthorizerDatabase database;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SampleAuthorizationProviderImpl.initialize");
SampleAuthorizerMBean myMBean = (SampleAuthorizerMBean)mbean;
description = myMBean.getDescription() + "¥n" + myMBean.getVersion();
database = new SampleAuthorizerDatabase(myMBean);
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SampleAuthorizationProviderImpl.shutdown");
}
public AccessDecision getAccessDecision()
{
return this;
}
public Result isAccessAllowed(Subject subject, Map roles, Resource resource,
ContextHandler handler, Direction direction) throws InvalidPrincipalException
{
System.out.println("SampleAuthorizationProviderImpl.isAccessAllowed");
System.out.println("¥tsubject¥t= " + subject);
System.out.println("¥troles¥t= " + roles);
System.out.println("¥tresource¥t= " + resource);
System.out.println("¥tdirection¥t= " + direction);
Set principals = subject.getPrincipals();
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
return isAccessAllowed(res, principals, roles);
}
}
return Result.ABSTAIN;
}public boolean isProtectedResource(Subject subject, Resource resource) throws
InvalidPrincipalException
{
System.out.println("SampleAuthorizationProviderImpl.
isProtectedResource");
System.out.println("¥tsubject¥t= " + subject);
System.out.println("¥tresource¥t= " + resource);
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
return true;
}
}
return false;
}public void deployPolicy(Resource resource, String[] roleNamesAllowed)
throws ResourceCreationException
{
System.out.println("SampleAuthorizationProviderImpl.deployPolicy");
System.out.println("¥tresource¥t= " + resource);
for (int i = 0; roleNamesAllowed != null && i < roleNamesAllowed.length;
i++) {
System.out.println("¥troleNamesAllowed[" + i + "]¥t= " +
roleNamesAllowed[i]);
}
database.setPolicy(resource, roleNamesAllowed);
}
public void undeployPolicy(Resource resource) throws ResourceRemovalException
{
System.out.println("SampleAuthorizationProviderImpl.undeployPolicy");
System.out.println("¥tresource¥t= " + resource);
database.removePolicy(resource);
}
private boolean principalsOrRolesContain(Set principals, Map roles, String
principalOrRoleNameWant)
{
if (roles.containsKey(principalOrRoleNameWant)) {
return true;
}
{
for (Iterator i = principals.iterator(); i.hasNext();) {
Principal principal = (Principal)i.next();
String principalNameHave = principal.getName();
if (principalOrRoleNameWant.equals(principalNameHave)) {
return true;
}
}
}
return false;
}
private Result isAccessAllowed(Resource resource, Set principals, Map roles)
{
for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();)
{
String principalOrRoleNameAllowed = (String)e.nextElement();
if (WLSPrincipals.getEveryoneGroupname().
equals(principalOrRoleNameAllowed) ||
(WLSPrincipals.getUsersGroupname().equals(principalOrRoleNameAllowed)
&& !principals.isEmpty()) || principalsOrRolesContain(principals,
roles, principalOrRoleNameAllowed))
{
return Result.PERMIT;
}
}
return Result.DENY;
}
}
WebLogic MBeanMaker を使用して MBean タイプを生成する
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダの MBean タイプを作成します。
注意: これらの手順の実行方法は、いくつかのサンプル セキュリティ プロバイダ (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) に示されています。
この節で説明する手順はすべて、Windows 環境での作業を想定しています。
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
注意: MDF 要素の構文についての完全なリファレンスは、MBean 定義ファイル (MDF) 要素の構文.に収められています。
WebLogic MBeanMaker を使用して MBean タイプを生成する
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの作成手順は、カスタム認可プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム認可プロバイダの MDF に任意 SSPI MBean もカスタム操作も実装しない場合、次の手順に従います。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに翻訳する必要があることを示し、xmlFile は MDF (XML MBean 定義ファイル)、filesdir は WebLogic MBeanMaker で生成された MBean タイプの中間ファイルが格納される場所です。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
任意 SSPI MBean またはカスタム操作を追加する場合
カスタム認可プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに翻訳する必要があることを示し、xmlFile は MDF (XML MBean 定義ファイル)、filesdir は WebLogic MBeanMaker で生成された MBean タイプの中間ファイルが格納される場所です。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、SampleAuthorizer という MDF の場合には、編集すべき MBean 実装ファイルの名前は SampleAuthorizerImpl.java です。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに翻訳する必要があることを示し、xmlFile は MDF (XML MBean 定義ファイル)、filesdir は WebLogic MBeanMaker で生成された MBean タイプの中間ファイルが格納される場所です。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、SampleAuthorizer という MDF の場合には、編集すべき MBean 実装ファイルの名前は SampleAuthorizerImpl.java です。
これには、メソッドの実装を既存の MBean 実装ファイルから新しく生成された MBean 実装ファイルにコピー (または、新しく生成された MBean 実装ファイルから既存の MBean 実装ファイルに新しいメソッドを追加) し、いずれの MBean 実装ファイルにも入っているメソッドのメソッド シグネチャへの変更が使用する MBean 実装ファイルに反映されていることを確認するといった作業が必要です。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「Provider」SSPI の目的を理解するで説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で SampleAuthorizer MDF を実行すると、その結果、SampleAuthorizerMBean.java という MBean インタフェース ファイルが生成されます。
WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) を作成する
WebLogic MBeanMaker を使用して MDF を実行して中間ファイルを生成し、MBean 実装ファイルを手作業で編集してその中にメソッドの内容を記述したら、カスタム認可プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。
カスタム認可プロバイダの MJF を作成するには、次の手順に従います。
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを格納する JAR ファイルをビルドする必要があることを示し、jarfile は MJF の名前、filesdir は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所です。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。
注意: 既存の MJF を更新する場合は、MJF をいったん削除してから再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御することができます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false です。このオプションは、-DMJF を使用しない場合には無視されます。
生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。
WebLogic Server 環境に MBean タイプをインストールする
MBean タイプを WebLogic Server 環境にインストールするには、MJF を WL_HOME¥server¥lib¥mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。このインストール コマンドによって、カスタム認可プロバイダが「デプロイ」されます。つまり、カスタム認可プロバイダを WebLogic Server Administration Console から管理できるようになります。
注意: WL_HOME¥server¥lib¥mbeantypes は、MBean タイプをインストールするデフォルトのディレクトリです。 ただし、WebLogic Server が追加ディレクトリで MBean タイプを検索するようにするには、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用します (<dir> はディレクトリ名のカンマ区切りのリスト)。 このフラグを使用すると、WebLogic Server は常にまず WL_HOME¥server¥lib¥mbeantypes から MBean タイプをロードし、その後に追加ディレクトリを検索して、(拡張子に関係なく) そのディレクトリに存在するすべての有効なアーカイブをロードします。 たとえば -Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server はまず WL_HOME¥server¥lib¥mbeantypes から MBean タイプをロードし、その後に、dirX および dirY に存在する有効なアーカイブをロードします。
追加ディレクトリで MBean タイプを検索するように WebLogic Server に指示し、かつ Java セキュリティ マネージャを使用する場合は、weblogic.policy ファイルを更新して、MBean タイプ (したがってカスタム セキュリティ プロバイダも) に対する適切なパーミッションを与える必要があります。 詳細については、『WebLogic Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
非セキュリティ プロバイダの JAR (バックアップ ファイルを含む) は、WL_HOME¥server¥lib¥mbeantypes ディレクトリ以外の場所に置くことをお勧めします。
カスタム認可プロバイダをコンフィグレーションすることによって (Administration Console を使用してカスタム認可プロバイダをコンフィグレーションするを参照)、MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。詳細については、『WebLogic Server ドメイン管理』の「障害が発生したサーバの回復」の「セキュリティ コンフィグレーション データのバックアップ」を参照してください。
Administration Console を使用してカスタム認可プロバイダをコンフィグレーションする
カスタム認可プロバイダをコンフィグレーションするということは、認可サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム認可プロバイダを追加するということです。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム認可プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。
注意: WebLogic Server Administration Console を使用したカスタム認可プロバイダのコンフィグレーション手順については、『WebLogic Security の管理』の「カスタム セキュリティプロバイダのコンフィグレーション」を参照してください。
エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーション コンポーネントの中には、関連デプロイメント情報を Java 2 Enterprise Edition (J2EE) デプロイメント記述子および WebLogic Server デプロイメント記述子に格納するものがあります。Web アプリケーションの場合、デプロイメント記述子ファイル (web.xml と weblogic.xml) には、セキュリティ ポリシーの宣言を含む J2EE セキュリティ モデルの実装情報が格納されます。この情報は、WebLogic Server Administration Console で認可プロバイダを初めてコンフィグレーションするときに格納するのが一般的です。
Administration Console には、この目的のために [デプロイメント記述子内のセキュリティ データを無視] チェックボックスが用意されています。開発者または管理者がカスタム認可プロバイダを初めてコンフィグレーションするときには、このチェックボックスのチェックがはずれていることを確認する必要があります。
注意: [デプロイメント記述子内のセキュリティ データを無視] チェックボックスは、デフォルトではチェックがはずれています。 このチェックボックスを設定するには、WebLogic Server Administration Console の左ペインで [セキュリティ｜レルム｜realm] をクリックします。realm はセキュリティ レルムの名前です。 次に [一般] タブを選択します。
このチェックボックスのチェックをはずして Web アプリケーションをデプロイすると、WebLogic Server は、web.xml および weblogic.xml デプロイメント記述子ファイル (リスト6-3 およびリスト6-4 の web.xml および weblogic.xml の例を参照) からセキュリティ ポリシー情報を読み込みます。この情報は、認可プロバイダのセキュリティ プロバイダ データベースにコピーされます。
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>developers</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>developers</role-name>
</security-role>
</web-app>
コード リスト 6-4 Sample weblogic.xml File
<weblogic-web-app>
<security-role-assignment>
<role-name>developers</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
注意: web.xml/weblogic.xml デプロイメント記述子ファイルでも WebLogic Server Administration Console でも追加のセキュリティ ポリシーを設定することができますが、Web アプリケーションのデプロイメント記述子に定義されているセキュリティ ポリシーをいったんコピーしてから Administration Console を使用して追加のセキュリティ ポリシーを定義することをお勧めします。この理由は、認可プロバイダのコンフィグレーション中に Administration Console を使用してセキュリティ ポリシーを変更すると、その内容が web.xml および weblogic.xml ファイルに保持されないからです。 Administration Console を使用して再デプロイする、ディスク上で Web アプリケーションを変更した、または WebLogic Server を再起動したといった場合に、Web アプリケーションを再デプロイするときには、[デプロイメント記述子内のセキュリティ データを無視] チェックボックスをチェックする必要があります。チェックボックスをチェックしないと、Administration Console で定義したセキュリティ ポリシーがデプロイメント記述子に定義されているセキュリティ ポリシーによって上書きされます。 詳細については、『WebLogic リソースのセキュリティ』の「組み合わせた方法による URL (Web) リソースとエンタープライズ JavaBean (EJB) リソースの保護」を参照してください。EJB についてもプロセスは同じですが、ejb-jar.xml/weblogic-ejb-jar.xml デプロイメント記述子を使用します。
[デプロイメント記述子内のセキュリティ データを無視] チェックボックスは、ロール マッピング プロバイダおよび資格マッピング プロバイダにも影響します。詳細については、それぞれロール マッピング プロバイダとデプロイメント記述子の管理と資格マッピング プロバイダ、リソース アダプタ、およびデプロイメント記述子の管理を参照してください。
DeployableAuthorizationProvider SSPI を実装し、カスタム認可プロバイダでデプロイ可能なセキュリティ ポリシーをサポートしたい場合、カスタム認可プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ポリシー デプロイメントを有効化] チェックボックスがチェックされていることを確認する必要があります。チェックがはずれていると、認可プロバイダは「オフ」と見なされます。 このため、複数の認可プロバイダがコンフィグレーションされている場合、[ポリシー デプロイメントを有効化] チェックボックスを使用すると、セキュリティ ポリシーのデプロイメントに使用する認可プロバイダを指定できます。
注意: [デプロイメント記述子内のセキュリティ データを無視] チェックボックス (認可プロバイダとデプロイメント記述子の管理で説明したようにセキュリティ レルム レベルで指定) では、コンフィグレーション済みの認可プロバイダのセキュリティ データベースにセキュリティ ポリシーをコピーするかどうかを指定します。 [ポリシー デプロイメントを有効化] チェックボックス (コンフィグレーション済みの認可プロバイダごとに指定) では、認可プロバイダがデプロイ済みのセキュリティ ポリシーを格納するかどうかを指定します。
WebLogic Server Administration Console を使用してカスタム認可プロバイダをコンフィグレーションすると、必要な認可サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ポリシーを管理する方法を管理者にも提供する必要があります。 たとえば WebLogic 認可プロバイダには、ポリシー エディタ ページ (図 6-2 を参照) が管理者向けに用意されており、リソースを右クリックして [ポリシーを定義...] オプションを選択すると、さまざまな WebLogic リソースのセキュリティ ポリシーを追加、変更、または削除することができます。
図6-2 WebLogic 認可プロバイダのポリシー エディタ ページ
管理者は、カスタム認可プロバイダを開発するときに、ポリシー エディタ ページも右クリック メニューも利用できません。 したがって、セキュリティ ポリシーを管理するための独自のメカニズムを提供する必要があります。 このメカニズムでは、カスタム認可プロバイダのデータベースのセキュリティ ポリシー データ (つまり式) を読み書きできなければなりません。
オプション 1 : コンソール拡張を使用して独自の「ポリシー エディタ」ページを作成する
カスタム認可プロバイダ用にコンソール拡張を作成する方法の主な利点は、コンソール拡張によって WebLogic リソースの ID がわかるので、その WebLogic リソースがリソース階層のどこにあるかもわかるということです。 この情報は、認可プロバイダのデータベースから式を読み書きするために必要です。 また、WebLogic 認可プロバイダのポリシー エディタ ページのように、作成したページを既存の WebLogic Server Administration Console GUI に統合できるという利点もあります。
注意: 詳細については、カスタム セキュリティ プロバイダ用のコンソール拡張の記述を参照してください。
注意: この構文は、認可プロバイダごとに異なっていてもかまいません。 式の詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシーの構成要素 : ポリシー条件、式、およびポリシー文」を参照してください。
オプション 2 : セキュリティ ポリシー管理用のスタンドアロン ツールを開発する
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法の場合、オプション 1 : コンソール拡張を使用して独自の「ポリシー エディタ」ページを作成するで説明したカスタム認可プロバイダ用のコンソール拡張を記述する必要もなく、管理 MBean を開発する必要もありません。 ただし、ツールでは以下のことを行う必要があります。
オプション 3 : 既存のセキュリティ ポリシー管理ツールを Administration Console に統合する
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
