WebLogic セキュリティ プロバイダの開発
|
 |
 |
|
ロール マッピングとは、実行時にプリンシパル (ユーザまたはグループ) をセキュリティ ロールに動的に割り当てるプロセスのことです。WebLogic Server では、ロール マッピング プロバイダは、WebLogic リソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ ロールを調べます。通常、この操作では WebLogic リソースへのアクセスを取得する必要があるので、ロール マッピング プロバイダは認可プロバイダと共に使用するのが一般的です。
以下の節では、ロール マッピング プロバイダの概念と機能、およびカスタム ロール マッピング プロバイダの開発手順について説明します。
ロール マッピング プロバイダを開発する前に、以下の概念を理解しておく必要があります。
セキュリティ ロールは、WebLogic リソースへの同じアクセス パーミッションを持つユーザまたはグループの集合です。グループと同様、セキュリティ ロールを使用すると、複数のユーザによる WebLogic リソースへのアクセスを一度に制御できます。しかし、セキュリティ ロールは WebLogic Server ドメインの特定のリソースを対象としており (WebLogic Server ドメイン全体を対象とするグループとは異なる)、動的に定義することが可能です。「動的セキュリティ ロール計算」を参照してください。
注意 : セキュリティ ロールの詳細については、『WebLogic リソースのセキュリティ』の「ユーザ、グループ、セキュリティ ロール」を参照してください。WebLogic リソースの詳細については、「セキュリティ プロバイダと WebLogic リソース」および『WebLogic リソースのセキュリティ』の「WebLogic リソースのタイプ」を参照してください。
weblogic.security.service パッケージに定義されている SecurityRole インタフェースは、セキュリティ ロールの抽象的な記法を表すのに用いられます。詳細については、WebLogic Server 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 リソース」を参照してください。
リソース コンテナは、サブジェクト (ユーザおよびグループ プリンシパルを含む)、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 認可プロバイダと同じポリシー エンジンを使用します。自社の既存のロール マッピング メカニズムを使用する場合は、カスタム ロール マッピング プロバイダを作成してそれを既存のメカニズムに結合できます。
セキュリティ レルムのすべての認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール マッピング、または資格マッピング用にカスタム セキュリティ プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションの SSPI を実装する必要があります。
WebLogic ロール マッピング プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム ロール マッピング プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ロール マッピング プロバイダの実行時クラスを作成します。
注意 : セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダが DeployableRoleProviderV2 SSPI を実装する必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
カスタム ロール マッピング プロバイダの実行時クラスの作成例については、「例 : サンプル ロール マッピング プロバイダの実行時クラスを作成する」を参照してください。
RoleProvider SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
RoleProvider SSPI と getRoleMapper メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
注意 : DeployableRoleProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。DeployableRoleProviderV2 SSPI を代わりに使用してください。
DeployableRoleProviderV2 SSPI を実装するには、「「Provider」SSPI の目的について」および「RoleProvider SSPI を実装する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
void deployRole(DeployRoleHandle handle, Resource resource, String roleName, String[] userAndGroupNames)
デプロイされた Web アプリケーションまたは EJB に代わってロールを作成します。ロールがすでに存在する場合は削除され、このロールによって置き換えられます。
DeployRoleHandle startDeployRoles(ApplicationInfo application)
アプリケーションのロール デプロイメントの開始をマークし、アプリケーションが対象指定されている WebLogic Server ドメイン内のすべてのサーバで呼び出されます。
DeployableRoleProvider SSPI と deployRole および undeployRole メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
ApplicationInfo インタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ プロバイダに渡します。このデータを使用すると、アプリケーションをユニークに識別できます。
セキュリティ フレームワークは、ユーザの利便を図るために ApplicationInfo インタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。
DeployableAuthorizationProviderV2 インタフェースと DeployableRoleProviderV2 インタフェースは ApplicationInfo を使用します。たとえば、DeployableRoleProviderV2 メソッドの実装を例に挙げます。WebLogic Security フレームワークは、DeployableRoleProviderV2 startDeployRoles メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。ApplicationInfo データは、アプリケーションのデプロイ時に Administration Console で提供される情報を基に決められます。
startDeployRoles メソッドは、他の DeployableRoleProviderV2 メソッドでこの後使用できる DeployRoleHandle を返します。
ApplicationInfo インタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentType クラスの定義に従って、APPLICATION、CONTROL_RESOURCE、EJB、または WEBAPP のいずれかです。
public DeployRoleHandle startDeployRoles(ApplicationInfo appInfo)
throws DeployHandleCreationException
:
// アプリケーション情報を取得する...
String appId = appInfo.getApplicationIdentifier();
ComponentType compType = appInfo.getComponentType();
String compName = appInfo.getComponentName();
WebLogic Security フレームワークは、DeployableRoleProviderV2 deleteApplicationRoles メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。deleteApplicationRoles メソッドは、アプリケーションのすべてのロールを削除し、アプリケーションが削除された時点で WebLogic Server ドメイン内の管理サーバでのみ呼び出されます。
RoleMapper SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
public Map getRoles(Subject subject, Resource resource, ContextHandler handler)
getRoles メソッドは、場合によっては ContextHandler を使用して、特定の WebLogic リソースに関して特定のサブジェクトに関連付けられているセキュリティ ロールを返します。ContextHandler の詳細については、「ContextHandler と WebLogic リソース」を参照してください。
RoleMapper SSPI と getRoles メソッドの詳細については、WebLogic Server 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 は、サンプル ロール マッピング プロバイダの実行時クラスである SimpleSampleRoleMapperProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、および shutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的について」を参照)RoleProvider SSPI から継承した getRoleMapper メソッド (「RoleProvider SSPI を実装する」を参照)DeployableRoleProviderV2 SSPI の deleteApplicationRoles、deployRole、endDeployRoles、startDeployRoles、および undeployAllRoles メソッド (「DeployableRoleProviderV2 SSPI を実装する」を参照)RoleMapper SSPI の getRoles メソッド (「RoleMapper SSPI を実装する」を参照)注意 : コード リスト 8-2 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 8-2 SimpleSampleRoleMapperProviderImpl.java
package examples.security.providers.roles.simple;
import java.security.Principal;
import java.util.Collections;
import java.util.Date;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.HashSet;
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.SubjectUtils;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.ApplicationInfo;
import weblogic.security.spi.ApplicationInfo.ComponentType;
import weblogic.security.spi.DeployableRoleProviderV2;
import weblogic.security.spi.DeployRoleHandle;
import weblogic.security.spi.Resource;
import weblogic.security.spi.RoleMapper;
import weblogic.security.spi.SecurityServices;
import weblogic.security.spi.VersionableApplicationProvider;
public final class SimpleSampleRoleMapperProviderImpl
implements DeployableRoleProviderV2, RoleMapper, VersionableApplicationProvider
{
private String description; // このプロバイダの説明
private SimpleSampleRoleMapperDatabase database; // このプロバイダのロール定義を管理する
private static final Map NO_ROLES = Collections.unmodifiableMap(new HashMap(1)); // ルールが見つからない場合に使用する
public void initialize(ProviderMBean mbean, SecurityServices services){
System.out.println("SimpleSampleRoleMapperProviderImpl.initialize");
// 汎用 ProviderMBean から SimpleSampleRoleMapperMBean に MBean をキャストする。
SimpleSampleRoleMapperMBean myMBean = (SimpleSampleRoleMapperMBean)mbean;
// 単純なサンプル ロール マッピング プロバイダの MBean の説明とバージョンを説明として設定する
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
// このプロバイダのロール定義を管理するヘルパーをインスタンス化する
database = new SimpleSampleRoleMapperDatabase(myMBean);
}
public String getDescription()
{
return description;
}
public void shutdown(){
System.out.println("SimpleSampleRoleMapperProviderImpl.shutdown");
}
public RoleMapper getRoleMapper()
{
// このクラスは DeployableRoleProvider インタフェースと
// RoleMapper インタフェースを実装するので、このクラスは
// ロール マッピング プロバイダとなり、「this」のみを返す。
return this;
}
public Map getRoles(Subject subject, Resource resource, ContextHandler handler)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.getRoles");
System.out.println("\tsubject\t= " + subject);
System.out.println("\tresource\t= " + resource);
// ロール用にリストを作成する
Map roles = new HashMap();
// 評価済みの既存のロール用にリストを作成する
Set rolesEvaluated = new HashSet();
// リソース スコープのロールおよびリソースが階層化されているので、
// 現在のサブジェクトに一致するロールに追加する形で、
// リソースとその親を繰り返しループする。
for (Resource res = resource; res != null; res = res.getParentResource()) {
getRoles(res, subject, roles, rolesEvaluated);
}
// グローバル リソースについても試行する
getRoles(null, subject, roles, rolesEvaluated);
// 一致するルールがない場合の特別な処理
if (roles.isEmpty()) {
return NO_ROLES;
}
// 見つかったロールを返す。
System.out.println("\troles\t= " + roles);
return roles;
}
public DeployRoleHandle startDeployRoles(ApplicationInfo application){
String appId = application.getApplicationIdentifier();
String compName = application.getComponentName();
ComponentType compType = application.getComponentType();
DeployRoleHandle handle = new SampleDeployRoleHandle(appId,compName,compType);
// 以前のロールが削除されたので、最新の
// ロールが有効になっていることを確認する
database.removeRolesForComponent(appId, compName, compType);
// 必要に応じて null ハンドルを返す可能性がある
return handle;
}
public void deployRole(DeployRoleHandle handle, Resource resource,{
String roleName, String[] principalNames)
System.out.println("SimpleSampleRoleMapperProviderImpl.deployRole");
System.out.println("\thandle\t\t= " + ((SampleDeployRoleHandle)handle).toString());
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 endDeployRoles(DeployRoleHandle handle){
database.saveRoles();
}
public void undeployAllRoles(DeployRoleHandle handle){
System.out.println("SimpleSampleRoleMapperProviderImpl.undeployAllRoles");
SampleDeployRoleHandle myHandle = (SampleDeployRoleHandle)handle;
System.out.println("\thandle\t= " + myHandle.toString());
// ロールを削除する
database.removeRolesForComponent(myHandle.getApplication(),
myHandle.getComponent(),
myHandle.getComponentType());
}public void deleteApplicationRoles(ApplicationInfo application){
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplicationRoles");
String appId = application.getApplicationIdentifier();
System.out.println("\tapplication identifier\t= " + appId);
// アプリケーションのロールを削除する
database.removeRolesForApplication(appId);
}
private void getRoles(Resource resource, Subject subject,
Map roles, Set rolesEvaluated)
{
// このリソースの「データベース」内の全ロールを繰り返しループする
for (Enumeration e = database.getRoles(resource); e.hasMoreElements();) {
String role = (String)e.nextElement();
// まだ評価されていないロールがあるかどうかのみをチェックする
if (rolesEvaluated.contains(role)) {
continue;
}
// 評価済みリストにロールを追加する
rolesEvaluated.add(role);
// ロール上にいずれかのプリンシパルがある場合、そのロールをリストに追加する。
if (roleMatches(resource, role, subject)) {
// 単純なサンプル ロール マッピング プロバイダのロール インスタンスをロールのリストに追加する。
roles.put(role, new SimpleSampleSecurityRoleImpl(role));
}
}
}
private boolean roleMatches(Resource resource, String role, Subject subject){
// このロール内のプリンシパルを繰り返しループする。
for (Enumeration e = database.getPrincipalsForRole(resource, role); e.hasMoreElements();) {
// このロールの次のプリンシパルを取得する
String principalWant = (String)e.nextElement();
// 現在のプリンシパルのいずれかがこのプリンシパルに一致しているかどうかを確認する
if (subjectMatches(principalWant, subject)) {
return true;
}
}
return false;
}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;
}public void createApplicationVersion(String appId, String sourceAppId){
System.out.println("SimpleSampleRoleMapperProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));
// 既存のアプリケーションを指定したときに新しいロールを作成する
if (sourceAppId != null) {
database.cloneRolesForApplication(sourceAppId,appId);
}
}public void deleteApplicationVersion(String appId){
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
// アプリケーションのロールを削除する
database.removeRolesForApplication(appId);
}public void deleteApplication(String appName){
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);
// アプリケーションのロールを削除する
database.removeRolesForApplication(appName);
}
class SampleDeployRoleHandle implements DeployRoleHandle
{
Date date;
String application;
String component;
ComponentType componentType;
SampleDeployRoleHandle(String app, String comp, ComponentType type)
{
this.application = app;
this.component = comp;
this.componentType = type;
this.date = new Date();
}
public String getApplication() { return application; }
public String getComponent() { return component; }
public ComponentType getComponentType() { return componentType; }
public String toString()
{
String name = component;
if (componentType == ComponentType.APPLICATION)
name = application;
return componentType +" "+ name +" ["+ date.toString() +"]";
}
}
}
コード リスト 8-3 は、SimpleSampleRoleMapperProviderImpl.java 実行時クラスとともに使用する SecurityRole のサンプル実装を示しています。
コード リスト 8-3 SimpleSampleSecurityRoleImpl.java
package examples.security.providers.roles.simple;
import weblogic.security.service.SecurityRole;
/*package*/ class SimpleSampleSecurityRoleImpl implements SecurityRole
{
private String roleName; // ロールの名前
private int hashCode; // ロールのハッシュ コード
/*package*/ SimpleSampleSecurityRoleImpl(String roleName)
{
this.roleName = roleName;
this.hashCode = roleName.hashCode() + 17;
}
public boolean equals(Object genericRole)
{
// 他のロールが null の場合は、同じではない
if (genericRole == null) {
return false;
}
// 同じ Java オブジェクトの場合は、同じ
if (this == genericRole) {
return true;
}
// 他のロールが単純なサンプル ロール マッピング プロバイダのロールではない場合、
// 同じではない
if (!(genericRole instanceof SimpleSampleSecurityRoleImpl)) {
return false;
}
// 他のロールを単純なサンプル ロール マッピング プロバイダのロールにキャストする。
SimpleSampleSecurityRoleImpl sampleRole =
(SimpleSampleSecurityRoleImpl)genericRole;
// 名前が一致しない場合、同じではない
if (!roleName.equals(sampleRole.getName())) {
return false;
}
// 同じ
return true;
}
public String toString()
{
return roleName;
}
public int hashCode()
{
return hashCode;
}
public String getName()
{
return roleName;
}
public String getDescription()
{
return "";
}
}
カスタム セキュリティ プロバイダの 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 にカスタム操作を含めない場合、次の手順に従います。
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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまりロール マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
カスタム ロール マッピング プロバイダの 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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、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 を作成するには、次の手順に従います。
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを含む JAR ファイルを構築すべきであることを示し、jarfile は MJF の名前、filesdir は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所を示します。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。
注意 : カスタム セキュリティ プロバイダの JAR ファイルを作成する際には、一連の XML バインディング クラスと 1 つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム クラスと BEA のカスタム クラスとの衝突を防ぐことができます。ネームスペースのデフォルトは vendor です。-targetNameSpace 引数を WebLogicMBeanMaker または関連する WLMBeanMaker ant タスクに渡すと、このデフォルトを変更できます。
既存の 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 です。初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\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 Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションする手順は、『WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で説明されています。
エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーションの中には、Java 2 Enterprise Edition (J2EE) の関連デプロイメント情報と WebLogic Server デプロイメント記述子を格納するものがあります。Web アプリケーションの場合、デプロイメント記述子ファイル (web.xml と weblogic.xml) には、セキュリティ ロールを含む J2EE セキュリティ モデルの実装情報が格納されます。この情報は、WebLogic Server Administration Console でロール マッピング プロバイダを初めてコンフィグレーションするときに格納するのが一般的です。
J2EE プラットフォームはデプロイメント記述子で Web アプリケーションおよび EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーションおよび EJB リソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも Administration Console のみを使用することもできます。また、状況によっては、この 2 つの方法を組み合わせることもできます。
選択した方法によって、セキュリティ モデルを適用する必要もあります。WebLogic では、個々のデプロイメントについて複数のセキュリティ モデルがサポートされ、使用する方法を組み込むレルム全体のコンフィグレーションについてはセキュリティ モデルがサポートされます。
詳細については、『WebLogic リソースのセキュリティ』の「EJB および Web アプリケーション リソースの保護のオプション」を参照してください。
デプロイメント記述子を使用するようにコンフィグレーションすると、WebLogic Server は、web.xml および weblogic.xml デプロイメント記述子ファイルからセキュリティ ロール情報を読み込みます (web.xml ファイルと weblogic.xml ファイルの例については、コード リスト 8-4 とコード リスト 8-5 を参照)。この情報は、ロール マッピング プロバイダのセキュリティ プロバイダ データベースにコピーされます。
<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>
カスタム ロール マッピング プロバイダの開発の一環として DeployableRoleProviderV2 SSPI を実装し、カスタム ロール マッピング プロバイダでデプロイ可能なセキュリティ ロールをサポートしたい場合、カスタム ロール マッピング プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ロール デプロイメントを有効化] フラグがチェックされていることを確認する必要があります。チェックがはずれていると、ロール マッピング プロバイダに対するデプロイメントは「オフ」と見なされます。このため、複数のロール マッピング プロバイダがコンフィグレーションされている場合、[ロール デプロイメントを有効化] ボックスを使用して、セキュリティ ロールのデプロイメントに使用するロール マッピング プロバイダを指定できます。
WebLogic Server Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションすると、必要なロール マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ロールを管理する方法を管理者にも提供する必要があります。たとえば WebLogic ロール マッピング プロバイダには、ロール エディタ ページが管理者向けに用意されており、さまざまな WebLogic リソースのセキュリティ ロールを追加、変更、または削除することができます。
カスタム ロール マッピング プロバイダを開発すると、管理者はロール エディタ ページも右クリック メニューも利用できません。したがって、セキュリティ ロールを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム ロール マッピング プロバイダのデータベースのセキュリティ ロール データ (つまり式) を読み書きできなければなりません。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム ロール マッピング プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
|
|
|