WebLogic セキュリティ プロバイダの開発
|
 |
 |
|
認可とは、ユーザの ID などの情報に基づいて、ユーザと WebLogic リソースとのやり取りを管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Server では、認可プロバイダはユーザと WebLogic リソースとの対話を制限して、整合性、機密性、および可用性を確保します。
以下の節では、認可プロバイダの概念と機能、およびカスタム認可プロバイダの開発手順について説明します。
認可プロバイダを開発する前に、以下の概念を理解しておく必要があります。
認証プロバイダの LoginModule と同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作を WebLogic リソースに対して実行するパーミッションをサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答を PERMIT、DENY、または ABSTAIN のいずれかで返します。
注意 : アクセス決定の詳細については、「AccessDecision SSPI を実装する」を参照してください。
Java Authorization Contract for Containers (JACC) は J2EE 1.4 の一部です。JACC は、EJB およびサーブレットに対する Java 2 パーミッションベースのセキュリティ モデルです。JACC は、JSR-115 によって定義されます。
JACC は、WebLogic Server ドメイン内の EJB およびサーブレット コンテナに代替認証メカニズムを提供します。JACC がコンフィグレーションされている場合、WebLogic Security フレームワークのアクセス決定、裁決、およびロール マッピング機能は、EJB およびサーブレットの認可判定には使用されません。
注意 : WebLogic Security フレームワークと一緒に JACC フレームワークを使用することはできません。WebLogic Server で使用される JACC クラスには、決定を下すためのポリシー オブジェクトの実装は含まれません。代わりに、JACC クラスは、java.security.Policy オブジェクトに依存します。
WebLogic Server は、JSR-115 に完全に準拠しているものの、WebLogic 認証プロバイダほどには最適化されていない JACC プロバイダを実装します。Java JACC クラスは、アクセス決定を下す際に使用します。JSR-115 はロール マッピングに対処する方法を定義しないので、ロールとプリンシパルの間のマッピングには WebLogic JACC クラスが使用されます。JACC プロバイダの開発の詳細については、http://java.sun.com/j2ee/javaacc/ を参照してください。
図 6-1 に、認可プロセスにおける認可プロバイダ (および関連する裁決プロバイダとロール マッピング プロバイダ) と WebLogic Security フレームワークとの対話を示します。その後、この図について説明します。
注意 : リソース コンテナは、「セキュリティ プロバイダと WebLogic リソース」で説明されている WebLogic リソースのいずれかを処理するコンテナです。
ContextHandler オブジェクトを作成します。このオブジェクトは、コンフィグレーション済みのロール マッピング プロバイダと認可プロバイダのアクセス決定がそのリクエストのコンテキストに関連付けられている情報を取得するために使用できます。注意 : ContextHandler の詳細については、「ContextHandler と WebLogic リソース」を参照してください。アクセス決定の詳細については、「アクセス決定」を参照してください。ロール マッピング プロバイダの詳細については、「ロール マッピング プロバイダ」を参照してください。
リソース コンテナは、サブジェクト、WebLogic リソース、そして場合によっては決定用の追加入力を提供する ContextHandler オブジェクトを渡して WebLogic Security フレームワークを呼び出します。
ContextHandler を用いて、リクエストに関するさまざまな情報を要求します。また、ロール マッピング プロバイダは、要求する情報のタイプを表す一連の Callback オブジェクトを作成します。その Callback オブジェクト群は、handle メソッドを通じて、配列として ContextHandler に渡されます。ロール マッピング プロバイダは、Callback オブジェクトに格納されている値、サブジェクト、およびリソースを用いて、リクエスト側のサブジェクトに付与されるセキュリティ ロールを計算し、該当するセキュリティ ロールを WebLogic Security フレームワークに渡します。
認可プロバイダのアクセス決定ではまた、ContextHandler を用いてリクエストに関するさまざまな情報を要求します。アクセス決定は、要求する情報のタイプを表す一連の Callback オブジェクトを作成します。その Callback オブジェクト群は、handle メソッドを通じて、配列として ContextHandler に渡されます。このプロセスは、手順 5 のロール マッピング プロバイダの場合と同じです。
isAccessAllowed() メソッドが呼び出され、要求されたアクセスを実行する権限がサブジェクトにあるかどうかが、ContextHandler、サブジェクト、WebLogic リソース、およびセキュリティ ロールに基づいて判定されます。各 isAccessAllowed() メソッドは、以下の 3 つの値のいずれかを返します。注意 : 裁決プロバイダの詳細については、「裁決プロバイダ」を参照してください。
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 認可プロバイダが含まれています。WebLogic 認可プロバイダは、このバージョンの WebLogic Server の認可機能をデフォルトで適用するものです。WebLogic 認可プロバイダは、特定のユーザが保護対象の WebLogic リソースへのアクセスを許可されているかどうかを判定するためのポリシーベースの認可エンジンを使用して、アクセス決定を返します。また、WebLogic 認可プロバイダは、システム内のセキュリティ ポリシーのデプロイメントとアンデプロイメントもサポートしています。自社の既存の認可メカニズムを使用する場合は、カスタム認可プロバイダを作成してそれを既存のメカニズムに結合できます。
セキュリティ レルムのすべての認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール マッピング、または資格マッピング用にカスタム セキュリティ プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションの SSPI を実装する必要があります。
WebLogic 認可プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム認可プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダの実行時クラスを作成します。
注意 : セキュリティ レルムでは、少なくとも 1 つの認可プロバイダが DeployableAuthorizationProvider SSPI を実装する必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
カスタム認可プロバイダの実行時クラスの作成例については、「例 : サンプル認可プロバイダの実行時クラスを作成する」を参照してください。
AuthorizationProvider SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
AuthenticationProvider SSPI と getAccessDecision メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
DeployableAuthorizationProviderV2 SSPI を実装するには、「「Provider」SSPI の目的について」および「AuthorizationProvider SSPI を実装する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
public void deleteApplicationPolicies(ApplicationInfo application) throws ResourceRemovalException
deleteApplicationPolicies メソッドは、アプリケーションのすべてのポリシーを削除します。deleteApplicationPolicies メソッドは、管理サーバでのみ呼び出されます。
public void deleteApplicationPolicies(DeployPolicyHandle handle, Resource resource) throws ResourceCreationException
deployExcludedPolicy メソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。
public void deployPolicy(DeployPolicyHandle handle, Resource resource, String[] roleNames) throws ResourceCreationException
deployPolicy メソッドは、セキュリティ ポリシーの適用対象となる WebLogic リソースとセキュリティ ポリシー内に記載されるセキュリティ ロール名を基に、デプロイ済みの Web アプリケーションや EJB に代わってセキュリティ ポリシーを作成します。
public void deployUncheckedPolicy(DeployPolicyHandle handle, Resource resource) throws ResourceCreationException
deployUncheckedPolicy メソッドは、アクセスを常に許可するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。
public void endDeployPolicies(DeployPolicyHandle handle) throws ResourceCreationException
deployExcludedPolicy メソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。
public deployPolicyHandle startDeployPolicies(ApplicationInfo application) throws DeployHandleCreationException
startDeployPolicies メソッドは、アプリケーションのポリシー デプロイメントの開始をマークし、アプリケーションが対象指定されている WebLogic Server ドメイン内のすべてのサーバで呼び出されます。
DeployableAuthorizationProviderV2 SSPI と deployPolicy および undeployPolicy メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
ApplicationInfo インタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ プロバイダに渡します。このデータを使用すると、アプリケーションをユニークに識別できます。
セキュリティ フレームワークは、ユーザの利便を図るために ApplicationInfo インタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。
DeployableAuthorizationProviderV2 インタフェースと DeployableRoleProviderV2 インタフェースは ApplicationInfo を使用します。たとえば、DeployableAuthorizationProviderV2 メソッドの実装を例に挙げます。WebLogic Security フレームワークは、DeployableAuthorizationProviderV2 startDeployPolicies メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。ApplicationInfo データは、アプリケーションのデプロイ時に Administration Console で提供される情報を基に決められます。
startDeployPolicies メソッドは、他の DeployableAuthorizationProviderV2 メソッドでこの後使用できる DeployPolicyHandle を返します。
ApplicationInfo インタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentType クラスの定義に従って、APPLICATION、CONTROL_RESOURCE、EJB、または WEBAPP のいずれかです。
public DeployPolicyHandle startDeployPolicies(ApplicationInfo appInfo)
throws DeployHandleCreationException
String appId = appInfo.getApplicationIdentifier();
ComponentType compType = appInfo.getComponentType();
String compName = appInfo.getComponentName();
WebLogic Security フレームワークは、DeployableAuthorizationProviderV2 deleteApplicationPolicies メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。deleteApplicationPolicies メソッドは、アプリケーションのすべてのポリシーを削除し、アプリケーションが削除された時点で WebLogic Server ドメイン内の管理サーバでのみ呼び出されます。
AccessDecision SSPI を実装する際には、以下のメソッドの実装を提供する必要があります。
Resource resource, ContextHandler handler, Direction direction) throws InvalidPrincipalException
isAccessAllowed メソッドは、サブジェクトに格納されている情報を利用して、リクエスト側に保護対象リソースへのアクセスを許可すべきかどうかを決定します。isAccessAllowed メソッドはリクエストの前または後に呼び出すことができ、PERMIT、DENY、または ABSTAIN のいずれかの値を返します。複数のアクセス決定がコンフィグレーションされていて、それらが相反する値を返す場合、最終結果を決定するには裁決プロバイダが必要になります。詳細については、「裁決プロバイダ」を参照してください。
AccessDecision SSPI と isAccessAllowed および isProtectedResource メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、認可プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 6-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするために、カスタム認可プロバイダが使用できるコードを示しています。このコードは、isAccessAllowed メソッドと isProtectedResource メソッドの双方に属しています。
コード リスト 6-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;
}
コード リスト 6-2 は、サンプル認可プロバイダの実行時クラスである SampleAuthorizationProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、および shutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的について」を参照)AuthorizationProvider SSPI から継承した getAccessDecision メソッド (「AuthorizationProvider SSPI を実装する」を参照)DeployableAuthorizationProviderV2 SSPI の deleteApplicationPolicies、deployExcludedPolicy、deployPolicy、deployUncheckedPolicy、endDeployPolicies、starteployPolicies、および undeployAllPolicies メソッド (「DeployableAuthorizationProviderV2 SSPI を実装する」を参照)AccessDecision SSPI の isAccessAllowed および isProtectedResource メソッド (「AccessDecision SSPI を実装する」を参照)注意 : コード リスト 6-2 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 6-2 SimpleSampleAuthorizationProviderImpl.java
package examples.security.providers.authorization.simple;
import java.security.Principal;
import java.util.Date;
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.SubjectUtils;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AccessDecision;
import weblogic.security.spi.ApplicationInfo;
import weblogic.security.spi.ApplicationInfo.ComponentType;
import weblogic.security.spi.DeployableAuthorizationProviderV2;
import weblogic.security.spi.DeployPolicyHandle;
import weblogic.security.spi.Direction;
import weblogic.security.spi.InvalidPrincipalException;
import weblogic.security.spi.Resource;
import weblogic.security.spi.Result;
import weblogic.security.spi.SecurityServices;
import weblogic.security.spi.VersionableApplicationProvider;
public final class SimpleSampleAuthorizationProviderImpl implements DeployableAuthorizationProviderV2, AccessDecision, VersionableApplicationProvider
{
private static String[] NO_ACCESS = new String[0];
private static String[] ALL_ACCESS = new String[] {WLSPrincipals.getEveryoneGroupname()};
private String description;
private SimpleSampleAuthorizerDatabase database;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.initialize");
SimpleSampleAuthorizerMBean myMBean = (SimpleSampleAuthorizerMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
database = new SimpleSampleAuthorizerDatabase(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)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.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)) {
Result result = isAccessAllowed(res, subject, roles);
System.out.println("\tallowed\t= " + result);
return result;
}
}
Result result = Result.ABSTAIN;
System.out.println("\tallowed\t= " + result);
return result;
}
public boolean isProtectedResource(Subject subject, Resource resource) throws
InvalidPrincipalException
{
System.out.println("SimpleSampleAuthorizationProviderImpl.
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)) {
System.out.println("\tprotected\t= true");
return true;
}
}
System.out.println("\tprotected\t= false");
return false;
}
public DeployPolicyHandle startDeployPolicies(ApplicationInfo application)
{
String appId = application.getApplicationIdentifier();
String compName = application.getComponentName();
ComponentType compType = application.getComponentType();
DeployPolicyHandle handle = new SampleDeployPolicyHandle(appId,compName,compType);
database.removePoliciesForComponent(appId, compName, compType);
return handle;
public void deployPolicy(DeployPolicyHandle handle,
Resource resource, String[] roleNamesAllowed)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
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 deployUncheckedPolicy(DeployPolicyHandle handle, Resource resource)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployUncheckedPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
System.out.println("\tresource\t= " + resource);
database.setPolicy(resource, ALL_ACCESS);
}
public void deployExcludedPolicy(DeployPolicyHandle handle, Resource resource)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployExcludedPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
System.out.println("\tresource\t= " + resource);
database.setPolicy(resource, NO_ACCESS);
}
public void endDeployPolicies(DeployPolicyHandle handle)
{
database.savePolicies();
}
public void undeployAllPolicies(DeployPolicyHandle handle)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.undeployAllPolicies");
SampleDeployPolicyHandle myHandle = (SampleDeployPolicyHandle)handle;
System.out.println("\thandle\t= " + myHandle.toString());
// ポリシーを削除する
database.removePoliciesForComponent(myHandle.getApplication(),
myHandle.getComponent(),
myHandle.getComponentType());
}
public void deleteApplicationPolicies(ApplicationInfo application)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationPolicies");
String appId = application.getApplicationIdentifier();
System.out.println("\tapplication identifier\t= " + appId);
// アプリケーションのポリシーを削除する
database.removePoliciesForApplication(appId);
}
private boolean rolesOrSubjectContains(Map roles, Subject subject, String roleOrPrincipalWant)
{
// 最初に、ロール名の一致かどうかを確認する
if (roles.containsKey(roleOrPrincipalWant)) {
return true;
}
// 2 番目に、グループ名の一致かどうかを確認する
if (SubjectUtils.isUserInGroup(subject, roleOrPrincipalWant)) {
return true;
}
// 3 番目に、ユーザ名の一致かどうかを確認する
if (roleOrPrincipalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// 一致せず
return false;
}
private Result isAccessAllowed(Resource resource, Subject subject, Map roles)
{
// このリソースへのアクセスが許可されているデータベースでプリンシパルとロールを繰り返しループする
for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();) {
String roleOrPrincipalAllowed = (String)e.nextElement();
if (rolesOrSubjectContains(roles, subject, roleOrPrincipalAllowed)) {
return Result.PERMIT;
}
}
// リソースが明示的に言及され、アクセスを不許可
return Result.DENY;
}
public void createApplicationVersion(String appId, String sourceAppId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));
// 既存のアプリケーションを指定したときに新しいポリシーを作成する
if (sourceAppId != null) {
database.clonePoliciesForApplication(sourceAppId,appId);
}
}
public void deleteApplicationVersion(String appId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
// アプリケーションのポリシーを削除する
database.removePoliciesForApplication(appId);
}
public void deleteApplication(String appName)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);
// アプリケーションのポリシーを削除する
database.removePoliciesForApplication(appName);
}
class SampleDeployPolicyHandle implements DeployPolicyHandle
{
Date date;
String application;
String component;
ComponentType componentType;
SampleDeployPolicyHandle(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() +"]";
}
}
}
カスタム セキュリティ プロバイダの 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 に任意 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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり認可プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
カスタム認可プロバイダの 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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり認可プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
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 で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : このバージョンの WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用し、複数の MDF を格納するディレクトリを指定することもできます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり認可プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。
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 を使用して 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 Server は、web.xml および weblogic.xml デプロイメント記述子ファイルからセキュリティ ポリシー情報を読み込みます (web.xml ファイルと weblogic.xml ファイルの例については、コード リスト 6-3 とコード リスト 6-4 を参照)。この情報は、認可プロバイダのセキュリティ プロバイダ データベースにコピーされます。
<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 weblogic.xml ファイルのサンプル
<weblogic-web-app>
<security-role-assignment>
<role-name>developers</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
カスタム認可プロバイダの開発の一環として DeployableAuthorizationProviderV2 SSPI を実装し、カスタム認可プロバイダでデプロイ可能なセキュリティ ポリシーをサポートしたい場合、カスタム認可プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ポリシー デプロイメントを有効化] チェック ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、認可プロバイダは「オフ」と見なされます。このため、複数の認可プロバイダがコンフィグレーションされている場合、[ポリシー デプロイメントを有効化] チェック ボックスを使用して、セキュリティ ポリシーのデプロイメントに使用する認可プロバイダを指定できます。
WebLogic Server Administration Console を使用してカスタム認可プロバイダをコンフィグレーションすると、必要な認可サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ポリシーを管理する方法を管理者にも提供する必要があります。たとえば WebLogic 認可プロバイダには、ポリシー エディタ ページが管理者向けに用意されており、さまざまな WebLogic リソースのセキュリティ ポリシーを追加、変更、または削除することができます。
カスタム認可プロバイダを開発している場合、管理者はポリシー エディタ ページも認可サービスへのアクセスも利用できません。したがって、セキュリティ ポリシーを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム認可プロバイダのデータベースのセキュリティ ポリシー データ (つまり式) を読み書きできなければなりません。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム認可プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
|
|
|