| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Security サービスの開発 > ロール マッピング プロバイダ |
|
WebLogic Security サービスの開発
|
ロール マッピングとは、実行時にプリンシパル (ユーザまたはグループ) をセキュリティ ロールに動的に割り当てるプロセスのことです。WebLogic Server では、ロール マッピング プロバイダは、WebLogic リソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ ロールを調べます。通常、この操作では WebLogic リソースへのアクセスを取得する必要があるので、ロール マッピング プロバイダは認可プロバイダと共に使用するのが一般的です。
以下の節では、ロール マッピング プロバイダの概念と機能、およびカスタム ロール マッピング プロバイダの開発手順について説明します。
ロール マッピング プロバイダを開発する前に、以下の概念を理解しておく必要があります。
セキュリティ ロールは、WebLogic リソースへの同じアクセス パーミッションを持つユーザまたはグループの集合です。グループと同様、セキュリティ ロールを使用すると、複数のユーザによる WebLogic リソースへのアクセスを一度に制御できます。 しかし、セキュリティ ロールは WebLogic Server ドメインの特定のリソースを対象としており (WebLogic Server ドメイン全体を対象とするグループとは異なる)、動的に定義することが可能です。動的セキュリティ ロール計算を参照してください。
注意: セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。WebLogic リソースの詳細については、セキュリティ プロバイダと WebLogic リソースおよび『WebLogic リソースのセキュリティ』の「WebLogic リソース」を参照してください。
weblogic.security.service パッケージに定義されている SecurityRole インタフェースは、セキュリティ ロールの抽象的な記法を表すのに用いられます。詳細については、WebLogic Server 7.0 API リファレンス Javadoc の SecurityRole インタフェースを参照してください。
プリンシパルをセキュリティ ロールにマップすると、そのプリンシパルがそのセキュリティ ロールに「割り当てられている」かぎり、そのプリンシパルには定義されたアクセス パーミッションが付与されます。たとえば、アプリケーションで「AppAdmin」というセキュリティ ロールを定義し、これによってそのアプリケーションのリソースのごく一部に対する書き込みアクセスが提供されるものとします。この場合、AppAdmin セキュリティ ロールに割り当てられたプリンシパルはすべて、それらのリソースに対して書き込みアクセスを持つことになります。 詳細については、動的セキュリティ ロール計算と『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
なお、多数のプリンシパルを単一のセキュリティ ロールにマップすることができます。プリンシパルの詳細については、ユーザ/グループ、プリンシパル、サブジェクトを参照してください。
セキュリティ ロールの指定は、J2EE (Java 2 Enterprise Edition) デプロイメント記述子ファイルか WebLogic Server Administration Console、あるいはその両方で行われます。詳細については、ロール マッピング プロバイダとデプロイメント記述子の管理を参照してください。
セキュリティ ロールは、宣言的なもの (すなわち、Java 2 Enterprise Edition におけるロール) とすることも、リクエストのコンテキストに基づいて動的に計算することもできます。
動的ロール計算とは、このようにプリンシパル (ユーザまたはグループ) を実行時にセキュリティ ロールにレイト バインドすることを意味する用語です。 こうしたレイト バインディングは、プリンシパル対セキュリティ ロールの関連付けが静的に定義されるか動的に計算されるかによらず、保護対象 WebLogic リソースについての認可判定の直前に行われます。 バインディングが呼び出しシーケンス内で行われるため、あらゆるプリンシパル対セキュリティ ロール計算の結果は、リクエストに対して下される認可判定の一環として、認証用 ID 情報として解釈することができます。
セキュリティ ロールの動的計算には、ビジネス ルールに基づいてユーザまたはグループにセキュリティ ロールを付与できるという、非常に重要な利点があります。たとえば、本来の管理者が長期の出張で不在の間だけユーザに Manager セキュリティ ロールを割り当てるといったことができます。このセキュリティ ロールを動的に計算することで、そうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要はなくなります。さらに、本当の管理者が戻ってきたときに、特別に付与した一時的な特権を忘れずに取り消す必要もありません。なお、ユーザを一時的に Managers グループに追加した場合には、その必要があるでしょう。
注意: 通常は、WebLogic Server Administration Console で使用可能なロール条件を使用して、ユーザまたはグループにセキュリティ ロールを付与します (このリリースの WebLogic Server では、カスタム ロール条件を書き込むことはできません)。 詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
計算で得られたセキュリティ ロールは、対象 (利用可能であれば) の ID 情報やリクエストのパラメータ値など、リクエストのコンテキストを構成するさまざまな情報にアクセスすることができます。こうしたコンテキスト情報は通常、WebLogic Security フレームワークで評価される式に含まれるパラメータの値として使用されます。この機能は、デプロイメント記述子または WebLogic Server Administration Console を通じて静的に定義されたセキュリティ ロールの計算も担当します。
注意: 認証済みユーザに対するセキュリティ ロールの計算は、J2EE (Java 2 Enterprise Edition) 仕様で定義されているロールベース アクセス制御 (RBAC) によるセキュリティ機能を拡張したものです。
動的なセキュリティ ロール計算を作成するには、WebLogic Server Administration Console でロール文を定義します。 詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。
WebLogic Security フレームワークは、認可判定の一環として、セキュリティ レルム用にコンフィグレーションされている各ロール マッピング プロバイダを呼び出します。関連情報については、認可プロセスを参照してください。
ロール マッピング プロバイダによる動的ロール関連計算の結果、一連のセキュリティ ロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのセキュリティ ロールを用いて、保護対象 WebLogic リソース、リソース コンテナ、およびアプリケーション コードについての認可判定が行われます。たとえば、エンタープライズ JavaBean (EJB) であれば、アクセスを許可するかどうかを決めるビジネス ポリシーを知らなくても、J2EE (Java 2 Enterprise Edition) の isCallerInRole() メソッドを用いてデータベース内のレコードからフィールドを取得することができます。
動的ロール計算を作成する場合のロール マッピング プロバイダと WebLogic Security フレームワークとの対話を図 8-1 に示し、その後それについて説明します。
図8-1 ロール マッピング プロバイダとロール マッピング プロセス
注意: リソース コンテナは、セキュリティ プロバイダと WebLogic リソースで説明されている WebLogic リソースのいずれかを処理するコンテナです。
注意: ContextHandler の詳細については、ContextHandler と WebLogic リソースを参照してください。
リソース コンテナは、JAAS サブジェクト (ユーザおよびグループ プリンシパルを含む)、WebLogic リソースの識別子、そして場合によっては追加入力を提供する ContextHandler オブジェクトを渡して WebLogic Security フレームワークを呼び出します。
注意: サブジェクトの詳細については、ユーザ/グループ、プリンシパル、サブジェクトを参照してください。また、リソース識別子の詳細については、WebLogic リソース識別子を参照してください。
ロール マッピング プロバイダは、必要なコンテキスト情報を取得するのに、ContextHandler を複数回呼び出す場合があります。ロール マッピング プロバイダで ContextHandler が呼び出される回数はその実装によって異なります。
セキュリティ ポリシーは、指定されたセキュリティ ロールを付与すべきかどうかを判定する際に評価される一連の式すなわちルールとして表されます。これらのルールを使用する際に、ロール マッピング プロバイダは、取得したコンテキスト情報の値を式のパラメータに代入しなければならない場合があります。さらに、ユーザ プリンシパルまたはグループ プリンシパルの ID 情報が、式のパラメータ値として必要になることもあります。
注意: セキュリティ ポリシーのルールは、WebLogic Server Administration Console と J2EE (Java 2 Enterprise Edition) デプロイメント記述子で設定します。 詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照してください。
カスタム ロール マッピング プロバイダを開発する必要があるか
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic ロール マッピング プロバイダが含まれています。WebLogic ロール マッピング プロバイダは、デフォルト ユーザと WebLogic リソースのそれぞれについて、保護されている特定のリソースに関する特定のユーザ (サブジェクト) の動的セキュリティ ロールを計算します。また、WebLogic ロール マッピング プロバイダは、システム内のセキュリティ ロールのデプロイメントとアンデプロイメントをサポートしています。WebLogic ロール マッピング プロバイダは、WebLogic 認可プロバイダと同じポリシー エンジンを使用します。自社の既存のロール マッピング メカニズムを使用する場合は、カスタム ロール マッピング プロバイダを作成してそれを既存のメカニズムに結合できます。
WebLogic ロール マッピング プロバイダが開発者の要求を満たさない場合、次の手順でカスタム ロール マッピング プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ロール マッピング プロバイダの実行時クラスを作成します。
注意: セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダが DeployableRoleProvider SSPI を実装する必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
カスタム ロール マッピング プロバイダの実行時クラスの作成例については、例 : サンプル ロール マッピング プロバイダの実行時クラスの作成を参照してください。
RoleProvider SSPI を実装するには、「Provider」SSPI の目的を理解するで説明されているメソッドと以下のメソッドの実装を提供する必要があります。
RoleProvider SSPI および getRoleMapper メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
DeployableRoleProvider SSPI を実装する
DeployableRoleProvider SSPI を実装するには、「Provider」SSPI の目的を理解するおよびRoleProvider SSPI を実装するで説明されているメソッドと以下のメソッドの実装を提供する必要があります。
DeployableRoleProvider SSPI と deployRole メソッドおよび undeployRole メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
RoleMapper SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
RoleMapper SSPI および getRoles メソッドの詳細については、WebLogic Server 7.0 API リファレンス Javadoc を参照してください。
レルム アダプタ認証プロバイダと互換性のあるカスタム ロール マッピング プロバイダの開発
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループは、ロール マッピング プロバイダなどの他のタイプのセキュリティ プロバイダによってサブジェクトから抽出されます。 セキュリティ レルムでコンフィグレーションされている認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは若干異なる方法でサブジェクトに格納されます。 そのため、こうしたユーザおよびグループの情報の抽出も、若干異なる方法で行う必要があります。
サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかを調べるためにカスタム ロール マッピング プロバイダで使用できるコードをリスト8-1 に示します。 このコードは、getRoles メソッドに記述できます。
コード リスト 8-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;
}
SecurityRole インタフェースのメソッドを使用して、セキュリティ ロールに関する基本的な情報を取得したり、取得した情報を別のセキュリティ ロールと比較したりできます。これらのメソッドは、セキュリティ プロバイダの利便性のために設計されています。
注意: SecurityRole 実装は、getRoles() メソッドによって Map として返されます。RoleMapper SSPI を実装するを参照してください。
SecurityRole インタフェースを実装するには、以下のメソッドの実装を提供する必要があります。
例 : サンプル ロール マッピング プロバイダの実行時クラスの作成
リスト8-2 は、サンプル ロール マッピング プロバイダの実行時クラスである SampleRoleMapperProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
注意: リスト8-2 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 8-2 SampleRoleMapperProviderImpl.java
package examples.security.providers.roles;
import java.security.Principal;
import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.Properties;
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.DeployableRoleProvider;
import weblogic.security.spi.Resource;
import weblogic.security.spi.RoleCreationException;
import weblogic.security.spi.RoleMapper;
import weblogic.security.spi.RoleRemovalException;
import weblogic.security.spi.SecurityServices;
public final class SampleRoleMapperProviderImpl implements DeployableRoleProvider, RoleMapper
{
private String description;
private SampleRoleMapperDatabase database;
private static final Map NO_ROLES = Collections.unmodifiableMap(new
HashMap(1));
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SampleRoleMapperProviderImpl.initialize");
SampleRoleMapperMBean myMBean = (SampleRoleMapperMBean)mbean;
description = myMBean.getDescription() + "¥n" + myMBean.getVersion();
database = new SampleRoleMapperDatabase(myMBean);
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SampleRoleMapperProviderImpl.shutdown");
}
public RoleMapper getRoleMapper()
{
return this;
}
public Map getRoles(Subject subject, Resource resource, ContextHandler
handler)
{
System.out.println("SampleRoleMapperProviderImpl.getRoles");
System.out.println("¥tsubject¥t= " + subject);
System.out.println("¥tresource¥t= " + resource);
Map roles = new HashMap();
Set principals = subject.getPrincipals();
for (Resource res = resource; res != null; res = res.getParentResource())
{
getRoles(res, principals, roles);
}
getRoles(null, principals, roles);
if (roles.isEmpty()) {
return NO_ROLES;
}return roles;
}
public void deployRole(Resource resource, String roleName, String[]
principalNames) throws RoleCreationException
{
System.out.println("SampleRoleMapperProviderImpl.deployRole");
System.out.println("¥tresource¥t¥t= " + resource);
System.out.println("¥troleName¥t¥t= " + roleName);
for (int i = 0; principalNames != null && i < principalNames.length; i++)
{
System.out.println("¥tprincipalNames[" + i + "]¥t= " +
principalNames[i]);
}
database.setRole(resource, roleName, principalNames);
}
public void undeployRole(Resource resource, String roleName) throws
RoleRemovalException
{
System.out.println("SampleRoleMapperProviderImpl.undeployRole");
System.out.println("¥tresource¥t= " + resource);
System.out.println("¥troleName¥t= " + roleName);
database.removeRole(resource, roleName);
}
private void getRoles(Resource resource, Set principals, Map roles)
{
for (Enumeration e = database.getRoles(resource); e.hasMoreElements();)
{
String role = (String)e.nextElement();
if (roleMatches(resource, role, principals))
{
roles.put(role, new SampleSecurityRoleImpl(role, "no description"));
}
}
}
private boolean roleMatches(Resource resource, String role, Set
principalsHave)
{
for (Enumeration e = database.getPrincipalsForRole(resource, role);
e.hasMoreElements();)
{
String principalWant = (String)e.nextElement();
if (principalMatches(principalWant, principalsHave))
{
return true;
}
}
return false;
}
private boolean principalMatches(String principalWant, Set principalsHave)
{
if (WLSPrincipals.getEveryoneGroupname().equals(principalWant) ||
(WLSPrincipals.getUsersGroupname().equals(principalWant) &&
!principalsHave.isEmpty()) || (WLSPrincipals.getAnonymousUsername().
equals(principalWant) && principalsHave.isEmpty()) ||
principalsContain(principalsHave, principalWant))
{
return true;
}
return false;
}
private boolean principalsContain(Set principalsHave, String
principalNameWant)
{
for (Iterator i = principalsHave.iterator(); i.hasNext();)
{
Principal principal = (Principal)i.next();
String principalNameHave = principal.getName();
if (principalNameWant.equals(principalNameHave))
{
return true;
}
}
return false;
}
}
リスト8-3 は、SampleRoleMapperProviderImpl.java 実行時クラスと共に使用される SecurityRole 実装を示しています。
コード リスト 8-3 SampleSecurityRoleImpl.java
package examples.security.providers.roles;
import weblogic.security.service.SecurityRole;
public class SampleSecurityRoleImpl implements SecurityRole
{
private String _roleName;
private String _description;
private int _hashCode;
public SampleSecurityRoleImpl(String roleName, String description)
{
_roleName = roleName;
_description = description;
_hashCode = roleName.hashCode() + 17;
}
public boolean equals(Object secRole)
{
if (secRole == null)
{
return false;
}
if (this == secRole)
{
return true;
}
if (!(secRole instanceof SampleSecurityRoleImpl))
{
return false;
}
SampleSecurityRoleImpl anotherSecRole = (SampleSecurityRoleImpl)secRole;
if (!_roleName.equals(anotherSecRole.getName()))
{
return false;
}
return true;
}
public String toString () { return _roleName; }
public int hashCode () { return _hashCode; }
public String getName () { return _roleName; }
public String getDescription () { return _description; }
}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 にカスタム操作を含めない場合、次の手順に従います。
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 で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
カスタム ロール マッピング プロバイダの MDF にカスタム操作を含める場合、質問に答えながら手順を進めてください。
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 で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
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 で指定された場所にファイルが既に存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「Provider」SSPI の目的を理解するで説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で SampleRoleMapper MDF を実行すると、SampleRoleMapperMBean.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 デプロイメント記述子ファイル (リスト8-4 およびリスト8-5 の 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>
コード リスト 8-5 weblogic.xml ファイルのサンプル
<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 デプロイメント記述子を使用します。
[デプロイメント記述子内のセキュリティ データを無視] チェックボックスは、認可プロバイダおよび資格マッピング プロバイダにも影響します。詳細については、それぞれ認可プロバイダとデプロイメント記述子の管理と資格マッピング プロバイダ、リソース アダプタ、およびデプロイメント記述子の管理を参照してください。
DeployableRoleProvider SSPI を実装し、カスタム ロール マッピング プロバイダでデプロイ可能なセキュリティ ロールをサポートしたい場合、カスタム ロール マッピング プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ロール デプロイメントを有効化] チェックボックスがチェックされていることを確認する必要があります。チェックがはずれていると、ロール マッピング プロバイダに対するデプロイメントは「オフ」と見なされます。 このため、複数のロール マッピング プロバイダがコンフィグレーションされている場合、[ロール デプロイメントを有効化] チェックボックスを使用すると、セキュリティ ロールのデプロイメントに使用するロール マッピング プロバイダを指定できます。
注意: [デプロイメント記述子内のセキュリティ データを無視] チェックボックス (ロール マッピング プロバイダとデプロイメント記述子の管理で説明したようにセキュリティ レルム レベルで指定) では、コンフィグレーション済みのロール マッピング プロバイダのセキュリティ データベースにセキュリティ ロールをコピーするかどうかを指定します。 [ロール デプロイメントを有効化] チェックボックス (コンフィグレーション済みのロール マッピング プロバイダごとに指定) では、ロール マッピング プロバイダがデプロイ済みのセキュリティ ロールを格納するかどうかを指定します。
WebLogic Server Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションすると、必要なロール マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ロールを管理する方法を管理者にも提供する必要があります。 たとえば WebLogic ロール マッピング プロバイダには、さまざまな WebLogic リソースのセキュリティ ロールを追加、変更、または削除するためのロール エディタ ページ (図 8-2を参照) が管理者向けに用意されています。このページは、特定のグローバル ロールまたはスコープ ロールの [条件] タブに表示されます。
図8-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 から起動する場合には、この方法を選択します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
