| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
戻る |
次へ |
ロール マッピングとは、実行時にプリンシパル (ユーザまたはグループ) をセキュリティ ロールに動的に割り当てるプロセスのことです。WebLogic Server では、ロール マッピング プロバイダは、WebLogic リソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ ロールを調べます。通常、この操作では WebLogic リソースへのアクセスを取得する必要があるので、ロール マッピング プロバイダは認可プロバイダと共に使用するのが一般的です。
以下の節では、ロール マッピング プロバイダの概念と機能、およびカスタム ロール マッピング プロバイダの開発手順について説明します。
ロール マッピング プロバイダを開発する前に、以下の概念を理解しておく必要があります。
セキュリティ ロールは、WebLogic リソースへの同じアクセス パーミッションを持つユーザまたはグループの集合です。グループと同様、セキュリティ ロールを使用すると、複数のユーザによる WebLogic リソースへのアクセスを一度に制御できます。ただし、セキュリティ ロールは WebLogic Server ドメインの特定のリソースを対象としており (WebLogic Server ドメイン全体を対象とするグループとは異なる)、動的に定義することが可能です。「動的セキュリティ ロール計算」を参照してください。
|
注意 : セキュリティ ロールの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。WebLogic リソースの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「セキュリティ プロバイダと WebLogic リソースおよび「ポリシーで保護できるリソースのタイプ」を参照してください。 |
weblogic.security.service パッケージの SecurityRole インタフェースは、セキュリティ ロールの抽象的な記法を表すために用いられます (詳細については、WebLogic Server API リファレンス Javadoc の SecurityRole インタフェースを参照してくさい。)
プリンシパルをセキュリティ ロールにマップすると、そのプリンシパルがそのセキュリティ ロールに「割り当てられている」かぎり、そのプリンシパルには定義されたアクセス パーミッションが付与されます。たとえば、アプリケーションで AppAdmin というセキュリティ ロールを定義し、これによってそのアプリケーションのリソースのごく一部に対する書き込みアクセスが提供されるものとします。この場合、AppAdmin セキュリティ ロールに割り当てられたプリンシパルはすべて、それらのリソースに対して書き込みアクセス権を持つことになります。詳細については、動的セキュリティ ロール計算と『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
なお、多数のプリンシパルを単一のセキュリティ ロールにマップすることができます。プリンシパルの詳細については、「ユーザ/グループ、プリンシパル、サブジェクト」を参照してください。
セキュリティ ロールの指定は、Java EE デプロイメント記述子ファイルか WebLogic Server Administration Console、あるいはその両方で行われます。詳細については、「ロール マッピング プロバイダとデプロイメント記述子の管理」を参照してください。
セキュリティ ロールは、宣言的なもの (すなわち、Java Enterprise Edition におけるロール) とすることも、要求のコンテキストに基づいて動的に計算することもできます。
動的セキュリティ ロール計算とは、このようにプリンシパル (ユーザまたはグループ) を実行時にセキュリティ ロールにレイト バインドすることを意味する用語です。こうしたレイト バインディングは、プリンシパル対セキュリティ ロールの関連付けが静的に定義されるか動的に計算されるかによらず、保護対象 WebLogic リソースについての認可判定の直前に行われます。バインディングが呼び出しシーケンス内で行われるため、あらゆるプリンシパル対セキュリティ ロール計算の結果は、要求に対して下される認可判定の一環として、認証用 ID 情報として解釈することができます。
こうしたセキュリティ ロールの動的計算には非常に重要な利点があります。つまり、ビジネス ルールに基づいてユーザまたはグループをセキュリティ ロールに関連付けることができるのです。たとえば、本来の管理者が長期の出張で不在の間のみ、ユーザに Manager セキュリティ ロールを割り当てることができます。このセキュリティ ロールを動的に計算することで、そうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要はなくなります。さらに、本来の管理者が戻ってきたときに、その特別に付与した特権を忘れずに取り消す必要もありません。なお、ユーザを一時的に Managers グループに追加した場合には、その必要があるでしょう。
|
注意 : 通常は WebLogic Server Administration Console で利用できるロール条件を使用して、ユーザまたはグループにセキュリティ ロールを付与します (このリリースの WebLogic Server では、カスタム ロール条件は記述できません)。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。 |
計算で得られたセキュリティ ロールは、対象 (利用可能であれば) の ID 情報や要求のパラメータ値など、要求のコンテキストを構成するさまざまな情報にアクセスすることができます。こうしたコンテキスト情報は通常、WebLogic Security フレームワークで評価される式に含まれるパラメータの値として使用されます。この機能は、デプロイメント記述子または WebLogic Server Administration Console を通じて静的に定義されたセキュリティ ロールの計算も担当します。
|
注意 : 認証済みユーザに対するセキュリティ ロールの計算は、Java EE 仕様で定義されているロールベース アクセス制御 (RBAC) によるセキュリティ機能を拡張したものです。動的なセキュリティ ロール計算を作成するには、WebLogic Server Administration Console でロール文を定義します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。 |
WebLogic Security フレームワークは、認可判定の一環として、セキュリティ レルム用にコンフィグレーションされている各ロール マッピング プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。
ロール マッピング プロバイダによる動的セキュリティ ロール関連計算の結果、一連のセキュリティ ロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのセキュリティ ロールを用いて、保護対象 WebLogic リソース、リソース コンテナ、およびアプリケーション コードについての認可判定が行われます。たとえば、エンタープライズ JavaBean (EJB) であれば、アクセスを許可するかどうかを決めるビジネス ポリシーを知らなくても、Java EE の isCallerInRole() メソッドを用いてデータベース内のレコードからフィールドを取得することができます。
動的セキュリティ ロール計算を作成する場合のロール マッピング プロバイダと WebLogic Security フレームワークとの対話を図 9-1 に示し、続いてそれについて説明します。
一般に、ロール マッピングは以下のように実行されます。
ユーザまたはシステム プロセスが WebLogic リソースを要求し、特定の操作を実行しようとします。
要求された WebLogic リソースのタイプを処理するリソース コンテナが要求を受け取ります。たとえば EJB コンテナは EJB リソースに対する要求を受け取ります。
リソース コンテナは、要求のコンテキストに関連付けられている情報を取得するためにロール マッピング プロバイダで使用する場合のある ContextHandler オブジェクトを作成します。
リソース コンテナは、サブジェクト (ユーザおよびグループ プリンシパルを含む)、WebLogic リソースの識別子、そして場合によっては追加入力を提供する ContextHandler オブジェクトを渡して WebLogic Security フレームワークを呼び出します。
|
注意 : サブジェクトの詳細については、「ユーザ/グループ、プリンシパル、サブジェクト」を参照してください。また、リソース識別子の詳細については、「WebLogic リソース識別子」を参照してください。 |
WebLogic Security フレームワークは、適用するセキュリティ ロールのリストを取得するために、コンフィグレーション済みの各ロール マッピング プロバイダを呼び出します。この仕組みは次のとおりです。
ロール マッピング プロバイダは ContextHandler を用いて、要求に関するさまざまな情報を要求します。また、ロール マッピング プロバイダは、要求する情報のタイプを表す一連の Callback オブジェクトを作成します。その Callback オブジェクト群は、handle メソッドを通じて、配列として ContextHandler に渡されます。
ロール マッピング プロバイダは、必要なコンテキスト情報を取得するのに、ContextHandler を複数回呼び出す場合があります。ロール マッピング プロバイダで ContextHandler が呼び出される回数はその実装によって異なります。
コンテキスト情報と、セキュリティ ポリシー、サブジェクト、および WebLogic リソースを格納する関連セキュリティ プロバイダ データベースを使用することで、ロール マッピング プロバイダは、サブジェクト内のユーザ プリンシパルとグループ プリンシパルで表される要求側に特定のセキュリティ ロールの資格があるかどうかを決定します。
セキュリティ ポリシーは、指定されたセキュリティ ロールを付与すべきかどうかを判定する際に評価される一連の式すなわちルールとして表されます。これらのルールを使用する際に、ロール マッピング プロバイダは、取得したコンテキスト情報の値を式のパラメータに代入しなければならない場合があります。さらに、ユーザ プリンシパルまたはグループ プリンシパルの ID 情報が、式のパラメータ値として必要になることもあります。
|
注意 : セキュリティ ポリシーのルールは、WebLogic Server Administration Console と Java EE デプロイメント記述子で設定します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「セキュリティ ポリシー」を参照してください。 |
要求側に特定のセキュリティ ロールの資格があるとセキュリティ ポリシーに指定されている場合には、そのセキュリティ ロールがサブジェクトに適用されるセキュリティ ロールのリストに追加されます。
このプロセスは、WebLogic リソースまたはリソース コンテナに適用されるセキュリティ ポリシーがすべて評価されるまで続行されます。
セキュリティ ロールのリストは WebLogic Security フレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。
WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic ロール マッピング プロバイダが含まれています。WebLogic ロール マッピング プロバイダは、デフォルト ユーザと WebLogic リソースのそれぞれについて、保護されている特定のリソースに関する特定のユーザ (サブジェクト) の動的セキュリティ ロールを計算します。また、WebLogic ロール マッピング プロバイダは、システム内のセキュリティ ロールのデプロイメントとアンデプロイメントをサポートしています。WebLogic ロール マッピング プロバイダは、WebLogic 認可プロバイダと同じセキュリティ ポリシー エンジンを使用します。自社の既存のロール マッピング メカニズムを使用する場合は、カスタム ロール マッピング プロバイダを作成してそれを既存のメカニズムに結合できます。
セキュリティ レルムのすべての認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール マッピング、または資格マッピング用にカスタム セキュリティ プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションの SSPI を実装する必要があります。
WebLogic ロール マッピング プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム ロール マッピング プロバイダを開発することができます。
適切な SSPI を使用して実行時クラスの作成または必要に応じてバルク認可プロバイダを実装
必要に応じてロール コンシューマ SSPIを実装
Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションする
実行時クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ロール マッピング プロバイダの実行時クラスを作成します。
|
注意 : セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダが DeployableRoleProviderV2 SSPI を実装する必要があり、実装していない場合、Web アプリケーションや EJB をデプロイできなくなります。 |
カスタム ロール マッピング プロバイダの実行時クラスの作成例については、「例 : サンプル ロール マッピング プロバイダの実行時クラスの作成」を参照してください。
RoleProvider SSPI を実装するには、「Provider」SSPI の目的についてで説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getRoleMapper
public RoleMapper getRoleMapper()
getRoleMapper メソッドは、RoleMapper SSPI の実装を取得します。MyRoleProviderImpl.java という 1 つの実行時クラスの場合、getRoleMapper メソッドの実装は次のようになります。
return this;
実行時クラスが 2 つの場合、getRoleMapper メソッドの実装は次のようになります。
return new MyRoleMapperImpl;
これは、RoleProvider SSPI を実装する実行時クラスが、RoleMapper SSPI を実装するクラスを取得する場合のファクトリとして使用されるためです。
RoleProvider SSPI と getRoleMapper メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
|
注意 : DeployableRoleProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。DeployableRoleProviderV2 SSPI を代わりに使用してください。 |
DeployableRoleProviderV2 SSPI を実装するには、「Provider」SSPI の目的についておよび RoleProvider SSPI の実装で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
deleteApplicationRoles
void deleteApplicationRoles(ApplicationInfo application)
アプリケーションのすべてのロールを削除し、アプリケーションが削除された時点で WLS ドメイン内の管理サーバでのみ呼び出されます。
deployRole
void deployRole(DeployRoleHandle handle, Resource resource, String roleName, String[] userAndGroupNames)
デプロイされた Web アプリケーションまたは EJB に代わってロールを作成します。ロールがすでに存在する場合は削除され、このロールによって置き換えられます。
endDeployRoles
void endDeployRoles(DeployRoleHandle handle)
アプリケーションのロール デプロイメントの終了をマークします。
startDeployRoles
DeployRoleHandle startDeployRoles(ApplicationInfo application)
アプリケーションのロール デプロイメントの開始をマークし、アプリケーションが対象指定されている WebLogic Server ドメイン内のすべてのサーバで呼び出されます。
undeployAllRoles
void undeployAllRoles(DeployRoleHandle handle)
デプロイされていない Web アプリケーションまたは EJB に代わって、ロールのセットを削除します。
DeployableRoleProvider SSPI、deployRole メソッド、undeployRole メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
ApplicationInfo インタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ プロバイダに渡します。このデータを使用すると、アプリケーションをユニークに識別できます。
WebLogic Security フレームワークは、ユーザの利便を図るために 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 を実装するには、以下のメソッドの実装を提供する必要があります。
getRoles
public Map getRoles(Subject subject, Resource resource, ContextHandler handler)
getRoles メソッドは、場合により ContextHandler に指定された任意情報を使用して、特定の WebLogic リソースに関して特定のサブジェクトに関連付けられているセキュリティ ロールを返します。ContextHandler の詳細については、「ContextHandler と WebLogic リソース」を参照してください。
RoleMapper SSPI と getRoles メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、ロール マッピング プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。
コード リスト 9-1 では、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするため、カスタム資格マッピング プロバイダで使用できるコードを示します。このコードは、getRoles メソッドに属しています。
コード リスト 9-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 インタフェースを実装するには、以下のメソッドの実装を提供する必要があります。
equals
public boolean equals(Object another)
equals メソッドは、渡されたセキュリティ ロールが、このインタフェースの実装によって表されるセキュリティ ロールに一致する場合に TRUE を返し、それ以外の場合は FALSE を返します。
toString
public String toString()
toString メソッドは、このセキュリティ ロールを String として返します。
hashCode
public int hashCode()
hashCode メソッドは、このセキュリティ ロールのハッシュコードを整数で返します。
getName
public String getName()
getName メソッドは、このセキュリティ ロールの名前を String として返します。
getDescription
public String getDescription()
getDescription メソッドは、このセキュリティ ロールの説明を String として返します。説明は、このセキュリティ ロールの目的を記述したものです。
コード リスト 9-2 は、サンプル ロール マッピング プロバイダの実行時クラスである SimpleSampleRoleMapperProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、および shutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的について」を参照)。
getRoleMapper という RoleProvider SSPI から継承したメソッド (「RoleProvider SSPI の実装」を参照)。
deleteApplicationRoles、deployRole、endDeployRoles、startDeployRoles、および undeployAllRoles という DeployableRoleProviderV2 SSPI の 5 つのメソッド (「DeployableRoleProviderV2 SSPI の実装」を参照)。
getRoles という RoleMapper SSPI のメソッド (「RoleProvider SSPI の実装」を参照)。
コード リスト 9-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() +"]";
}
}
}
コード リスト 9-3 は、SimpleSampleRoleMapperProviderImpl.java 実行時クラスとともに使用する SecurityRole の実装例を示しています。
コード リスト 9-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 "";
}
}
WebLogic Server には WebService アノテーション用のロール コンシューマが実装されています。このリリースの WebLogic Server には、ロール マッピング プロバイダがロール コレクションを取得するために使用できる SSPI があります。
RoleConsumer SSPI は省略可能です。ロール コレクションを消費するためには、この SSPI を実装するロール マッピング プロバイダのみが呼び出されます。
この SSPI では、初期状態のロール コレクションの配信と、更新後のロール コレクションの配信の両方がサポートされます。
ロール コレクションの消費においては、RoleConsumer SSPI をサポートするすべてのロール マッピング プロバイダが呼び出されます。各ロール マッピング プロバイダは、特定のロール セットのロール コレクションを取得するかしないかを選択できます。プロバイダでロールが永続化される場合、ロールを取得する必要があるのは一度だけです。一方、プロバイダでロールがメモリに保持される場合、ロール コレクションを再び取得することも可能です。
用意されている WebLogic Server ロール マッピング プロバイダでは、ロールは LDAP 内に永続化されます。
ロール マッピング プロバイダをカスタマイズしてロール コレクションの配信をサポートするには、以下の 3 つのインタフェースを実装する必要があります。
weblogic.security.spi.RoleConsumerFactory
weblogic.security.spi.RoleConsumer
weblogic.security.spi.RoleCollectionHandler
これらのインタフェースについては、これ以降の節で説明します。
ロール マッピング プロバイダには、RoleConsumer のインスタンスを WebLogic Security フレームワークで使用できるように、RoleConsumerFactory インタフェースが実装されています。WebLogic Security フレームワークでは RoleConsumerFactory の実装を呼び出して、プロバイダのロール コンシューマの実装を取得します。
RoleConsumerFactory SSPI にはメソッドが 1 つあり、このメソッドは RoleConsumer SSPI インタフェースの実装を返します。
public interface RoleConsumerFactory
{
/**
* RoleConsumer セキュリティ サービス プロバイダ インタフェース (SSPI)
* の実装を取得する。<P>
*
* @return a RoleConsumer SSPI の実装。<P>
*/
public RoleConsumer getRoleConsumer();
}
RoleConsumer SSPI は、ロール コレクションを消費するためのロール コレクション ハンドラを返します。これには getRoleCollectionHandler() というメソッドが 1 つあり、このメソッドは引数に RoleCollectionInfo の実装を取って、RoleCollectionHandler インタフェースの実装を返します。
public interface RoleConsumer
{
/**
* ロール コレクションを消費するためのロール ハンドラを取得する。
*
* @param info。ロール コレクションの RoleCollectionInfo
*
* @return a RoleCollectionHandler または NULL。NULL はロール コレクションが
* 不要であることを示す。
*
* @exception ConsumptionException ハンドラの取得中にエラーが発生して
* ロール コレクションを消費できない場合に送出。
*/
public RoleCollectionHandler getRoleCollectionHandler(
RoleCollectionInfo info)
throws ConsumptionException;
}
WebLogic Security フレームワークでは getRoleCollectionHandler() メソッドを呼び出して、ロール コレクションに関するデータを RoleCollectionInfo インタフェースの実装としてセキュリティ プロバイダに渡します (このインタフェースはあらかじめ実装されているので、ユーザが実装する必要はありません)。
RoleCollectionInfo の getName()、getVersion()、getTimestamp()、および getResourceTypes() メソッドを使用して、このロール コレクションに関する情報を検索します。検索後には RoleCollectionHandler を返すか、ロール コレクションが不要であることを示す NULL を返します。
public interface RoleCollectionInfo
{
/**
* コレクションの名前を取得する。
*/
public String getName();
/**
* ロールの実行時バージョンを取得する。
*/
public String getVersion();
/**
* ロールのタイムスタンプを取得する。
*/
public String getTimestamp();
/**
* ロール コレクションで使用されるリソース タイプを取得する。
*/
public Resource[] getResouceTypes();
}
RoleConsumer.getRoleCollectionHandler() メソッドは RoleCollectionHandler インタフェースの実装を返します。RoleCollectionHandler には setRole() と done() という 2 つのメソッドがあります。setRole() メソッドは、リソース、ロール名、およびその特定のリソース用のロールに割り当てる一連のユーザ名とグループ名の配列を取ります。
done() メソッドはロール コレクションの完了を示します。
public interface RoleCollectionHandler
{
/**
* 指定したリソース用のロールを設定する。
*/
public void setRole(Resource resource, String roleName, String[] userAndGroupNames)
throws ConsumptionException;
/**
* ロール コレクションの完了を示す。
*/
public void done()
throws ConsumptionException;
}
更新後のロール コレクションの配信をサポートするには、RoleConsumer SSPI をサポートするすべてのロール マッピング プロバイダで、RoleConsumer.getRoleCollectionHandler() メソッドに渡された RoleCollectionInfo の内容を調べて、ロール コレクションが変更されているかどうかを判断する必要があります。各プロバイダでは、初期状態のロール コレクションと SSPI の外部から受け取ったカスタマイズ後のロールとの衝突を解決する方法を (できればコンフィグレーションによって) 決定しておくことが必要です。
WebLogic Server で提供されているロール マッピング プロバイダでは、カスタマイズ後のロールが更新後のロール コレクションで置き換えられません。初期状態のロール コレクションのロールはすべて削除され、カスタマイズ後のロールと更新後のロール コレクションのみが有効になります。ロール コレクションの情報に異なるタイムスタンプやバージョンがある場合、更新後のロール コレクションとして扱われます。コレクションの名前は永続キーとして使用されます。
このリリースの WebLogic Server では、weblogic.management.security.authorization.PolicyStoreMBean という新しい MBean がサポートされています。この MBean は、管理者が生成した XACML ポリシーおよびポリシー セットの標準的な管理操作 (追加、削除、取得、リスト表示、変更、読み込み) に使用できます。認可プロバイダ MBean やロール マッピング プロバイダ MBean には、必要に応じてこの MBean インタフェースを実装できます。
セキュリティ管理者は、PolicyStoreMBean のメソッドを使用して、サーバ内のポリシーを XACML ドキュメントとして管理できます。たとえば、デフォルトの XACML プロバイダを使用するドメインを作成および管理したり、作成済みの XACML ドキュメントを管理したりできます。これらの XACML ポリシーは、WebLogic Server では WLST を使用して管理できます。
WebLogic Server にはこの MBean の実装が含まれており、付属の XACML プロバイダで使用できます。また、この MBean の独自の実装を記述して、カスタムの認可プロバイダやロール マッピング プロバイダで使用することも可能です。WebLogic Server に用意されている XACML プロバイダでは、XACML 2.0 のコア仕様 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf) に記載されている XACML の必須機能がサポートされています。Oracle 固有の使用方法については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
ポリシーは XACML 2.0 のポリシーまたは PolicySet ドキュメントで表現されます。カスタム認可プロバイダでは、XACML 2.0 のコア仕様に記載されている標準の Policy または PolicySet ドキュメントを想定する必要があります。カスタム ロール マッピング プロバイダでは、Core and hierarchical role based access control (RBAC) profile of XACML v2.0 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf) に記載されているロール割り当てポリシーと整合性がある Policy または PolicySet ドキュメントを想定する必要があります。
具体的には、Target に以下を含める必要があります。
ActionAttributeDesignator (anyURI-equal で一致する、urn:oasis:names:tc:xacml:1.0:action:action-id という ID と、urn:oasis:names:tc:xacml:2.0:actions:enableRole という値の指定されているもの)。次に例を示します。
<Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:enableRole </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="true"/> </ActionMatch> </Action>
ResourceAttributeDesignator (string-equal で一致する、urn:oasis:names:tc:xacml:2.0:subject:role という ID と、割り当てられたロールの名前である値の指定されているもの)。次に例を示します。
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
XACML 2.0 のコア仕様 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf) および『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』で説明している Oracle 拡張が、提供されている XACML 認可プロバイダおよびロール マッピング プロバイダで使用する XACML ポリシー ファイルについての最も確実な情報です。
ただしサポートされている XACML ファイルの形式を開発プロセスの一環として確認する場合は、おそらく、Administration Console を使用して、XACML 認可またはロール マッピング プロバイダのデータベースからデータを XACML ファイルとしてエクスポートする方法が最も便利です。エクスポートした XACML ファイルをコピーして別の名前で保存し、任意のツールで確認します。
|
注意 : エクスポートしたファイルは読み取り専用としてください。変更した場合、そのファイルは WebLogic Server にインポートし直さないでください。エクスポートしたファイルを編集すると、WebLogic Server コンフィグレーションが使用できなくなる可能性があります。エクスポートしたファイルの編集はサポートされていません。 |
コード リスト 9-4 に、WLST を使用して XACML ファイルから PolicyStoreMBean のインスタンスに 1 つのポリシーを追加する例を示します。
この例ではこのスクリプトで使用するプロパティを、次の ant スクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。
<property name="xacml-docs-dir" value="${xacmldir}/xacml-docs"/>
<sysproperty key="file" value="${xacml-docs-dir}/policy-getSubject.xacml"/>
コード リスト 9-4 WLST を使用して PolicyStoreMBean にポリシーの追加
:
try:
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
fil = System.getProperty("file")
prov = System.getProperty("provider")
stat = System.getProperty("status")
def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
print("calling open()")
xacmlFile = open(fil,"r")
print("calling read()")
xacmlDoc = xacmlFile.read()
print("calling cmo.addPolicy")
if stat == "none":
cmo.addPolicy(xacmlDoc)
else:
cmo.addPolicy(xacmlDoc, stat)
print("Add error handling")
:
:
『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』の「MBean の移動と照会」で説明しているように、WLST が初めて WebLogic Server インスタンスに接続すると、変数 cmo (現在の管理オブジェクト) がすべてのコンフィグレーション管理オブジェクトのルート DomainMBean に初期化されます。MBean タイプに移動すると、SecurityConfigurationMBean の場合、cmo の値は SecurityConfigurationMBean を反映したものになります。MBean インスタンス、つまりこの場合には PolicyStoreMBean を実装する認可プロバイダ MBean (例では変数 prov で識別) に移動するときには、WLST によって cmo の値が現在の MBean インスタンスに変更されます。
この例では PolicyStoreMBean の addPolicy() メソッドを使用して、XACML ファイルからポリシー ストアに読み込まれるポリシーを追加しています。addPolicy() メソッドの 2 つのバリアント (ステータスを伴うものと伴わないもの) が示されています。
ステータスを指定しない addPolicy() メソッドを使用する場合、デフォルトで ACTIVE に設定されます。これは、ポリシーがその対象で適用されるどのような決定でも評価されることを示します。ステータスは明示的に ACTIVE、INACTIVE、または BYREFERENCE に設定できます。INACTIVE ステータスは、ポリシーが評価されずに格納されるだけであることを示します。BYREFERENCE ステータスは、評価されるポリシー セットによって参照された場合にだけ、ポリシーが評価されることを示します。
このタイプの WLST スクリプトは、次のような方法でコマンドラインから呼び出せます。
java -Dhost="localhost " -Dprotocol="t3" -Dauthuser="weblogic" -Dauthpwd="weblogic" -Dport="7001" -Ddomain="mydomain" -Drealm="myrealm" -Dprovider="Authorizers/XACMLAuthorizer" -Dfile="C:/XACML/xacml-docs/policy12.xml" -Dstatus="none" weblogic.WLST XACML/scripts/XACMLaddPolicy.py
コード リスト 9-5 に、WLST を使用して PolicySet を String として読み込む例を示します。
この例ではこのスクリプトで使用するプロパティを、次の ant スクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。
<sysproperty key="identifier" value="urn:sample:xacml:2.0:wlssecqa:resource:type@E@Fejb@G@M@Oapplication@ENoD DRolesOrPoliciesEar@M@Omodule@Eejb11inEarMiniAppBean.jar@M@Oejb@EMiniAppBean@ M@Omethod@EgetSubject@M@OmethodInterface@ERemote"/> <sysproperty key="version" value="1.0"/>
コード リスト 9-5 WLST を使用して PolicySet を String として読み込む
:
:
try:
print("start XACMLreadPolicySet.py")
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
prov = System.getProperty("provider")
id = System.getProperty("identifier")
vers = System.getProperty("version")
:
:
def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
polset = cmo.readPolicySetAsString(id, vers)
print("readPolicySetAsString() returned the following policy set: " + polset)
print"Add error handling."
:
:
XACML 2.0 のコア仕様 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf) で説明されているように、<PolicySet> 要素には <Policy> のセットまたは別の <PolicySet> 要素、およびそれらの評価結果を結合するための指定された手順が含まれます。詳細については、XACML 2.0 のコア仕様を参照してください。
WebLogic Server のこのリリースには、以下に示すバルク アクセス バージョンのロール マッピング プロバイダ SSPI インタフェースがあります。
BulkRoleProvider
BulkRoleMapper
バルク アクセス SSPI インタフェースを使用すると、ロール マッピング プロバイダにおいて、1 回の呼び出しで複数の判定要求を取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。
バルク バージョンでない SSPI インタフェースとバルク バージョンの SSPI インタフェースの使用方法には若干の違いがあります。たとえば、BulkRoleMapper.getRoles() メソッドはロールの Map を返します。これは、初めにリソース、続いて名前で索引付けされ (Map<Resource, Map<String, SecurityRole>>)、サブジェクトに許可されている指定のリソースに関連付けられたセキュリティ ロールを表します。
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ロール マッピング プロバイダの MBean タイプを作成します。
WebLogic Server 環境に MBean タイプのインストール
|
注意 : この節で説明する手順はすべて、Windows 環境での作業を想定しています。 |
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
サンプル ロール マッピング プロバイダの MDF をテキスト ファイルにコピーします。
|
注意 : サンプル ロール マッピング プロバイダの MDF は、SimpleSampleRoleMapper.xml という名前です。 |
MDF で <MBeanType> 要素と <MBeanAttribute> 要素の内容をカスタム ロール マッピング プロバイダに合わせて修正します。
カスタム属性および操作 (つまり、<MBeanAttribute> および <MBeanOperation> 要素) を MDF に追加します。
ファイルを保存します。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム ロール マッピング プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム ロール マッピング プロバイダの MDF にカスタム操作を含めない場合、次の手順に従います。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまりロール マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
カスタム ロール マッピング プロバイダの MDF にカスタム操作を含める場合、質問に答えながら手順を進めてください。
MBean タイプを作成するのは初めてですか。初めての場合は、次の手順に従ってください。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまりロール マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
MDF のすべてのカスタム操作に対して、メソッド スタブを使用してメソッドを実装します。
ファイルを保存します。
既存の MBean タイプの更新ですか。更新の場合は、次の手順に従ってください。
WebLogic MBeanMaker によって現在のメソッドの実装が上書きされないように、既存の MBean 実装ファイルを一時ディレクトリにコピーします。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまりロール マッピング プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
MDF を変更して元の MDF にはないカスタム操作を含めた場合、メソッド スタブを使用してメソッドを実装します。
完成した、つまりすべてのメソッドを実装した MBean 実装ファイルを保存します。
この MBean 実装ファイルを、WebLogic MBeanMaker が MBean タイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順 3 で filesdir として指定したものです。 (手順 3 の結果として WebLogic MBeanMaker で生成された MBean 実装ファイルがオーバーライドされます)。
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 を作成するには、次の手順に従います。
新しい DOS シェルを作成します。
次のコマンドを入力します。
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 つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム クラスと Oracle のカスタム クラスとの衝突を防ぐことができます。ネームスペースのデフォルトは vendor です。-targetNameSpace 引数を WebLogicMBeanMaker または関連する WLMBeanMaker ant タスクに渡すことで、このデフォルトを変更できます。既存の MJF を更新する場合は、単純に MJF を削除して再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御できます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false。このオプションは、-DMJF を使用しない場合には無視されます。 |
生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。
MBean タイプを WebLogic Server 環境にインストールするには、MJF を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 タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズガイド』の「Java セキュリティを使用しての WebLogic リソースの保護」を参照してください。 |
カスタム ロール マッピング プロバイダをコンフィグレーションすることによって (「Administration Console によるカスタム ロール マッピング プロバイダのコンフィグレーション」を参照)、MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。
カスタム ロール マッピング プロバイダをコンフィグレーションするということは、ロール マッピング サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム ロール マッピング プロバイダを追加するということです。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム ロール マッピング プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。
|
注意 : WebLogic Server Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションする手順は、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で説明されています。 |
エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーションの中には、Java EE の関連デプロイメント情報と WebLogic Server デプロイメント記述子を格納するものがあります。Web アプリケーションの場合、デプロイメント記述子ファイル (web.xml と weblogic.xml) には、セキュリティ ロールを含む Java EE セキュリティ モデルの実装情報が格納されます。この情報は、WebLogic Server Administration Console でロール マッピング プロバイダを初めてコンフィグレーションするときに格納するのが一般的です。
Java EE プラットフォームはデプロイメント記述子で Web アプリケーションおよび EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーションおよび EJB リソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも Administration Console のみを使用することもできます。また、状況によっては、この 2 つの方法を組み合わせることもできます。
選択した方法によって、セキュリティ モデルを適用する必要もあります。WebLogic では、個々のデプロイメントについて複数のセキュリティ モデルがサポートされ、使用する方法を組み込むレルム全体のコンフィグレーションについてはセキュリティ モデルがサポートされます。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「EJB および Web アプリケーション リソースの保護のオプション」を参照してください。
デプロイメント記述子を使用するようにコンフィグレーションすると、WebLogic Server により web.xml および weblogic.xml デプロイメント記述子ファイルからセキュリティ ロール情報が読み込まれます (web.xml ファイルと weblogic.xml ファイルの例については、コード リスト 9-6 とコード リスト 9-7を参照)。この情報は、ロール マッピング プロバイダのセキュリティ プロバイダ データベースにコピーされます。
コード リスト 9-6 web.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>
カスタム ロール マッピング プロバイダの開発の一環として DeployableRoleProviderV2 SSPI を実装し、デプロイ可能なセキュリティ ロールをサポートする場合、カスタム ロール マッピング プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ロール デプロイメントを有効化] ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、ロール マッピング プロバイダに対するデプロイメントは「オフ」と見なされます。このため、複数のロール マッピング プロバイダがコンフィグレーションされている場合、[ロール デプロイメントを有効化] ボックスを使用して、セキュリティ ロールのデプロイメントに使用するロール マッピング プロバイダを指定できます。
WebLogic Server Administration Console を使用してカスタム ロール マッピング プロバイダをコンフィグレーションすると、必要なロール マッピング サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ロールを管理する方法を管理者にも提供する必要があります。たとえば WebLogic ロール マッピング プロバイダには、ロール エディタ ページが管理者向けに用意されており、さまざまな WebLogic リソースのセキュリティ ロールを追加、変更、または削除することができます。
カスタム ロール マッピング プロバイダを開発すると、管理者はロール エディタ ページも右クリック メニューも利用できません。したがって、セキュリティ ロールを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム ロール マッピング プロバイダのデータベースのセキュリティ ロール データ (つまり式) を読み書きできなければなりません。
それには、以下の 2 通りの方法があります。
WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム ロール マッピング プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
WebLogic リソースの ID を特定します。ID がコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogic リソース識別子」を参照してください。
セキュリティ ロールを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム ロール マッピング プロバイダのデータベースの式を読み書きします。
WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。
この方法の場合、ツールでは以下のことを行う必要があります。
WebLogic リソースの ID を特定します。ID がコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogic リソース識別子」を参照してください。
セキュリティ ロールを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。
カスタム ロール マッピング プロバイダのデータベースの式を読み書きします。
『Oracle Fusion Middleware Oracle WebLogic ServerAdministration Console の拡張』に説明されているように、基本コンソール拡張を使用して Administration Console にリンクします。
