6 認可プロバイダ
認可とは、ユーザーのIDなどの情報に基づいて、ユーザーとWebLogicリソースとの対話を管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Serverでは、認可プロバイダはユーザーとWebLogicリソースとの対話を制限して、整合性、機密性、および可用性を確保します。
この章の内容は次のとおりです。
認可の概念
認可プロバイダを開発する前に、次の概念を理解しておく必要があります。
アクセス決定
認証プロバイダのLoginModuleと同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作をWebLogicリソースに対して実行する権限をサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答をPERMIT
、DENY
、またはABSTAIN
のいずれかで返します。
ノート:
「AccessDecision SSPIの実装」を参照してください。
Java Authorization Contract for Containersの使用
Java Authorization Contract for Containers (JACC)はJava EEの一部です。JACCは、EJBおよびサーブレットに対する権限ベースのセキュリティ・モデルです。JACCはJSR-115 (http://www.jcp.org/en/jsr/detail?id=115
)によって定義されます。
JACCは、WebLogic Serverドメイン内のEJBおよびサーブレット・コンテナに代替認可メカニズムを提供します。JACCが構成されている場合、WebLogicセキュリティ・フレームワークのアクセス決定、裁決、およびロール・マッピング機能は、EJBおよびサーブレットの認可判定には使用されません。
ノート:
WebLogicセキュリティ・フレームワークと一緒にJACCフレームワークを使用することはできません。WebLogic Serverで使用されるJACCクラスには、決定を下すためのポリシー・オブジェクトの実装は含まれません。かわりに、JACCクラスは、java.security.Policy(http://docs.oracle.com/javase/8/docs/api/java/security/Policy.html
)オブジェクトに依存します。
WebLogic Serverは、JSR-115に完全に準拠しているものの、WebLogic認証プロバイダほどには最適化されていないJACCプロバイダを実装します。Java JACCクラスは、アクセス決定を下す際に使用します。JSR-115はロール・マッピングに対処する方法を定義しないので、ロールとプリンシパルの間のマッピングにはWebLogic JACCクラスが使用されます。JACCプロバイダの開発の詳細は、https://javaee.github.io/javaee-spec/javadocs/javax/security/jacc/package-summary.html
を参照してください。
認可プロセス
図6-1に、認可プロセスにおける認可プロバイダ(および関連する裁決プロバイダとロール・マッピング・プロバイダ)とWebLogicセキュリティ・フレームワークとの対話を示します。その後、この図について説明します。
一般に、認可は以下のように実行されます。
-
ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとします。
-
リクエストされたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。
ノート:
リソース・コンテナは、「セキュリティ・プロバイダとWebLogicリソース」で説明されているWebLogicリソースのいずれかを処理するコンテナです
-
リソース・コンテナは、
ContextHandler
オブジェクトを作成します。このオブジェクトは、構成済のロール・マッピング・プロバイダおよび認可プロバイダのアクセス決定で、そのリクエストのコンテキストに関連付けられている情報を取得する際に使用できます。ノート:
「ContextHandlerとWebLogicリソース」、「アクセス決定」および「ロール・マッピング・プロバイダ」を参照してください。
リソース・コンテナは、サブジェクト、WebLogicリソース、そして場合によっては決定用の追加入力を提供する
ContextHandler
オブジェクトを渡してWebLogicセキュリティ・フレームワークを呼び出します。 -
WebLogicセキュリティ・フレームワークは、構成済のロール・マッピング・プロバイダを呼び出します。
-
ロール・マッピング・プロバイダは
ContextHandler
を用いて、リクエストに関する様々な情報をリクエストします。また、ロール・マッピング・プロバイダは、リクエストする情報のタイプを表す一連のCallback
オブジェクトを作成します。そのCallback
オブジェクト群は、handle
メソッドを通じて、配列としてContextHandler
に渡されます。ロール・マッピング・プロバイダは、
Callback
オブジェクトに格納されている値、サブジェクト、およびリソースを用いて、リクエスト側のサブジェクトに付与されるセキュリティ・ロールを計算し、該当するセキュリティ・ロールをWebLogicセキュリティ・フレームワークに返します。 -
WebLogicセキュリティ・フレームワークは、リクエストされたアクションをWebLogicリソースに対して実行する資格がサブジェクトにあるかどうかに関し、実際の判定を構成済の認可プロバイダに委託します。
認可プロバイダのアクセス決定ではまた、
ContextHandler
を用いてリクエストに関する様々な情報をリクエストします。アクセス決定は、リクエストする情報のタイプを表す一連のCallback
オブジェクトを作成します。そのCallback
オブジェクト群は、handle
メソッドを通じて、配列としてContextHandler
に渡されます。(このプロセスは、ステップ5のロール・マッピング・プロバイダの場合と同じです。) -
構成済の各認可プロバイダのアクセス決定の
isAccessAllowed
メソッドが呼び出され、リクエストされたアクセスを実行する権限がサブジェクトにあるかどうかが、ContextHandler
、サブジェクト、WebLogicリソース、およびセキュリティ・ロールに基づいて判定されます。各isAccessAllowed
メソッドは、以下の3つの値のいずれかを返します。-
PERMIT
- リクエストされたアクセスが許可されることを示します。 -
DENY
- リクエストされたアクセスが明示的に拒否されることを示します。 -
ABSTAIN
- 明示的な判定をアクセス決定が下せなかったことを示します。
このプロセスは、すべてのアクセス決定が使用されるまで続きます。
-
-
WebLogicセキュリティ・フレームワークは、構成済の認可プロバイダのアクセス決定から返された判定結果に食い違いがあった場合、その調停を裁決プロバイダに委託します。裁決プロバイダでは、認可判定の最終結果を決定します。
ノート:
「裁決プロバイダ」を参照してください。
-
裁決プロバイダは
TRUE
またはFALSE
の判定を返し、この判定はWebLogicセキュリティ・フレームワークを通してリソース・コンテナに転送されます。-
判定が
TRUE
の場合、リソース・コンテナはリクエストを保護対象のWebLogicリソースにディスパッチします。 -
判定が
FALSE
の場合、リソース・コンテナはセキュリティ例外をスローします。この例外は、リクエスト側にはリクエストしたアクセスを保護されたWebLogicリソースに対して行う権限がなかったことを示します。
-
カスタム認可プロバイダを開発する必要があるか
WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic認可プロバイダおよびXACML認可プロバイダが含まれています。
ノート:
DefaultAuthorizerとも呼ばれるWebLogic認可プロバイダは、WebLogic Server 14.1.1.0.0で非推奨になっており、今後のリリースで削除されます。かわりにXACML認可プロバイダがデフォルトの認可プロバイダになります。
XACML認可プロバイダは、特定のユーザーが保護対象のWebLogicリソースへのアクセスを許可されているかどうかを判定するためのポリシー・ベースの認可エンジンを使用して、アクセス決定を返します。また、XACML認可プロバイダは、システム内のセキュリティ・ポリシーのデプロイメントとアンデプロイメントもサポートしています。自社の既存の認可メカニズムを使用する場合は、カスタム認可プロバイダを作成してそれを既存のメカニズムに結合できます。
カスタム認可プロバイダでアプリケーションのバージョン管理をサポートする必要があるか
セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピングまたは資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。
カスタム認可プロバイダはスレッド・セーフか
最高のパフォーマンスを実現するため、デフォルトでは、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対して並列変更を実行できます。このため、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。
ただし、カスタムのデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダで並列呼出しがサポートされている場合とサポートされていない場合があります。カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダが並列呼出しをサポートしない場合、並列セキュリティ・ポリシーとロール変更を無効にして、かわりに各アプリケーションとモジュールがキューに配置され、連続してデプロイされる同期メカニズムを実行する必要があります。
ノート:
同期化メカニズムを有効にした場合、定義済のWebLogic Serverプロバイダも含めて、レルム内に構成されているすべてのデプロイ可能なプロバイダが影響を受けます。同期化メカニズムを有効にすると、これらのプロバイダのパフォーマンスに悪影響を与える可能性があります。
この同期化強制メカニズムを有効にする方法については、『Oracle WebLogic Serverセキュリティの管理』を参照してください。
カスタム認可プロバイダの開発方法
XACML認可プロバイダが開発者のニーズを満たさない場合、次のステップでカスタム認可プロバイダを開発することができます。
-
適切なSSPIによるランタイム・クラスの作成、または必要に応じてバルク認可プロバイダを実装
-
必要に応じて、ポリシー・コンシューマSSPIを実装
-
必要に応じて、PolicyStoreMBeanを実装
-
「WebLogic MBeanMakerを使用してMBeanタイプを生成する」で説明されているステップを実行してカスタム認可プロバイダのMBeanタイプを生成
適切なSSPIによるランタイム・クラスの作成
ランタイム・クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次のステップでカスタム認可プロバイダのランタイム・クラスを作成します。
-
AuthorizationProvider SSPIの実装またはDeployableAuthorizationProviderV2 SSPIの実装
-
ノート:
セキュリティ・レルムでは、少なくとも1つの認可プロバイダが
DeployableAuthorizationProvider
SSPIを実装している必要があります。実装していない場合、WebアプリケーションやEJBをデプロイできなくなります。
カスタム認可プロバイダのランタイム・クラスの作成例については、例:サンプル認可プロバイダのランタイム・クラスの作成に関する項を参照してください。
AuthorizationProvider SSPIの実装
AuthorizationProvider
SSPIを実装するには、Provider SSPIの目的で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。
-
getAccessDecision
public AccessDecision getAccessDecision();
getAccessDecision
メソッドは、AccessDecision
SSPIの実装を取得します。MyAuthorizationProviderImpl
.java
という1つのランタイム・クラスの場合、getAccessDecision
メソッドの実装は次のようになります。return this;
ランタイム・クラスが2つの場合、
getAccessDecision
メソッドの実装は次のようになります。return new MyAccessDecisionImpl;
これは、
AuthorizationProvider
SSPIを実装するランタイム・クラスが、AccessDecision
SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。
AuthorizationProvider SSPIについては、Oracle WebLogic Server Java APIリファレンスを参照してください。
DeployableAuthorizationProviderV2 SSPIの実装
DeployableAuthorizationProviderV2
SSPIを実装するには、Provider SSPIの目的とAuthorizationProvider SSPIの実装で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。
-
deleteApplicationPolicies
public void deleteApplicationPolicies(ApplicationInfo application) throws ResourceRemovalException
deleteApplicationPolicies
メソッドは、アプリケーションのポリシーをすべて削除します。deleteApplicationPolicies
メソッドは、管理サーバーでのみ呼び出されます。 -
deployExcludedPolicy
public void deleteApplicationPolicies(DeployPolicyHandle handle, Resource resource) throws ResourceCreationException
deployExcludedPolicy
メソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。 -
deployPolicy
public void deployPolicy(DeployPolicyHandle handle, Resource resource, String[] roleNames) throws ResourceCreationException
deployPolicy
メソッドは、セキュリティ・ポリシーの適用対象となるWebLogicリソースと、セキュリティ・ポリシー内に記載されるセキュリティ・ロール名を基に、デプロイ済みのWebアプリケーションやEJBにかわってセキュリティ・ポリシーを作成します。 -
deployUncheckedPolicy
public void deployUncheckedPolicy(DeployPolicyHandle handle, Resource resource) throws ResourceCreationException
deployUncheckedPolicy
メソッドは、アクセスを常に許可するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。 -
endDeployPolicies
public void endDeployPolicies(DeployPolicyHandle handle) throws ResourceCreationException
deployExcludedPolicy
メソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。 -
startDeployPolicies
public deployPolicyHandle startDeployPolicies(ApplicationInfo application) throws DeployHandleCreationException
startDeployPolicies
メソッドは、アプリケーションのポリシー・デプロイメントの開始をマークし、アプリケーションがターゲット指定されているWebLogic Serverドメイン内のすべてのサーバーで呼び出されます。 -
undeployAllPolicies
public void undeployAllPolicies(DeployPolicyHandle handle) throws ResourceRemovalException
undeployAllPolicies
メソッドは、デプロイされていないWebアプリケーションまたはEJBにかわって、ポリシー定義のセットを削除します。
DeployableAuthorizationProviderV2 SSPIについては、Oracle WebLogic Server Java APIリファレンスを参照してください。
ApplicationInfoインタフェース
ApplicationInfoインタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ・プロバイダに渡します。このデータを使用すると、アプリケーションを一意に識別できます。
セキュリティ・フレームワークは、ユーザーの利便を図るためにApplicationInfoインタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。
DeployableAuthorizationProviderV2
インタフェースとDeployableRoleProviderV2
インタフェースはApplicationInfo
を使用します。たとえば、DeployableAuthorizationProviderV2
のメソッドの実装を例にあげます。セキュリティ・フレームワークは、DeployableAuthorizationProviderV2
のstartDeployPolicies
メソッドを呼び出し、このアプリケーションのApplicationInfoインタフェースを渡します。ApplicationInfo
データは、アプリケーションのデプロイ時にWebLogic Server管理コンソールで提供される情報を基に決められます。
startDeployPolicies
メソッドは、DeployableAuthorizationProviderV2
の他のメソッドでこの後使用できるDeployPolicyHandle
を戻します。
ApplicationInfo
インタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentType
クラスの定義に従って、APPLICATION
、CONTROL_RESOURCE
、EJB
、またはWEBAPP
のいずれかです。
次のコードは、このタスクを実行する方法の一例です。
public DeployPolicyHandle startDeployPolicies(ApplicationInfo appInfo) throws DeployHandleCreationException : // Obtain the application information... String appId = appInfo.getApplicationIdentifier(); ComponentType compType = appInfo.getComponentType(); String compName = appInfo.getComponentName();
セキュリティ・フレームワークは、DeployableAuthorizationProviderV2
deleteApplicationPolicies
メソッドを呼び出し、このアプリケーションのApplicationInfo
インタフェースを渡します。deleteApplicationPolicies
メソッドは、アプリケーションのポリシーをすべて削除します。このメソッドは、アプリケーションが削除されたときにWebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。
AccessDecision SSPIの実装
AccessDecision
SSPIを実装する際には、以下のメソッドの実装を用意する必要があります。
-
isAccessAllowed
public Result isAccessAllowed(Subject subject, Map roles, Resource resource, ContextHandler handler, Direction direction) throws InvalidPrincipalException
isAccessAllowed
メソッドは、サブジェクトに格納されている情報を利用して、リクエスト側に保護対象リソースへのアクセスを許可すべきかどうかを決定します。isAccessAllowed
メソッドはリクエストの前または後に呼び出すことができ、PERMIT
、DENY
、またはABSTAIN
のいずれかの値を返します。複数のアクセス決定が構成されていて、それらが相反する値を返す場合、最終結果を決定するには裁決プロバイダが必要になります。詳細は、「裁決プロバイダ」を参照してください。 -
isProtectedResource
public boolean isProtectedResource(Subject subject, Resource resource) throws InvalidPrincipalException
isProtectedResource
メソッドは、指定されたWebLogicリソースが保護対象かどうかを実際にアクセス・チェックを行わずに決定するために使用します。これは呼出し側のサブジェクトに付与できる一連のセキュリティ・ロールを計算するわけではないので、軽量のメカニズムに過ぎません。
AccessDecision SSPIについては、Oracle WebLogic Server Java APIリファレンスを参照してください。
例:サンプル認可プロバイダのランタイム・クラスの作成
例6-1は、サンプル認可プロバイダのランタイム・クラスであるSampleAuthorizationProviderImpl.java
クラスを示しています。このランタイム・クラスには次の実装が含まれています。
-
initialize
、getDescription
およびshutdown
というSecurityProvider
インタフェースから継承した3つのメソッド(Provider SSPIの目的についてを参照。) -
AuthorizationProvider
SSPIから継承したgetAccessDecision
メソッド(「AuthorizationProvider SSPIの実装」を参照)。 -
deleteApplicationPolicies
、deployExcludedPolicy
、deployPolicy
、deployUncheckedPolicy
、endDeployPolicies
、starteployPolicies
およびundeployAllPolicies
というDeployableAuthorizationProviderV2
SSPIの7つのメソッド(「DeployableAuthorizationProviderV2 SSPIの実装」を参照)。 -
AccessDecision
SSPIのisAccessAllowed
およびisProtectedResource
メソッド(「AccessDecision SSPIの実装」を参照)ノート:
例6-1の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。
例6-1 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()); // remove policies 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); // clear out policies for the application database.removePoliciesForApplication(appId); } private boolean rolesOrSubjectContains(Map roles, Subject subject, String roleOrPrincipalWant) { // first, see if it's a role name match if (roles.containsKey(roleOrPrincipalWant)) { return true; } // second, see if it's a group name match if (SubjectUtils.isUserInGroup(subject, roleOrPrincipalWant)) { return true; } // third, see if it's a user name match if (roleOrPrincipalWant.equals(SubjectUtils.getUsername(subject))) { return true; } // didn't match return false; } private Result isAccessAllowed(Resource resource, Subject subject, Map roles) { // loop over the principals and roles in our database who are allowed to access this resource for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();) { String roleOrPrincipalAllowed = (String)e.nextElement(); if (rolesOrSubjectContains(roles, subject, roleOrPrincipalAllowed)) { return Result.PERMIT; } } // the resource was explicitly mentioned and didn't grant access 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")); // create new policies when existing application is specified if (sourceAppId != null) { database.clonePoliciesForApplication(sourceAppId,appId); } } public void deleteApplicationVersion(String appId) { System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion"); System.out.println("\tapplication identifier\t= " + appId); // clear out policies for the application database.removePoliciesForApplication(appId); } public void deleteApplication(String appName) { System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication"); System.out.println("\tapplication name\t= " + appName); // clear out policies for the application 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() +"]"; } } }
ポリシー・コンシューマSSPI
WebLogic Serverには、JMX (MBean)デフォルト・ポリシーとWebサービス・アノテーション用のポリシー・コンシューマが実装されています。このリリースのWebLogic Serverには、認可プロバイダがポリシー・コレクションを取得するために使用できるSSPIがあります。
PolicyConsumer
SSPIは省略可能です。ポリシー・コレクションを消費するためには、このSSPIを実装する認可プロバイダのみが呼び出されます。
このSSPIでは、初期状態のポリシー・コレクションの配信と、更新後のポリシー・コレクションの配信の両方がサポートされます。
ポリシー・コレクションの消費においては、PolicyConsumer
SSPIをサポートするすべての認可プロバイダが呼び出されます。各認可プロバイダは、特定のポリシー・セットのポリシー・コレクションを取得するかしないかを選択できます。プロバイダでポリシーが永続化される場合、ポリシーを取得する必要があるのは一度のみです。一方、プロバイダでポリシーがメモリーに保持される場合、ポリシー・コレクションを再び取得することも可能です。
用意されているWebLogic Server認可プロバイダでは、ポリシーはLDAP内に永続化されます。
必要なSSPIインタフェース
カスタム認可プロバイダでポリシー・コレクションの配信をサポートするには、次の3つのインタフェースを実装する必要があります。
-
weblogic.security.spi.PolicyConsumerFactory
-
weblogic.security.spi.PolicyConsumer
-
weblogic.security.spi.PolicyCollectionHandler
-
これらのインタフェースについては、これ以降の節で説明します。
PolicyConsumerFactory SSPIインタフェースの実装
認可プロバイダには、PolicyConsumerのインスタンスをWebLogicセキュリティ・フレームワークで使用できるように、PolicyConsumerFactory
インタフェースが実装されています。WebLogicセキュリティ・フレームワークではPolicyConsumerFactory
の実装を呼び出して、プロバイダのポリシー・コンシューマの実装を取得します。
PolicyConsumerFactory
SSPIにはメソッドが1つあり、このメソッドはPolicyConsumer
SSPIインタフェースの実装を返します。
public interface PolicyConsumerFactory { /** * Obtain the implementation of the PolicyConsumer * security service provider interface (SSPI). * * @return a PolicyConsumer SSPI implementation. */ public PolicyConsumer getPolicyConsumer(); }
PolicyConsumer SSPIインタフェースの実装
PolicyConsumer
SSPIは、ポリシー・コレクションを消費するためのポリシー・コレクション・ハンドラを戻します。これにはgetPolicyCollectionHandler()
というメソッドが1つあり、このメソッドは引数にPolicyCollectionInfo
の実装を取って、PolicyCollectionHandler
インタフェースの実装を戻します。
public interface PolicyConsumer { /** * Obtain a policy handler for consumption of a policy set. * * @param info the PolicyCollectionInfo for the policy set. * * @return a PolicyCollectionHandler or NULL which indicates * that the policy set is not needed. * * @exception ConsumptionException if an error occurs * obtaining the handler and the policy set cannot be consumed. */ public PolicyCollectionHandler getPolicyCollectionHandler( PolicyCollectionInfo info) throws ConsumptionException; }
WebLogicセキュリティ・フレームワークではgetPolicyCollectionHandler()
メソッドを呼び出して、ポリシー・コレクションに関するデータをPolicyCollectionInfo
インタフェースの実装としてセキュリティ・プロバイダに渡します。(このインタフェースはあらかじめ実装されているので、ユーザーが実装する必要はありません。)
PolicyCollectionInfo
のgetName()
、getVersion()
、getTimestamp()
、およびgetResourceTypes()
メソッドを使用して、このポリシー・セットに関する情報を検索します。検索後にはPolicyCollectionHandler
を返すか、ポリシー・コレクションが不要であることを示すNULLを返します。
public interface PolicyCollectionInfo { /** * Get the name of the collection. */ public String getName(); /** * Get the runtime version of the policy. */ public String getVersion(); /** * Get the timestamp of the policy. */ public String getTimestamp(); /** * Get the resource types used in the policy collection. */ public Resource[] getResouceTypes(); }
PolicyCollectionHandler SSPIインタフェースの実装
PolicyConsumer.getPolicyCollectionHandler()
メソッドはPolicyCollectionHandler
インタフェースの実装を返します。PolicyCollectionHandler
にはsetPolicy
、setUncheckedPolicy
、およびdone()
という3つのメソッドがあります。setPolicy()
はリソースおよびロールの名前を取り、ロールに基づいてポリシーを設定します。setUncheckedPolicy()
メソッドはすべてのユーザーにアクセスを許可します。
done()
メソッドはポリシー・コレクションの完了を示します。done()
メソッドでは、ポリシー・セットの古いポリシーをすべて削除することをお薦めします。
public interface PolicyCollectionHandler { /** * Set a policy for the specified resource. */ public void setPolicy(Resource resource, String[] roleNames) throws ConsumptionException; /** * Sets a policy which always grants access. */ public void setUncheckedPolicy(Resource resource) throws ConsumptionException; /** * Signals the completion of the policy collection. */ public void done() throws ConsumptionException; }
更新後のポリシー・コレクションのサポート
更新後のポリシー・コレクションの配信をサポートするには、PolicyConsumer
SSPIをサポートするすべての認可プロバイダでPolicyConsumer.getPolicyCollectionHandler()
メソッドに渡されたPolicyCollectionInfo
の内容を調べて、ポリシー・セットが変更されているかどうかを判断する必要があります。各プロバイダでは、初期状態のポリシー・コレクションとSSPIの外部から受け取ったカスタマイズ後のポリシーとの競合を解決する方法を(できれば構成によって)決定しておくことが必要です。
WebLogic Serverで提供されている認可プロバイダでは、カスタマイズ後のポリシーが更新後のポリシー・コレクションで置き換えられません。初期状態のポリシー・コレクションのポリシーはすべて削除され、カスタマイズ後のポリシーと更新後のポリシー・コレクションのみが有効になります。ポリシー・コレクションの情報に異なるタイム・スタンプやバージョンがある場合、更新後のポリシー・コレクションとして扱われます。コレクションの名前は永続キーとして使用されます。
PolicyStoreMBean
このリリースの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 WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
ポリシーはXACML 2.0のポリシーまたはPolicySetドキュメントで表現されます。カスタム認可プロバイダでは、XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
)に記載されている標準の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 Policyファイルの形式の調べ
XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
)および『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明しているOracle拡張が、提供されているXACML認可プロバイダおよびロール・マッピング・プロバイダで使用するXACMLポリシー・ファイルについての最も確実な情報です。
ただしサポートされているXACMLファイルの形式を開発プロセスの一環として確認する場合は、おそらく、WebLogic Server管理コンソールを使用して、XACML認可またはロール・マッピング・プロバイダのデータベースからデータをXACMLファイルとしてエクスポートする方法が最も便利です。エクスポートしたXACMLファイルをコピーして別の名前で保存し、任意のツールで確認します。
ノート:
エクスポートしたファイルは読取り専用としてください。変更した場合、そのファイルはWebLogic Serverにインポートし直さないでください。エクスポートしたファイルを編集すると、WebLogic Server構成が使用できなくなる可能性があります。エクスポートしたファイルの編集はサポートされていません。
WLSTを使用してPolicyStoreMBeanにポリシーの追加
例6-2に、WLSTを使用してXACMLファイルからPolicyStoreMBeanのインスタンスに1つのポリシーを追加する例を示します。
この例ではこのスクリプトで使用するプロパティを、次のant
スクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。
<property name="xacml-docs-dir" value="${xacmldir}/xacml-docs"/> <sysproperty key="file" value="${xacml-docs-dir}/policy-getSubject.xacml"/>
通常はWLSTコマンドにクリア・テキストのパスワードを入力しないでください。特に、クリア・テキストのパスワードが含まれるWLSTスクリプトをディスクに保存することは避けてください。このような状況では、暗号化されたパスワードを渡すメカニズムをかわりに使用する必要があります。WebLogic Scripting Toolの理解のWLSTのセキュリティに関する項を参照してください。
例6-2 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") : :
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
WLSTを使用してPolicySetをStringとして読み込む
例6-3に、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"/>
通常はWLSTコマンドにクリア・テキストのパスワードを入力しないでください。特に、クリア・テキストのパスワードが含まれるWLSTスクリプトをディスクに保存することは避けてください。このような状況では、暗号化されたパスワードを渡すメカニズムをかわりに使用する必要があります。WebLogic Scripting Toolの理解のWLSTのセキュリティに関する項を参照してください。
例6-3 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インタフェースがあります。
-
BulkAuthorizationProvider
-
BulkAccessDecision
バルク・アクセスSSPIインタフェースを使用すると、認可プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」
ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResource
オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。
バルク・バージョンでないSSPIインタフェースとバルク・バージョンのSSPIインタフェースの使用方法には若干の違いがあります。
BulkAccessDecision.isAccessAllowed()
メソッドはロールのMap
を引数に取ります。これは、第1にResource
オブジェクト、続いてロール名(Map<Resource, Map<String, SecurityRole>> roles)
で索引付けされ、サブジェクトに関連付けられているもので、認可判定時に考慮に入れる必要があります。
BulkAccessDecision.isAccessAllowed()
メソッドはMap
(Resource、結果で索引付け)
を返します。これは、リソースに定義された認可ポリシーが、リクエストされたメソッドの実行を許可するかどうかを示します。
管理コンソールによるカスタム認可プロバイダの構成
カスタム認可プロバイダを構成するということは、認可サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム認可プロバイダを追加するということです。
カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この項では、カスタム認可プロバイダの構成担当者向けの重要な情報を取り上げます。
-
ノート:
WebLogic Server管理コンソールを使用してカスタムの認可プロバイダを構成するステップは、Oracle WebLogic Serverセキュリティの管理のWebLogicセキュリティ・プロバイダの構成を参照してください。
認可プロバイダとデプロイメント記述子の管理
Enterprise JavaBeans (EJB)やWebアプリケーションなどのアプリケーションの中には、Java EEの関連デプロイメント情報とWebLogic Serverデプロイメント記述子を格納するものがあります。Webアプリケーションの場合、デプロイメント記述子ファイル(web.xml
とweblogic.xml
)には、セキュリティ・ポリシーの宣言を含むJava EEセキュリティ・モデルの実装情報が記述されます。この情報は、WebLogic Server管理コンソールで認可プロバイダを初めて構成するときに格納するのが一般的です。
Java EEプラットフォームはデプロイメント記述子でWebアプリケーションおよびEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、WebアプリケーションおよびEJBリソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することもWebLogic Server管理コンソールのみを使用することもできます。また、状況によっては、この2つの方法を組み合せることもできます。
選択した方法によって、セキュリティ・モデルを適用する必要もあります。WebLogicでは、個々のデプロイメントについて複数のセキュリティ・モデルがサポートされ、使用する方法を組み込むレルム全体の構成についてはセキュリティ・モデルがサポートされます。
デプロイメント記述子を使用するように構成すると、WebLogic Serverによりweb.xml
およびweblogic.xml
デプロイメント記述子ファイルからセキュリティ・ポリシー情報が読み込まれます(web.xml
ファイルとweblogic.xml
ファイルの例は、例6-4と例6-5を参照)。この情報は、認可プロバイダのセキュリティ・プロバイダ・データベースにコピーされます。
例6-4 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>
例6-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>
セキュリティ・ポリシー・デプロイメントの有効化
カスタム認可プロバイダの開発の一環としてDeployableAuthorizationProviderV2
SSPIを実装し、デプロイ可能なセキュリティ・ポリシーをサポートする場合、カスタム認可プロバイダの構成担当者(つまり、開発者または管理者)は、WebLogic Server管理コンソールで「ポリシー・デプロイメントを有効化」チェック・ボックスがチェックされていることを確認する必要があります。そうでない場合、認可プロバイダのデプロイメントはオフと見なされます。このため、複数の認可プロバイダが構成されている場合、「ポリシー・デプロイメントを有効化」チェック・ボックスを使用して、セキュリティ・ポリシーのデプロイメントに使用する認可プロバイダを指定できます。
セキュリティ・ポリシーを管理するためのメカニズムの提供
WebLogic Server管理コンソールを使用してカスタム認可プロバイダを構成すると、認可サービスを必要とするアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられたセキュリティ・ポリシーを管理する方法を管理者にも提供する必要があります。たとえばWebLogic認可プロバイダには、ポリシー・エディタ・ページが管理者向けに用意されており、様々なWebLogicリソースのセキュリティ・ポリシーを追加、変更、または削除することができます。
カスタム認可プロバイダを開発すると、管理者はポリシー・エディタ・ページも右クリック・メニューも利用できません。したがって、セキュリティ・ポリシーを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム認可プロバイダのデータベースのセキュリティ・ポリシー・データ(つまり式)を読み書きできなければなりません。
それには、以下の2通りの方法があります。
オプション1 :セキュリティ・ポリシー管理用のスタンドアロン・ツールの開発
WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。
この方法では、カスタム認可プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。
-
WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。「WebLogicリソース識別子」を参照してください。
-
セキュリティ・ポリシーを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。
-
カスタム認可プロバイダのデータベースの式を読み書きします。
オプション2 : 管理コンソールに既存のセキュリティ・ポリシー管理ツールの統合
WebLogic Server管理コンソールとは別のツールを持っているが、そのツールをWebLogic Server管理コンソールから起動する場合には、通常、この方法を選択します。
この方法の場合、ツールでは以下のことを行う必要があります。
-
WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。「WebLogicリソース識別子」を参照してください。
-
セキュリティ・ポリシーを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。
-
カスタム認可プロバイダのデータベースの式を読み書きします。
-
基本的なコンソール拡張方法を使用して、WebLogic Server管理コンソールにリンクします。