WebLogic Security サービスの開発
|
 |
 |
|
ロール マッピングとは、実行時にプリンシパル (ユーザまたはグループ) をセキュリティ ロールに動的に割り当てるプロセスのことです。WebLogic Server では、ロール マッピング プロバイダは、WebLogic リソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ ロールを調べます。通常、この操作では WebLogic リソースへのアクセスを取得する必要があるので、ロール マッピング プロバイダは認可プロバイダと共に使用するのが一般的です。
以下の節では、ロール マッピング プロバイダの概念と機能、およびカスタム ロール マッピング プロバイダの開発手順について説明します。
ロール マッピング プロバイダを開発する前に、以下の概念を理解しておく必要があります。
セキュリティ ロールは、WebLogic リソースへの同じアクセス パーミッションを持つユーザまたはグループの集合です。グループと同様、セキュリティ ロールを使用すると、複数のユーザによる WebLogic リソースへのアクセスを一度に制御できます。しかし、セキュリティ ロールは WebLogic Server ドメインの特定のリソースを対象としており (WebLogic Server ドメイン全体を対象とするグループとは異なる)、動的に定義することが可能です。「動的セキュリティ ロール計算」を参照してください。
注意 : セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロール」を参照してください。WebLogic リソースの詳細については、「セキュリティ プロバイダと WebLogic リソース」および『WebLogic リソースのセキュリティ』の「WebLogic リソースのタイプ」を参照してください。
weblogic.security.service パッケージに定義されている SecurityRole インタフェースは、セキュリティ ロールの抽象的な記法を表すのに用いられます。詳細については、WebLogic Server 8.1 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 を用いて、リクエストに関するさまざまな情報を要求します。また、ロール マッピング プロバイダは、要求する情報のタイプを表す一連の Callback オブジェクトを作成します。その Callback オブジェクト群は、handle メソッドを通じて、配列として ContextHandler に渡されます。ロール マッピング プロバイダは、必要なコンテキスト情報を取得するのに、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 8.1 API リファレンス Javadoc」 を参照してください。
DeployableRoleProvider SSPI を実装するには、「「Provider」SSPI の目的を理解する」および「RoleProvider SSPI を実装する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
public void deployRole(Resource resource, java.lang.String roleName, java.lang.String[] userAndGroupNames) throws RoleCreationException
deployRole メソッドは、セキュリティ ロールの適用対象となる WebLogic リソース、アプリケーション内でのセキュリティ ロールの名前、およびセキュリティ ロールに割り当てられるユーザおよびグループ名を基に、デプロイ済みの Web アプリケーションや EJB に代わってセキュリティ ロールを作成します。
DeployableRoleProvider SSPI と deployRole および undeployRole メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」を参照してください。
RoleMapper SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
public Map getRoles(Subject subject, Resource resource, ContextHandler handler)
getRoles メソッドは、場合によっては ContextHandler を使用して、特定の WebLogic リソースに関して特定のサブジェクトに関連付けられているセキュリティ ロールを返します。ContextHandler の詳細については、「ContextHandler と WebLogic リソース」を参照してください。
RoleMapper SSPI と getRoles メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」 を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、ロール マッピング プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 8-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするために、カスタム ロール マッピング プロバイダが使用できるコードを示しています。このコードは、getRoles メソッドに属しています。
コード リスト 8-1サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするサンプル コード
/**
* サブジェクトがユーザ/グループ名に一致するかどうかを判断する
*
* @param principalWant このロール内のプリンシパルの名前を含む文字列
* (ロール定義)
*
* @param subject ユーザのグループだけでなくリソースにもアクセスしようとしている
* ユーザを識別するプリンシパルを含むサブジェクト
*
* @return 現在のサブジェクトがロール内のプリンシパル名に一致していれば true、
* それ以外の場合は false の boolean
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// 最初に、グループ名の一致かどうかを確認
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// 2 番目に、ユーザ名の一致かどうかを確認
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// 一致せず
return false;
}
SecurityRole インタフェースのメソッドを使用して、セキュリティ ロールに関する基本的な情報を取得したり、取得した情報を別のセキュリティ ロールと比較したりできます。これらのメソッドは、セキュリティ プロバイダの利便性のために設計されています。
注意 : SecurityRole 実装は、getRoles() メソッドによって Map として返されます。「RoleMapper SSPI を実装する」を参照してください。
SecurityRole インタフェースを実装するには、以下のメソッドの実装を提供する必要があります。
コード リスト 8-2 は、サンプル ロール マッピング プロバイダの実行時クラスである SampleRoleMapperProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、および shutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的を理解する」を参照)RoleProvider SSPI から継承した getRoleMapper メソッド (「RoleProvider SSPI を実装する」を参照)DeployableRoleProvider SSPI の deployRole および undeployRole メソッド (「DeployableRoleProvider SSPI を実装する」を参照)RoleMapper SSPI の getRoles メソッド (「RoleMapper SSPI を実装する」を参照)注意 : コード リスト 8-2 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 8-2SampleRoleMapperProviderImpl.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.util.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; }
}
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ロール マッピング プロバイダの MBean タイプを作成します。
注意 : これらの手順の実行方法は、いくつかのサンプル セキュリティ プロバイダ (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) に示されています。
この節で説明する手順はすべて、Windows 環境での作業を想定しています。
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
注意 : MDF 要素の構文についての完全なリファレンスは、「MBean 定義ファイル (MDF) 要素の構文」に収められています。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム ロール マッピング プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム ロール マッピング プロバイダの MDF にカスタム操作を含めない場合、次の手順に従います。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまりロール マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
カスタム ロール マッピング プロバイダの MDF にカスタム操作を含める場合、質問に答えながら手順を進めてください。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまりロール マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまりロール マッピング プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的を理解する」で説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で SampleRoleMapper MDF を実行すると、SampleRoleMapperMBean.java という MBean インタフェース ファイルが生成されます。
WebLogic MBeanMaker で MDF を実行して中間ファイルを作成し、MBean 実装ファイルを手作業で編集してその中にメソッドの内容を記述したら、カスタム ロール マッピング プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。
カスタム ロール マッピング プロバイダの MJF を作成するには、次の手順に従います。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -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 環境にインストールしてもらうこともできます。
MBean タイプを WebLogic Server 環境にインストールするには、MJF を WebLogic Server の WL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。このインストール コマンドによって、カスタム ロール マッピング プロバイダが「デプロイ」されます。つまり、カスタム ロール マッピング プロバイダを WebLogic Server Administration Console から管理できるようになります。
注意 : MBean タイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypes です。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用すれば、WebLogic Server が追加ディレクトリで MBean タイプを検索します。<dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードします。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server は最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードしてから、dirX および dirY にある有効なアーカイブをロードします。WebLogic Server に追加ディレクトリで MBean タイプを検索するように指示する際に Java セキュリティ マネージャを使用している場合には、weblogic.policy ファイルを更新して、MBean タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『WebLogic Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
カスタム ロール マッピング プロバイダをコンフィグレーションすることによって (「Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションする」を参照)、MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。詳細については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」の「セキュリティ データのバックアップ」を参照してください。
カスタム ロール マッピング プロバイダをコンフィグレーションするということは、ロール マッピング サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム ロール マッピング プロバイダを追加するということです。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム ロール マッピング プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。
注意 : 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 には、この目的のために [今後の再デフォルトの設定] ドロップダウン メニューが用意されています。開発者または管理者は、カスタム ロール マッピング プロバイダを初めてコンフィグレーションするときにこのメニューに [デプロイメント記述子のロールとポリシーを初期化] が設定されていることを確認する必要があります。
注意 : [今後の再デフォルトの設定] ドロップダウン メニューは、デフォルトで [デプロイメント記述子のロールとポリシーを初期化] に設定されています。[今後の再デフォルトの設定] ドロップダウン メニューにアクセスするには、Administration Console の左ペインで [セキュリティ｜レルム｜realm] (realm はセキュリティ レルムの名前) をクリックします。
このドロップダウン メニューの値が [デプロイメント記述子のロールとポリシーを初期化] で、Web アプリケーションがデプロイされた場合、WebLogic Server は、web.xml および weblogic.xml デプロイメント記述子ファイル(コード リスト 8-4 と コード リスト 8-5 の例を参照) からセキュリティ ロール情報を読み出します。この情報は、ロール マッピング プロバイダのセキュリティ プロバイダ データベースにコピーされます。
注意 : [ロールとポリシーのチェック対象] ドロップダウン メニューの値を [すべての Web アプリケーションと EJB] に変更した場合は、[今後の再デプロイの設定] ドロップダウン メニューの値だけを変更できます。詳細については、『WebLogic リソースのセキュリティ』の「URL リソースおよび EJB リソースを保護する方法」および「URL リソースおよび EJB リソースを保護するための前提条件」を参照してください。
<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 アプリケーションまたは EJB のデプロイメント記述子で定義したセキュリティ ロールをいったんコピーしてから Administration Console を使用してロールを追加することをお勧めします。この理由は、ロール マッピング プロバイダのコンフィグレーション中に Administration Console を使用してセキュリティ ロールを変更すると、その内容が web.xml および weblogic.xml ファイルに保持されないからです。Administration Console を使用して再デプロイする、ディスク上で Web アプリケーションを変更した、または WebLogic Server を再起動したといった場合に、Web アプリケーションを再デプロイするときには、[今後の再デプロイの設定] ドロップダウン メニューの値を [デプロイメント記述子のロールとポリシーを無視] に設定する必要があります。設定しないと、Administration Console を使用して定義したロールがデプロイメント記述子で定義されているセキュリティ ロールによって上書きされます。詳細については、『WebLogic リソースのセキュリティ』の「組み合わせた方法による URL リソースと 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 ロール マッピング プロバイダのロール エディタ ページ
カスタム ロール マッピング プロバイダを開発すると、管理者はロール エディタ ページも右クリック メニューも利用できません。したがって、セキュリティ ロールを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム ロール マッピング プロバイダのデータベースのセキュリティ ロール データ (つまり式) を読み書きできなければなりません。
カスタム ロール マッピング プロバイダ用にコンソール拡張を作成する方法の主な利点は、コンソール拡張によって WebLogic リソースの ID がわかるので、その WebLogic リソースがリソース階層のどこにあるかもわかるということです。この情報は、ロール マッピング プロバイダのデータベースから式を読み書きするために必要です。また、WebLogic ロール マッピング プロバイダのロール エディタ ページのように、作成したページを既存の WebLogic Server Administration Console の GUI に統合できるという利点もあります。
weblogic.management.console.extensibility.SecurityExtensionV2 インタフェースの getExtensionForRole() メソッドを実装し、作成したロール エディタ ページをこのメソッドで返します。 注意 : 詳細については、「カスタム セキュリティ プロバイダ用のコンソール拡張の記述」を参照してください。
RoleEditor および RoleReader 認可用任意 SSPI MBean を実装し、作成したロール エディタ ページとカスタム ロール マッピング プロバイダのデータベースとの間の仲介役となる管理 MBean を開発します。詳細については、「拡張および実装する SSPI MBean を決定する」 と「表 2-4」を参照してください。注意 : この構文は、ロール マッピング プロバイダごとに異なっていてもかまいません。式の詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロールの構成要素 : ロール条件、式、およびロール文」を参照してください。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法の場合、「オプション 1 : コンソール拡張を使用して独自の「ロール エディタ」ページを作成する」で説明したカスタム ロール マッピング プロバイダ用のコンソール拡張を記述する必要もなく、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
|
|
|