Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
戻る |
次へ |
開発作業を綿密に計画すると、カスタム セキュリティ プロバイダの開発に要する時間と労力を大幅に削減できます。以下の節では、最初に知っておくと役立つ、セキュリティ プロバイダの概念と機能について詳しく説明します。
作成できるセキュリティ プロバイダにはさまざまなタイプがありますが (『Oracle Fusion Middleware Oracle WebLogic Server Security の紹介』の「セキュリティ プロバイダのタイプ」を参照)、それらのプロバイダはすべて同じアーキテクチャに基づきます。図 3-1 に、セキュリティ プロバイダの一般的なアーキテクチャを示します。このアーキテクチャの説明については図の下を参照してください。
注意 : SSPI および SSPI を使用して作成する実行時クラス (実装) は両方とも .java ファイルです。図 3-1 の左側を参照してください。図 3-1 の右側のファイルと同様、MyFooMBean は .xml ファイルとして開始します。このファイルで、SSPI MBean を拡張 (および任意で実装) します。この MBean 定義ファイル (MDF) が WebLogic MBeanMaker ユーティリティで実行される場合、このユーティリティでは MBean タイプ用の .java ファイルが生成されます。「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。 |
図 3-1 は、カスタム セキュリティ プロバイダの開発時に作成された 1 つの実行時クラス (MyFooProviderImpl
) と MBean タイプ (MyFooMBean
) の関係を示しています。プロセスは WebLogic Server インスタンスの起動時に始まり、WebLogic Security フレームワークは以下のことを行います。
セキュリティ レルムでセキュリティ プロバイダと関連付けられた MBean タイプを見つけます。
MBean タイプからセキュリティ プロバイダの実行時クラス (2 つある場合は「Provider」SSPI を実装する方の実行時クラス) の名前を取得します。
セキュリティ プロバイダが初期化 (コンフィグレーション データの読み込み) に使用する適切な MBean インスタンスを渡します。
このため、実行時クラス (1 つまたは複数) と MBean タイプの両方で「セキュリティ プロバイダ」と呼ばれるものが形成されます。
「開発プロセスの概要」で説明されているように、カスタム セキュリティ プロバイダの開発ではまず最初に多くのセキュリティ サービス プロバイダ インタフェース (SSPI) を実装して実行時クラスを作成します。この節では、以下の助けになる情報を提供します。
また、この節では各タイプのセキュリティ プロバイダでどの SSPI を実装できるのかを示す「SSPI クイック リファレンス」も提供します。
セキュリティ プロバイダは、以下の制限事項に準拠している必要があります。
カスタム セキュリティ プロバイダの実行時クラスの実装には、WebLogic Security フレームワークによるセキュリティ チェックの実行を必要とするコードを含めることはできない。セキュリティ プロバイダは実際にセキュリティ チェックを実行し、WebLogic リソースへのアクセス権を付与する WebLogic Security フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。
セキュリティ プロバイダの実装内で、ローカル (同じサーバ、クラスタ、またはドメイン内) の Java Platform, Enterprise Edition (Java EE) バージョン 5 サービスを使用することはできない。これらの使用を試行することもサポートされていません。たとえば、セキュリティ プロバイダから現在のドメイン内の EJB を呼び出すことは禁止されています。
他のドメインの Java EE サービスであれば、セキュリティ プロバイダからアクセスおよび使用できます。
名前が「Provider」というサフィックスで終わる各 SSPI (たとえば CredentialProvider
) は、セキュリティ プロバイダのサービスを WebLogic Security フレームワークにエクスポーズします。これによって、セキュリティ プロバイダの操作 (初期化、開始、停止など) が可能になります。
図 3-2, で示されているように、セキュリティ サービスを WebLogic Security フレームワークにエクスポーズする SSPI は WebLogic Server によって提供され、そのすべてが以下のメソッドを持つ SecurityProvider
インタフェースを拡張します。
initialize
public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)
initialize
メソッドは、セキュリティ プロバイダの関連付けられた MBean インスタンスに限定できる ProviderMBean
を引数として取ります。その MBean インスタンスは生成する MBean タイプから作成され、カスタム セキュリティ プロバイダを WebLogic Server 環境で管理できるようにするコンフィグレーション データを含みます。このコンフィグレーション データがある場合は、initialize
メソッドを使用してそれを抽出する必要があります。
securityServices
引数は、カスタム セキュリティ プロバイダで監査サービスを取得して使用する際の取得先となるオブジェクトです。監査サービスと監査の詳細については、「監査プロバイダ」および「カスタム セキュリティ プロバイダからのイベントの監査」を参照してください。
getDescription
public String getDescription()
このメソッドは、カスタム セキュリティ プロバイダについて簡単に説明したテキストを返します。
shutdown
public void shutdown()
このメソッドは、カスタム セキュリティ プロバイダを停止させます。
SecurityProvider
を拡張するものなので、名前が「Provider」で終わる SSPI を実装する実行時クラスは継承したメソッドの実装を提供する必要があります。
WebLogic Server のこのリリースには、以下に示すバルク アクセス バージョンの認可プロバイダ、裁決プロバイダ、およびロール マッピング プロバイダの SSPI インタフェースが含まれています。
BulkAuthorizationProvider
BulkAccessDecision
BulkAdjudicationProvider
BulkAdjudicator
BulkRoleProvider
BulkRoleMapper
バルク アクセス SSPI インタフェースを使用すると、認可、裁決、およびロール マッピング プロバイダにおいて、1 回の呼び出しで複数の判定要求を取得できます。「for
」ループなどで複数の呼び出しを実行する必要がありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource
オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。
詳細については、「バルク認可プロバイダ」、「バルク認可プロバイダ」および「バルク ロール マッピング プロバイダ」を参照してください。
名前が「Deployable」で始まり、「Provider」で終わる SSPI の実装 (DeployableRoleProviderV2
など) は、カスタム セキュリティ プロバイダのサービスを WebLogic Security フレームワークにエクスポーズします (「「Provider」SSPI の目的について」を参照)。ただし、それらの SSPI の実装では追加のタスクも実行されます。これらの SSPI はまた、サーブレット デプロイメント記述子 (web.xml
、weblogic.xml
)、EJB デプロイメント記述子 (ejb-jar.xml
、weblogic-ejb.jar.xml
)、および EAR デプロイメント記述子 (application.xml
、weblogic-application.xml
) をはじめとするデプロイメント記述子におけるセキュリティのサポートを提供します。
認可プロバイダ、資格マッピング プロバイダ、およびロール マッピング プロバイダには、デプロイ可能バージョンの「Provider」SSPI があります。
注意 : セキュリティ ポリシー、セキュリティ ロール、および資格を格納するセキュリティ プロバイダ データベースが読み込み専用の場合、認可、ロール マッピング、および資格マッピングの各セキュリティ プロバイダ用にデプロイ可能ではないバージョンの SSPI を実装できます。ただし、その場合でも、デプロイメントを処理するセキュリティ プロバイダのデプロイ可能バージョンをコンフィグレーションする必要があります。 |
Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってポリシーをデプロイできる認可プロバイダでは、AuthorizationProvider
SSPI ではなく DeployableAuthorizationProviderV2
SSPI を実装する必要があります。しかし、DeployableAuthorizationProviderV2
SSPI は AuthorizationProvider
SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、Web アプリケーションや EJB のデプロイメント作業では、認可プロバイダがポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの認可プロバイダが DeployableAuthorizationProviderV2
SSPI をサポートする必要があり、サポートされていない場合、Web アプリケーションや EJB をデプロイできなくなります。
注意 : セキュリティ ポリシーの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「セキュリティ ポリシー」を参照してください。 |
Web アプリケーションまたはエンタープライズ JavaBean (EJB) のデプロイメントに代わってロールをデプロイできるロール マッピング プロバイダでは、RoleProvider
SSPI ではなくDeployableRoleProviderV2
SSPI を実装する必要があります。しかし、DeployableRoleProviderV2
SSPI は RoleProvider
SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、Web アプリケーションや EJB のデプロイメント作業では、ロール マッピング プロバイダがセキュリティ ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つのロール マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、Web アプリケーションや EJB をデプロイすることが不可能になります。
注意 : セキュリティ ロールの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。 |
注意 : DeployableCredentialProvider インタフェースは、このリリースの WebLogic Server で非推奨になりました。 |
リソース アダプタ (RA) のデプロイメントに代わってセキュリティ ポリシーをデプロイできる資格マッピング プロバイダでは、CredentialProvider
SSPI ではなく DeployableCredentialProvider
SSPI を実装する必要があります。しかし、DeployableCredentialProvider
SSPI は CredentialProvider
SSPI の拡張なので、実際には両方の SSPI のメソッドを実装する必要があります。というのも、リソース アダプタのデプロイメント作業では、資格マッピング プロバイダが資格およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ レルムでは、少なくとも 1 つの資格マッピング プロバイダがこの SSPI をサポートする必要があり、そうでなければ、リソース アダプタをデプロイすることが不可能になります。
注意 : 資格の詳細については、「資格マッピングの概念」を参照してください。セキュリティ ポリシーの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「セキュリティ ポリシー」を参照してください。 |
図 3-3 は、資格マッピング プロバイダを使用してすべての SSPI に共通の継承階層を示すとともに、実行時クラスでどのようにそれらのインタフェースを実装できるのかを示します。この例では、Oracle が提供する SecurityProvider
インタフェースと、CredentialProviderV2
および CredentialMapperV2
SSPI を使用します。図 3-3 は、CredentialProviderV2
SSPI および CredentialMapperV2
SSPI を実装する MyCredentialMapperProviderImpl
という 1 つの実行時クラスを表しています。
ただし、図 3-3 SSPI を実装できる 1 つの方法のみを示します (1 つの実行時クラスを作成する方法)。必要に応じて、図 3-4 で示されているように 2 つの実行時クラスを使用することもできます。2 つとは、名前が「Provider」で終わる SSPI (CredentialProviderV2
など) の実装のための実行時クラスと、他の SSPI (CredentialMapperV2
SSPI など) の実装のための実行時クラスです。
2 つの実行時クラスがある場合、名前が「Provider」で終わる SSPI を実装するクラスは他の SSPI を実装する実行時クラスを生成するためのファクトリとして機能します。たとえば、図 3-4 では、MyCredentialMapperProviderImpl
が MyCredentialMapperImpl
を生成するためのファクトリとして機能します。
注意 : 実行時実装クラスを 2 つにする場合は、セキュリティ プロバイダの MBean タイプを生成するときに必ず両方の実行時実装クラスを MBean JAR ファイル (MJF) に格納する必要があります。詳細については、「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。 |
表 3-1 に、セキュリティ プロバイダのタイプ (およびそれらのコンポーネント) と、その開発に使用する SSPI およびその他のインタフェースとの対応を示します。
表 3-1 セキュリティ プロバイダとそのコンポーネント、および対応する SSPI
タイプ/コンポーネント | SSPI/インタフェース |
---|---|
認証プロバイダ |
|
LoginModule (JAAS) |
|
ID アサーション プロバイダ |
|
ID アサータ |
|
プリンシパル検証プロバイダ |
|
認可 |
|
アクセス決定 |
|
裁決プロバイダ |
|
Adjudicator |
|
ロール マッピング プロバイダ |
|
ロール マッパー |
|
監査プロバイダ |
|
監査チャネル |
|
資格マッピング プロバイダ |
|
資格マッパー |
|
証明書パス プロバイダ |
|
バージョン管理可能なアプリケーションのプロバイダ |
|
注意 : カスタム セキュリティ プロバイダの実行時クラスを作成するために使用する SSPI は、weblogic.security.spi パッケージに配置されます。このパッケージの詳細については、「WebLogic Server API リファレンス Javadoc」を参照してください。 |
「開発プロセスの概要」で説明されているように、カスタム セキュリティ プロバイダ開発の 2 番目の手順では、カスタム セキュリティ プロバイダの MBean タイプを生成します。この節では、以下の助けになる情報を提供します。
また、この節ではどの必須 SSPI MBean を拡張する必要があるのか、そしてどの任意 SSPI MBean を各タイプのセキュリティ プロバイダで実装できるのかを示す「SSPI MBean クイック リファレンス」も提供します。
カスタム セキュリティ プロバイダの実行時クラスを作成することに加えて、MBean タイプを生成することも必要です。MBean という用語は管理対象 Bean (managed bean) の略で、JMX (Java Management eXtensions) で管理可能なリソースを表す Java オブジェクトのことです。
注意 : JMX は Sun Microsystems によって策定された仕様で、標準的な管理アーキテクチャ、API、および管理サービスを定義しています。詳細については、『Java Management Extensions White Paper』 (http://java.sun.com/j2se/reference/whitepapers/index.html ) を参照してください。 |
MBean タイプは、MBean のインスタンスのファクトリです。MBean のインスタンスは、WebLogic Server Administration Console を使用して作成できます。MBean のインスタンスが作成されたら、Administration Console でそのインスタンスを使用してカスタム セキュリティ プロバイダをコンフィグレーションおよび管理できます。
注意 : すべての MBean インスタンスは自分の親タイプを認識しているので、MBean タイプのコンフィグレーションを変更すると、Administration Console を使用して作成したすべてのインスタンスのコンフィグレーションも更新されます。(詳細については、「SSPI MBean の階層と Administration Console に対する影響について」を参照してください)。 |
MBean タイプを作成するには SSPI MBean という MBean インタフェースを使用します。カスタム セキュリティ プロバイダ用の MBean タイプを作成するのに利用できる SSPI MBean には、以下の 2 つのタイプがあります。
必須 SSPI MBean。セキュリティ プロバイダを WebLogic Server 環境内でコンフィグレーションおよび管理できるようにするための基本的なメソッドが定義されるので、拡張する必要があります。
任意 SSPI MBean。セキュリティ プロバイダを管理するための追加メソッドが定義されるので実装することができます。セキュリティ プロバイダのタイプが異なれば、利用できる任意 SSPI MBean も異なります。
詳細については、「SSPI MBean クイック リファレンス」を参照してください。
MBean 定義ファイル (MDF) は、WebLogic MBeanMaker ユーティリティで、MBean タイプを構成する Java ファイルを生成するために使用される XML ファイルです。すべての MDF では、作成済みのセキュリティ プロバイダのタイプに固有の必須 SSPI MBean を拡張する必要があり、これに加えて任意 SSPI MBean を実装することもできます。
コード リスト 3-1 に、サンプルの MBean 定義ファイル (MDF) を示します。その内容の説明については、リストの下を参照してください。具体的には、WebLogic 資格マッピング プロバイダの MBean タイプを生成するために使用する MDF です。DeployableCredentialProvider インタフェースは、このリリースの WebLogic Server で非推奨になったので注意してください。
コード リスト 3-1 DefaultCredentialMapper.xml
<MBeanType Name = "DefaultCredentialMapper" DisplayName = "DefaultCredentialMapper" Package = "weblogic.security.providers.credentials" Extends = "weblogic.management.security.credentials.DeployableCredentialMapper" Implements = "weblogic.management.security.credentials.UserPasswordCredentialMapEditor, weblogic.management.security.credentials.UserPasswordCredentialMapExtendedReader, weblogic.management.security.ApplicationVersioner, weblogic.management.security.Import, weblogic.management.security.Export" PersistPolicy = "OnUpdate" Description = "This MBean represents configuration attributes for the WebLogic Credential Mapping provider.<p>" > <MBeanAttribute Name = "ProviderClassName" Type = "java.lang.String" Writeable = "false" Default = ""weblogic.security.providers.credentials.DefaultCredentialMapperProviderImpl"" Description = "The name of the Java class that loads the WebLogic Credential Mapping provider." /> <MBeanAttribute Name = "Description" Type = "java.lang.String" Writeable = "false" Default = ""Provider that performs Default Credential Mapping"" Description = "A short description of the WebLogic Credential Mapping provider." /> <MBeanAttribute Name = "Version" Type = "java.lang.String" Writeable = "false" Default = ""1.0"" Description = "The version of the WebLogic Credential Mapping provider." /> : : </MBeanType>
<MBeanType>
タグ内の太字の属性は、この MDF が DefaultCredentialMapper
という名前であり、DeployableCredentialMapper
という必須 SSPI MBean を拡張するものであることを示しています。また、この MDF では、UserPasswordCredentialMapEditor
任意 SSPI MBean を実装することで付加的な管理機能も組み込んでいます。
<MBeanAttribute>
タブで定義されている ProviderClassName
、Description
、および Version
の各属性は、セキュリティ プロバイダの基本的なコンフィグレーション方法を定義するものであり、Provider
という基本必須 SSPI MBean から継承されるものなので、セキュリティ プロバイダの MBean タイプを生成するために使用されるどのような MDF でも必須です (図 3-5 を参照)。ProviderClassName
属性は特に重要です。ProviderClassName
属性の値は、セキュリティ プロバイダの実行時クラスの Java ファイル名 (すなわち、「Provider」という文字列で終わる適切な SSPI の実装) です。コード リスト 3-1 で示されているサンプルの実行時クラスは、DefaultCredentialMapperProviderImpl.java
です。
コード リスト 3-1 では示されていませんが、<MBeanAttribute>
タグや <MBeanOperation>
タグを使用して MDF に属性や操作を追加できます。ほとんどのカスタム属性は、WebLogic Server Administration Console のカスタム セキュリティ プロバイダの [プロバイダ固有] タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります(「コンソール拡張機能の記述」を参照)
注意 : サンプル監査プロバイダは、カスタム属性の追加例を提供しています。 |
WL_HOME\server\lib\mbeantypes
からロードされるクラスは、WebLogic Server にデプロイされている他の JAR ファイルや EAR ファイルからは認識されません。共有する必要がある共通のユーティリティ クラスがある場合、そのクラスはシステムのクラス パスに配置する必要があります。
注意 : MBean タイプのインストール用のディレクトリは、デフォルトではWL_HOME\server\lib\mbeantypes ですが、初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\lib\mbeantypes からもロードできます。...\domaindir\lib\mbeantypes ディレクトリからロードした JAR ファイルは複数のアプリケーションで共有できるので、明示的にシステム クラスパスに配置する必要はありません。 |
カスタム プロバイダの MBean は、JDK 例外の型または weblogic.management.utils
例外の型のみを送出する必要があります。それ以外の場合、JMX クライアントには、例外を受け付ける必要があるコードが含まれていない可能性があります。
型付き例外の場合、その型から独自の例外の型を派生させて送出するのではなく、MBean メソッドの throw 句から正しい型のみを送出する必要があります。
ネストされた例外の場合は、JDK 例外の型または weblogic.management.utils
例外のみを送出する必要があります。
実行時例外の場合は、JDK 例外のみを送出するか、JDK 例外を介してのみ渡す必要があります。
表 A-1 に示すように、Encrypted 属性を使用すると、MBean 属性の値がクリアテキストとして表示されないように指定できます。たとえば、パスワードの入力を取得したときに MBean 属性の値を暗号化する場合などです。以下のコードでは、Encrypted 属性の使用例を示します。
<MBeanAttribute Name = "PrivatePassPhrase" Type = "java.lang.String" Encrypted = "true" Default = """" Description = "The Keystore password." />
MBean 定義ファイル (MDF) で拡張する必須 SSPI MBean (基本 SSPI MBean である Provider
に至るまで) に指定されている属性と操作はすべて、関連するセキュリティ プロバイダの WebLogic Server Administration Console ページに自動的に表示されます。これらの属性と操作は、カスタム セキュリティ プロバイダをコンフィグレーションおよび管理するために使用します。
注意 : 認証セキュリティ プロバイダに限っては、MDF で実装される任意 SSPI MBean で指定された属性と操作も Administration Console で自動的にサポートされます。他のタイプのセキュリティ プロバイダの場合、任意 SSPI MBean から継承された属性/操作を Administration Console で使用するには、コンソール拡張機能を記述する必要があります。詳細については、「コンソール拡張機能の記述」を参照してください。 |
図 3-5 は、WebLogic 資格マッピング MDF を例に使用してセキュリティ プロバイダの SSPI MBean 階層を示すとともに、どの属性/操作が WebLogic 資格マッピング プロバイダの Administration Console で表示されるのかを示します。
図 3-5 で示されているように、DefaultCredentialMapper
MDF の SSPI MBean の階層を実装することにより、図 3-6 のページが Administration Console で表示されます。DefaultCredentialMapper
MDF の部分的なリストは、コード リスト 3-1 に示してあります。
図 3-6 DefaultCredentialMapper の場合の Administration Console ページ
[名前]、[説明]、および [バージョン] の各フィールドは、Provider
という基本必須 SSPI MBean から継承され DefaultCredentialMapper
MDF に指定されている同名の属性から得られたものです。DefaultCredentialMapper
MDF 内の DisplayName
属性から [名前] フィールドの値が生成されるほか、Description
と Version
の各属性からも、それぞれ対応するフィールドの値が生成されることに注意します。なお、[プロバイダ固有] ページの [資格マッピング デプロイメントを有効化] フィールドが表示されているのは、DefaultCredentialMapper
MDF の拡張元である DeployableCredentialMapper
必須 SSPI MBean に CredentialMappingDeploymentEnabled
属性が定義されているためです。この Administration Console ページには、UserPasswordCredentialMapEditor
任意 SSPI MBean の DefaultCredentialMapper
の実装に対応するフィールドは表示されません。
WebLogic MBeanMaker は、MBean 定義ファイル (MDF) を入力とし、MBean タイプのファイルを出力するコマンドライン ユーティリティです。WebLogic MBeanMaker を使用して作成した MDF を実行すると、以下のことが行われます。
必須 SSPI MBean から継承された属性 (MDF に追加されたカスタム属性も同様) により、WebLogic MBeanMaker によって MBean タイプの情報ファイルに完全なゲッター/セッター メソッドが生成される (MBean 情報ファイルは図 3-7 に示されていない)。MBean 情報ファイルの詳細については、「MBean 情報ファイルについて」を参照してください。
開発者のアクション - なし。これらのメソッドでさらなる作業は必要ありません。
任意 SSPI MBean から継承された操作により、MBean の実装ファイルでメソッドが継承される (メソッドの実装は一から記述しなければならない)
開発者のアクション - 現時点では、WebLogic MBeanMaker では継承されたメソッドのメソッド スタブが生成されません。したがって、適切な実装を提供する必要があります。
MDF に追加されたカスタム操作により、WebLogic MBeanMaker によってメソッド スタブが生成される。
開発者のアクション - メソッドの実装を提供する必要があります。ただし、WebLogic MBeanMaker でスタブが生成されるので、Java メソッドのシグネチャを参照する必要はありません。
このことを図 3-7 に示します。
MBean 情報ファイルには、MBean 定義ファイル内のデータのコンパイル済みの定義が、JMX Model MBeans で要求される形式で含まれます。このファイルの形式は、それぞれがそのエンティティを記述する記述子タグのセットを持つ属性、操作、通知のリストです。加えて、MBean 自体にも、一連の記述子タグがあります。この形式の例を次に示します。
MBean + tags attribute1 + tags, attribute2 + tags ... operation1 + tags, operation2 + tags ... notification1 + tags, notification2 + tags ...
必要に応じて、標準の JMX サーバの getMBeanInfo
メソッドを呼び出し、ModelMBeanInfo
を取得することで、実行時にこの情報にアクセスできます。
注意 : 返された構造を解釈する方法を決定するために、必ず JMX 仕様を参照してください。 |
カスタム セキュリティ プロバイダの開発の一部として実装する必要のある SSPI のリストに基づいて、拡張する必要のある必須 SSPI MBean を表 3-2 で特定できます。また、表 3-3 から 表 3-5 では、セキュリティ プロバイダを管理するために実装できる任意 SSPI MBean を特定できます。
表 3-2 必須 SSPI MBean
タイプ | パッケージ名 | 必須 SSPI MBean |
---|---|---|
認証プロバイダ |
|
|
ID アサーション プロバイダ |
|
|
認可プロバイダ |
|
|
裁決プロバイダ |
|
|
ロール マッピング プロバイダ |
|
|
監査プロバイダ |
|
|
資格マッピング プロバイダ |
|
|
証明書パス プロバイダ |
|
|
表 3-3 認証用任意 SSPI MBean
任意 SSPI MBean | 用途 |
---|---|
|
グループを作成する。当該グループがすでに存在する場合には、例外が送出される。 |
|
グループのメンバーを列挙する。 |
|
グループに関するデータを読み込む。 |
|
グループを削除する。 |
|
あるユーザまたはグループが所属するグループを列挙する。 |
|
ユーザを作成、編集、および削除する。 |
|
ユーザのパスワードを変更する。 |
|
ユーザに関するデータを読み込む。 |
|
ユーザを削除する。 |
注意 : 表 3-3 に示した認証用任意 SSPI MBean は、weblogic.management.security.authentication パッケージに定義されています。また、これらは WebLogic Server Administration Console でもサポートされます。 |
表 3-4 認可用任意 SSPI MBean
任意 SSPI MBean | 用途 |
---|---|
|
プロバイダでポリシーの消費をサポートすることを示す。 |
|
セキュリティ ポリシーを作成、編集、および削除する。 |
|
ポリシーに関するデータをリストする。 |
|
セキュリティ ポリシーに関するデータを読み込む。 |
|
ポリシーをポリシー ストアで管理する。 |
|
セキュリティ ロールを作成、編集、および削除する。 |
|
セキュリティ ロールに関するデータを読み込む。 |
|
ロールに関するデータをリストする。 |
表 3-5 資格マッピング用任意 SSPI MBean
任意 SSPI MBean | 用途 |
---|---|
|
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを編集する。 |
|
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを読み込む。 |
|
WebLogic ユーザをリモートのユーザ名およびパスワードにマップする資格マップを読み込む。 |
一部の WebLogic セキュリティ プロバイダは、セキュリティ データの移行をサポートするように開発されています。つまり、(WebLogic 認証プロバイダの) ユーザとグループ、(WebLogic 認可プロバイダの) セキュリティ ポリシー、(WebLogic ロール マッピング プロバイダの) セキュリティ ロール、または (WebLogic 資格マッピング プロバイダの) 資格マップを、セキュリティ レルムからエクスポートして別のセキュリティ レルムにインポートできます。管理者は、これらの WebLogic セキュリティ プロバイダのセキュリティ データを個別に移行したり、すべての WebLogic セキュリティ プロバイダのセキュリティ データ (セキュリティ レルム全体のセキュリティ データ) を一度に移行したりできます。
管理者にとって、セキュリティ データの移行は次のような場合に有用です。
開発モードからプロダクション モードへ移行する。
プロダクション モードのセキュリティ コンフィグレーションを新しい WebLogic Server ドメインのセキュリティ レルムに拡散する。
同じ WebLogic ドメインまたは別の WebLogic ドメインの新しいセキュリティ レルムにデータを移動する。
同じ WebLogic Server ドメイン内のあるセキュリティ レルムから新しいセキュリティ レルムにデータを移動する (新しいセキュリティ レルムで、1 つまたは複数の WebLogic セキュリティ プロバイダがカスタム セキュリティ プロバイダに置き換えられる場合)。この場合、管理者は、置き換えの対象とならないセキュリティ プロバイダのセキュリティ データをコピーする必要があります。
以下の節では、セキュリティ データの移行の詳細について説明します。
セキュリティ データを移行する前に、以下の概念を理解しておく必要があります。
フォーマットとは単に、セキュリティ データのエクスポートまたはインポート方法を指定するデータ フォーマットです。現在、WebLogic Server はセキュリティ プロバイダの開発者に、標準の公開されたフォーマットを提供していません。このため、フォーマットは任意に選択できますが、あるセキュリティ プロバイダから別のセキュリティ プロバイダにデータをエクスポートおよびインポートするには、両方のセキュリティ プロバイダが同じフォーマットの処理方法を理解している必要があります。サポートされるフォーマットは、特定のセキュリティ プロバイダが処理方法を理解しているデータ フォーマットのリストです。
注意 : WebLogic セキュリティ プロバイダで使用されるデータ フォーマットは非公開であるため、現時点では、WebLogic セキュリティ プロバイダとカスタム セキュリティ プロバイダの間でセキュリティ データを移行することはできません。また、別のベンダのセキュリティ プロバイダとセキュリティ データを交換するには、セキュリティ ベンダがそのための標準フォーマットに従って連携する必要があります。 |
制約は、エクスポートまたはインポート処理のオプションの指定に使用されるキーと値の組み合わせです。制約を使用すると、セキュリティ プロバイダのデータベースからエクスポートまたはインポートするセキュリティ データを管理者が制御できます。たとえば、管理者は、認証プロバイダのデータベースから、グループではなくユーザまたはユーザのサブセットだけをエクスポートすることができます。サポートされる制約は、特定のセキュリティ プロバイダの移行処理で管理者が指定できる制約のリストです。たとえば、認証プロバイダのデータベースを使用して、ユーザとグループをインポートできますが、セキュリティ ポリシーはインポートできません。
エクスポート ファイルは、移行処理のエクスポートの段階で、セキュリティ データを (指定されたフォーマットで) 書き込むファイルです。インポート ファイルは、移行処理のインポートの段階で、セキュリティ データを (指定されたフォーマットで) 読み込むファイルです。エクスポート ファイルとインポート ファイルのどちらも、あるセキュリティ プロバイダのデータベースから別の場所に移行する際の、セキュリティ データの一時的な格納場所です。
警告 : 移行ファイルは、保護措置を取らない限り保護されません。移行ファイルには重要なデータが入っているので、扱いには十分な注意が必要です。 |
WebLogic セキュリティ プロバイダのようにセキュリティ データの移行をサポートするカスタム セキュリティ プロバイダを開発する場合、そのプロバイダの MBean タイプを生成するための MBean 定義ファイル (MDF) で weblogic.management.security.ImportMBean
および weblogic.management.security.ExportMBean
任意 SSPI MBean を拡張してから、そのメソッドを実装する必要があります。これらの任意 SSPI MBean には、表 3-6 および 表 3-7 に示されている属性と操作が含まれています。
表 3-6 ExportMBean 任意 SSPI MBean の属性と操作
属性/操作 | 説明 |
---|---|
|
セキュリティ プロバイダがサポートしているエクスポート データ フォーマットのリスト。 |
|
セキュリティ プロバイダがサポートしているエクスポート制約のリスト。 |
|
プロバイダ固有のセキュリティ データを指定されたフォーマットでエクスポートする。 |
|
プロバイダ固有のデータをエクスポートするフォーマットを指定する |
|
プロバイダ固有のデータをエクスポートするためのファイルの絶対パスを指定する 注意 : セキュリティ データの移行をサポートする WebLogic セキュリティ プロバイダは、(作業対象のサーバを基準とする) 相対パスでも指定できるように実装されている。すでに存在しているディレクトリを指定する必要がある。ディレクトリは WebLogic Server によって作成されない。 |
|
プロバイダ固有のデータをエクスポートする場合の制約を指定する |
表 3-7 ImportMBean 任意 SSPI MBean の属性と操作
属性/操作 | 説明 |
---|---|
|
セキュリティ プロバイダがサポートしているインポート データ フォーマットのリスト。 |
|
セキュリティ プロバイダがサポートしているインポート制約のリスト。 |
|
プロバイダ固有のデータを指定されたフォーマットでインポートする。 |
|
プロバイダ固有のデータをインポートするフォーマットを指定する |
|
プロバイダ固有のデータをインポートするためのファイル名の絶対パスを指定する 注意 : セキュリティ データの移行をサポートする WebLogic セキュリティ プロバイダは、(作業対象のサーバを基準とする) 相対パスでも指定できるように実装されている。すでに存在しているディレクトリを指定する必要がある。ディレクトリは WebLogic Server によって作成されない。 |
|
プロバイダ固有のデータをインポートする場合の制約を指定する |
カスタム セキュリティ プロバイダの MDF で拡張可能な他の任意 SSPI MBean と違い、ExportMBean
および ImportMBean
任意 SSPI MBean から継承した属性および操作は、関連付けられているセキュリティ プロバイダの WebLogic Server Administration Console ページの [移行] タブに自動的に表示されます (図 3-8 を参照)。これにより、管理者は各セキュリティ プロバイダのセキュリティ データを個別にエクスポートおよびインポートすることができます。
注意 : セキュリティ プロバイダが移行機能を持っていない場合、そのセキュリティ プロバイダの [移行] タブは Administration Console に表示されません。Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「セキュリティ データの移行」を参照してください。 |
また、セキュリティ レルムに移行機能を持つセキュリティ プロバイダがコンフィグレーションされている場合、管理者はセキュリティ レルム レベルの [移行] タブ (図 3-9 を参照) を使用して、セキュリティ レルムにあるすべてのセキュリティ プロバイダのセキュリティ データを一度にエクスポートまたはインポートできます。
注意 : セキュリティ レルム レベルの [移行] タブは、移行機能を持つセキュリティ プロバイダがセキュリティ レルムでコンフィグレーションされているかどうかにかかわらず、Administration Console に常に表示されます。ただし、[移行] タブが機能するのは、1 つまたは複数のセキュリティ プロバイダが移行機能を持っている場合だけです。Administration Console を使用して個々のセキュリティ プロバイダのセキュリティ データを移行する手順については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「セキュリティ データの移行」を参照してください。 |
注意 : また、管理者は、ExportMBean および ImportMBean 任意 SSPI MBean を拡張する場合、Administration Console ではなく WebLogic Scripting Tool (WLST) を使用してセキュリティ データを移行することができます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』を参照してください。 |
MDF に属性または操作を追加する場合、Administration Console で使用できるように、やはりコンソール拡張を記述する必要があります。
weblogic.management.utils
パッケージには、開発者にとって特にカスタム セキュリティ プロバイダの MBean タイプを生成する際に役立つ、補足的な管理インタフェースと例外が含まれています。カスタム セキュリティ プロバイダを開発する際に、これらのインタフェースと例外を実装する必要はありません (カスタム セキュリティ プロバイダの MDF で任意 SSPI MBean を実装してこれらを継承する場合を除く)。
注意 : このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティ MBean にも使用できるものなので、weblogic.management.security ではなくこのパッケージに入っています。さまざまな種類の MBean については、『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。 |
weblogic.management.utils
パッケージには、以下のユーティリティが含まれています。
一般例外
大きなデータ リストを扱うためのメソッドを提供するインタフェース
外部 LDAP サーバと通信するために必要なコンフィグレーション属性を含むインタフェース
注意 : Manageable Sample Authentication は、データ リストを扱うためだけでなく、例外用にもweblogic.management.utils パッケージを使用します。 |
詳細については、『WebLogic Server API リファレンス Javado』 の「weblogic.management.utils」パッケージを参照してください。
WebLogic リソースは、権限のないアクセスから保護することができる WebLogic Server エンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロールマッピング プロバイダ、および資格マッピング プロバイダの開発者は、これらのセキュリティ プロバイダが、WebLogic リソースおよびそれらのリソースのセキュリティに使用されるセキュリティ ポリシーとどのように対話するかを理解しておく必要があります。
注意 : セキュリティ ポリシーは、以前のリリースの WebLogic Server で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) とパーミッションに代わるものです。 |
以下の節では、セキュリティ プロバイダと WebLogic リソースについて説明します。
weblogic.security.spi
パッケージに定義されている Resource
インタフェースは、権限のないアクセスから保護できる WebLogic リソースを表すオブジェクトを定義します。weblogic.security.service
パッケージに定義されている ResourceBase
クラスは、より詳細な WebLogic リソース タイプの抽象基底クラスで、リソースを拡張するためのモデルです (詳細については、図 3-10 と「WebLogic リソースのタイプ」を参照)。
ResourceBase
クラスには、Oracle が提供する getID
、getKeys
、getValues
、および toString
メソッドの実装が含まれています。詳細については、『WebLogic Server API リファレンス Javadoc』の「ResourceBase クラス」を参照してください。
このアーキテクチャにより、特定の WebLogic リソースを意識することなくセキュリティ プロバイダを開発できます。このため、新しいリソース タイプが追加されても、セキュリティ プロバイダを修正する必要がありません。
図 3-10 「WebLogic リソースのアーキテクチャ」に示したように、weblogic.security.service
パッケージの特定のクラスは ResourceBase
クラスの拡張であるため、WebLogic リソースの特定のタイプの実装を提供します。以下の WebLogic リソースの実装を使用できます。
管理リソース
アプリケーション リソース
COM リソース
コントロール リソース
EIS リソース
EJB リソース
JDBC リソース
JMS リソース
JNDI リソース
リモート リソース
サーバ リソース
URL リソース
Web サービス リソース
ワーク コンテキスト リソース
注意 : これらの各 WebLogic リソースの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』および『WebLogic Server API リファレンス Javadoc』の「weblogic.security.service」パッケージを参照してください。 |
各 WebLogic リソース (「WebLogic リソースのタイプ」を参照) は、その toString()
表現か、または getID()
メソッドを使用して取得した ID によって識別できます。
WebLogic リソースの実装の toString()
メソッドを使用すると、その WebLogic リソースの説明が String
形式で返されます。最初に、WebLogic リソースのタイプが不等号括弧内に出力されます。次に、各キーとその値が順番に出力されます。これらのキーはカンマで区切られます。示される値はカンマで区切られ、中括弧で囲まれます。各値はそのまま出力されますが、カンマ (,)、開き中括弧 ({)、閉じ中括弧 (})、およびバック スラッシュ (\) はそれぞれバック スラッシュでエスケープされます。たとえば、次のような EJB リソースがあるとします。
EJBResource ('myApp", 'MyJarFile", 'myEJB", 'myMethod", 'Home", new String[] {'argumentType1", 'argumentType2"} );
このリソースは、以下の toString
出力を生成します。
type=<ejb>, app=myApp, module="MyJarFile", ejb=myEJB, method="myMethod", methodInterface="Home", methodParams={argumentType1, argumentType2}
toString()
メソッドによって提供される WebLogic リソース記述の形式は公開されており (つまり Resource
オブジェクトを使用せずに記述を作成でき)、逆変換できます (つまりこの String
形式を元の WebLogic リソースに戻せます)。
定義済みの各 WebLogic リソース タイプに定義されている getID()
メソッドは、セキュリティ プロバイダで WebLogic リソースをユニークに識別するために使用できる 64 ビット ハッシュコードを返します。リソース ID は、以下のアルゴリズムを使用して、高速の実行時キャッシングに効果的に使用できます。
WebLogic リソースを取得します。
getID
メソッドを使用して WebLogic リソースのリソース ID を取得します。
キャッシュ内でそのリソース ID をルックアップします。
リソース ID が見つかれば、それに対応するセキュリティ ポリシーを返します。
リソース ID が見つからなければ、以下を実行します。
toString()
メソッドを使用して、セキュリティ プロバイダ データベース内で WebLogic リソースをルックアップします。
リソース ID とセキュリティ ポリシーをキャッシュに格納します。
セキュリティ ポリシーを返します。
このメソッドは何度実行しても同じ値を返すという保証はないので、このリソース ID を使用してセキュリティ プロバイダ データベースに WebLogic リソースに関する情報を格納しないようにしてください。代わりに、WebLogic リソースの toString()
メソッドを使用して、リソース対セキュリティ ポリシーおよびリソース対セキュリティ ロール マッピングを、対応するセキュリティ プロバイダ データベースに格納するようにします。
注意 : セキュリティ プロバイダ データベースの詳細については、「セキュリティ プロバイダ データベースの初期化」を参照してください。toString メソッドの詳細については、「toString() メソッド」を参照してください。 |
カスタム認証プロバイダの実行時クラスを記述する場合は、デフォルト グループをいくつか作成しておく必要があります。表 3-8 は、このタスクを行う場合に役立つ情報を示しています。
カスタム ロール マッピング プロバイダの実行時クラスを記述する場合は、デフォルト グローバル ロールをいくつか作成しておく必要があります。表 3-9 は、このタスクを行う場合に役立つ情報を示しています。
表 3-9 デフォルト グローバル ロールとグループの関連付け
グローバル ロール名 | グループの関連付け |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意 : グローバルおよびスコープ指定セキュリティ ロールの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。 |
カスタム認可プロバイダの実行時クラスを記述する場合は、デフォルト セキュリティ ポリシーをいくつか作成しておく必要があります。これらのデフォルト セキュリティ ポリシーで、初期状態からさまざまなタイプの WebLogic リソースを保護します。表 3-10 は、このタスクを行う場合に役立つ情報を示しています。
表 3-10 WebLogic リソースのデフォルト セキュリティ ポリシー
WebLogic リソース コンストラクタ | セキュリティ ポリシー |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意 : アプリケーションおよび COM リソースにはデフォルト セキュリティ ポリシーを設定しないでください (つまり、デフォルトですべてのユーザにパーミッションを付与しないでください)。 |
コード リスト 3-2 に、認可プロバイダの実行時クラスで WebLogic リソースをルックアップする方法について示します。このアルゴリズムは、認可プロバイダのセキュリティ プロバイダ データベースに WebLogic リソースとセキュリティ ポリシーのマッピングが格納されていることを前提にしています。コード リスト 3-2 に示すアルゴリズムの使用、つまり getParentResource
メソッドの呼び出しの使用は必須ではありません (getParentResource
メソッドの詳細については、「単一親リソース階層」を参照)。
コード リスト 3-2 認可プロバイダで WebLogic リソースをルックアップする方法 : toString メソッドの使用
Policy findPolicy(Resource resource) { Resource myResource = resource; while (myResource != null) { String resourceText = myResource.toString(); Policy policy = lookupInDB(resourceText); if (policy != null) return policy; myResource = myResource.getParentResource(); } return null; }
getID
メソッドを使用することで、WebLogic リソースのルックアップ アルゴリズムを最適化できます (コード リスト 3-2 に示したように toString
メソッドだけを使用すると、文字列が頻繁に連結されるためパフォーマンスが低下する場合があります)。getID
メソッドは WebLogic リソース自身の内部で計算されキャッシュされるハッシュ処理なのでより高速で効率的です。このため、getID
メソッドを使用すると、toString
値の計算リソースにつき一度だけで済みます (コード リスト 3-3 を参照)。
コード リスト 3-3 認可プロバイダで WebLogic リソースをルックアップする方法 : getID メソッドの使用
Policy findPolicy(Resource resource) { Resource myResource = resource; while (myResource != null) { long id = myResource.getID(); Policy policy = lookupInCache(id); if (policy != null) return policy; String resourceText = myResource.toString(); Policy policy = lookupInDB(resourceText); if (policy != null) { addToCache(id, policy); return policy; } myResource = myResource.getParentResource(); } return null; }
注意 : getID メソッドは、サービス パック間または将来の WebLogic Server リリース間で保証されません。このため、getID 値はセキュリティ プロバイダ データベースに格納しないでください。 |
WebLogic リソースの粒度は自由に設定できます。たとえば、Web アプリケーション全体、その Web アプリケーション内の特定のエンタープライズ JavaBean (EJB)、あるいはその EJB 内の単一のメソッドを WebLogic リソースと見なすことができます。
WebLogic リソースは、特殊性が最も高いものから最も低いものまでの階層構造に整理されます。各 WebLogic リソース タイプでは、getParentResource
メソッドを使用できます (必須ではありません)。
WebLogic セキュリティ プロバイダは、次のように単一親リソース階層を使用します。WebLogic セキュリティ プロバイダが特定の WebLogic リソースにアクセスしようとして、そのリソースが見つからない場合、WebLogic セキュリティ プロバイダはそのリソースの getParentResource
メソッドを呼び出します。このメソッドによって現在の WebLogic リソースの親リソースが返され、WebLogic セキュリティ プロバイダはリソース階層を上って次の (特殊性のより低い) リソースを保護できるようになります。たとえば、呼び出し側が以下の URL リソースにアクセスしようとしたとします。
type=<url>, application=myApp, contextPath="/mywebapp", uri=foo/bar/my.jsp
この URL リソースが見つからない場合、WebLogic セキュリティ プロバイダは以下のリソースを検索して保護しようとします。順序は以下のとおりです。
type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/bar/* type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/* type=<url>, application=myApp, contextPath="/mywebapp", uri=*.jsp type=<url>, application=myApp, contextPath="/mywebapp", uri=/* type=<url>, application=myApp, contextPath="/mywebapp" type=<url>, application=myApp type=<app>, application=myApp type=<url>
注意 : getParentResource メソッドの詳細については、「WebLogic Server API リファレンス Javadoc」で定義済みの WebLogic リソース タイプのいずれかまたは「Resource インタフェース」を参照してください。 |
Java サーブレット 2.3 仕様の SRV.11.1 および SRV.11.2 節では、(http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html
) サーブレット コンテナのパターン マッチングのルールが説明されています。これらのルールは、URL リソースに対しても使用されます。以下の例では、URL リソースのパターン マッチングに関するいくつかの重要な概念を示します。
URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET
の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、3 行目と 4 行目に注意)。
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*, httpMethod=GET
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*, httpMethod=GET
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*
type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp, httpMethod=GET
type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp
type=<url>, application=myApp, contextPath=/mywebapp, uri=/*, httpMethod=GET
type=<url>, application=myApp, contextPath=/mywebapp, uri=/*
type=<url>, application=myApp, contextPath=/mywebapptype=<url>, application=myApp
type=<app>, application=myApp
type=<url>
URL リソース type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo
の場合、リソース階層は次のように使用されます (予想と異なっている可能性がある URL パターンが含まれる、2 行目に注意)。
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo
type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*
type=<url>, application=myApp, contextPath=/mywebapp, uri=/*
type=<url>, application=myApp, contextPath=/mywebapp
type=<url>, application=myApp
type=<app>, application=myApp
type=<url>
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler
インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement
オブジェクトによって表されます。
注意 : ContextHandler インタフェースおよび ContextElement クラスの詳細については、『WebLogic Server API リファレンス Javadoc』の「weblogic.security.service」パッケージを参照してください。 |
リソース タイプにはさまざまなコンテキスト要素があり、その値をカスタム プロバイダ開発の一部として検査できます。つまり、すべてのコンテナがすべてのコンテキスト要素を渡すとは限らないことになります。
表 3-11 に、利用できる ContextHandler
エントリの一覧を示します。
表 3-11 コンテキスト ハンドラのエントリ
コンテキスト要素名 | 説明とタイプ |
---|---|
|
HTTP によるサーブレット アクセス要求または SOAP メッセージ。
|
|
HTTP によるサーブレット アクセス応答または SOAP メッセージ。
|
|
WebLogic Integration メッセージ。メッセージは監査ログに送られる。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの内部リスン ポート。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの外部リスン ポート。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの TCP/IP 接続のリモート エンドのポート。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの要求を行うためのプロトコル。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの内部リスン アドレス。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの外部リスン アドレス。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの TCP/IP 接続のリモート アドレス。
|
|
要求の受け付けまたは処理を行うネットワーク チャネルの名前。
|
|
SSL による要求の受け付けまたは処理を行うネットワーク チャネルかどうかを示す。
|
|
パラメータに基づくオブジェクト。 |
|
|
|
WebLogic Server 内部プロセスによって使用される。
|
|
SSL フレームワークが証明書チェーンを検証した。つまり、チェーン内の証明書が相互に適切に署名しており、チェーンが終了する証明書がサーバの信頼性のある CA の 1 つであり、チェーンが基本制約ルールに準拠していて、チェーン内の証明書が期限切れではなかった。
|
|
このリリースの WebLogic Server では使用されない。
|
|
このリリースの WebLogic Server では使用されない。
|
|
|
|
SSL クライアント証明書チェーンが SSL 接続から取得され、sender-vouches SAML アサーションが受信された。
|
|
Web サービス メッセージに署名するための証明書。
|
|
SAML アサーションのタイプ (bearer、artifact、sender-vouches、holder-of-key)。
|
|
holder-of-key SAML アサーションでのサブジェクト確認のために使用される
|
コード リスト 3-4 では、URL (Web) リソースの ContextHandler を介して、HttpServletRequest
および HttpServletResponse
コンテキスト要素オブジェクトにアクセスする方法を示します。このコードはたとえば、AccessDecision
SSPI 実装の isAccessAllowed()
メソッドで使用できます (詳細については、「AccessDecision SSPI の実装」を参照)。
コード リスト 3-4 例 : URL リソース ContextHandler でのコンテキスト要素へのアクセス
static final String SERVLETREQUESTNAME = 'com.bea.contextelement.servlet.HttpServletRequest"; if (resource instanceof URLResource) { HttpServletRequest req = (HttpServletRequest)handler.getValue(SERVLETREQUESTNAME); }
注意 : RoleMapper SSPI 実装の getRoles() メソッドや、AuditContext インタフェース実装の getContext() メソッドでこれらのコンテキスト要素にアクセスすることもできます。(詳細については、それぞれ「RoleMapper SSPI の実装」と「監査コンテキスト」を参照してください)。 |
ContextHandler インタフェースを使用すると、WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダまたはインタフェースで、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。
表 3-12 に、コンテキスト ハンドラのサポートについて示します。
表 3-12 コンテキスト ハンドラがサポートされるメソッドとクラス
メソッド | 説明 |
---|---|
|
|
|
AdjudicatorV2 SSPI インタフェースの実装は裁決プロバイダの一部であり、すべてのアクセス決定の |
|
JAAS |
|
|
|
|
|
|
|
getContext メソッドは必要に応じて ContextHandler オブジェクトを取得でき、ContextHandler オブジェクトによって資格マッピングの監査イベントに関する付加的なデータが指定される。 |
|
|
|
|
|
|
|
IdentityAsserterV2 プロバイダを使用するとセキュリティ フレームワークで assertIdentity メソッドに ContextHandler を渡すことが可能。ContextHandler オブジェクトは必要に応じて、ID アサーションで使用する付加的な情報の取得に使用できる。ContextHandler を使用すると、たとえばユーザが HttpServletRequest から特別な情報を抽出したり、HttpServletResponse にクッキーを設定したりできるようになる。 |
|
ContextHandler は JAAS EJB およびサーブレット コンテナでは、Principal Authenticator を呼び出す際に CallbackHandler へ ContextHandler を追加する必要がある。具体的には、 |
|
|
|
WebLogic Server バージョン 9.0 以降では、
|
注意 : この節を読む前に、『Oracle Fusion Middleware Oracle WebLogic Server Security の紹介』の「セキュリティ プロバイダ データベース」に目を通しておいてください。 |
セキュリティ プロバイダ データベースは、少なくとも、認証、認可、ロール マッピング、および資格マッピングの各プロバイダで必要なデフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、または資格で初期化する必要があります。所定のセキュリティ プロバイダのデータベースを初期化してからでないと、セキュリティ プロバイダは使えるようになりません。また、カスタム セキュリティ プロバイダの実行時クラスを記述する際に、データベースの機能を考慮する必要があります。セキュリティ プロバイダのデータベースの初期化に使用する方法は、ユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、または資格情報の格納に外部管理のデータベースを使用するかどうか、およびデータベースがすでに存在するのか作成する必要があるのかなど、多くの要因に左右されます。
以下の節では、セキュリティ プロバイダ データベースを初期化するためのベスト プラクティスについて説明します。
認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、または資格マッピング プロバイダは、それが初めて使用されるときには、セキュリティ サービスを提供するために必要な情報のあるデータベースを見つけようとします。セキュリティ プロバイダがデータベースを見つけられない場合は、セキュリティ プロバイダにデータベースを作成させて、デフォルトのユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格を自動的に格納することができます。このオプションは、開発およびテストに便利です。
WebLogic セキュリティ プロバイダとサンプル セキュリティ プロバイダは両方ともこのプラクティスに従います。WebLogic の認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、ユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報を組み込み LDAP サーバに格納します。これらの WebLogic セキュリティ プロバイダのいずれかを使用する場合は、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「組み込み LDAP サーバのコンフィグレーション」で説明されている指示に従う必要があります。
注意 : サンプル セキュリティ プロバイダは、プロパティ ファイルを作成し、それらのデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザおよびグループについての必要な情報が格納されるSampleAuthenticatorDatabase.java というファイルが作成されます。 |
外部 LDAP サーバなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダが必要とするユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。
データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ プロバイダをコンフィグレーションする必要があります。そのためには、セキュリティ プロバイダの MBean 定義ファイル (MDF) でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMaker を通じて MDF を実行し、さらにいくつかの手順を行ってカスタム セキュリティ プロバイダの MBean タイプを生成したら、WebLogic Server Administration Console を使用してそれらの属性がデータベースを指すように設定します。
注意 : MDF、MBean タイプ、および WebLogic MBeanMaker の詳細については、「カスタム セキュリティ プロバイダをコンフィグレーションおよび管理する MBean タイプの生成」を参照してください。 |
コード リスト 3-5 に、WebLogic LDAP 認証プロバイダの MDF に属する一部のカスタム属性を例として示します。これらの属性を使用することにより、WebLogic LDAP 認証プロバイダのデータベース (外部 LDAP サーバ) についての情報を指定することができるので、プロバイダでユーザおよびグループについての情報を見つけることができます。
コード リスト 3-5 LDAPAuthenticator.xml
... <MBeanAttribute Name = "UserObjectClass" Type = "java.lang.String" Default = ""person"" Description = "The LDAP object class that stores users." /> <MBeanAttribute Name = "UserNameAttribute" Type = "java.lang.String" Default = ""uid"" Description = "The attribute of an LDAP user object that specifies the name of the user." /> <MBeanAttribute Name = "UserDynamicGroupDNAttribute" Type = "java.lang.String" Description = "The attribute of an LDAP user object that specifies the distinguished names (DNs) of dynamic groups to which this user belongs. この属性が指定されていない場合、WebLogic Server は、動的グループの URL を評価することでユーザがグループのメンバーかどうかを判定します。 If a group contains other groups, WebLogic Server evaluates the URLs on any of the descendents of the group." /> <MBeanAttribute Name = "UserBaseDN" Type = "java.lang.String" Default = ""ou=people, o=example.com"" Description = "The base distinguished name (DN) of the tree in the LDAP directory that contains users." /> <MBeanAttribute Name = "UserSearchScope" Type = "java.lang.String" Default = ""subtree"" LegalValues = "subtree,onelevel" Description = "Specifies how deep in the LDAP directory tree to search for Users. Valid values are <code>subtree</code> and <code>onelevel</code>." /> ...
可能な限り、セキュリティ プロバイダとセキュリティ プロバイダ データベースの間の初期化呼び出しは、データベース デリゲータという中間クラスを介して行う必要があります。データベース デリゲータは、図 3-11 で示されているようにセキュリティ プロバイダの実行時クラスおよび MBean タイプと対話する必要があります。
データベース デリゲータは、WebLogic の認証プロバイダと資格マッピング プロバイダで使用されます。たとえば、WebLogic 認証プロバイダはデータベース デリゲータに働きかけてデフォルトのユーザおよびグループで組み込み LDAP サーバを初期化します。デフォルトのユーザおよびグループは、デフォルト セキュリティ レルムの認証サービスを提供するために必要な情報です。
カスタム セキュリティ プロバイダを開発するアプリケーション開発者およびセキュリティ ベンダは、データベース デリゲータを使用することをお勧めします。データベース デリゲータを使用すると、セキュリティ プロバイダのデータベースが隠蔽され、データベースへの呼び出しが一元化されるメリットがあります。
バリデータは、さまざまな種類の式を検証できるクラスによって実装されるインタフェースです。このリリースの WebLogic Server では、セキュリティ プロバイダの属性バリデータ メソッドの継承ルールが、8.1 のルールとは異なっています。
8.1 で属性バリデータを有効にする場合、派生した MBean は、MBean 実装ファイルでその属性バリデータのメソッドをカスタマイズするだけで済みました。バージョン 9.0 以降で属性バリデータを有効にする場合、派生した MBean は、メソッドをカスタマイズするだけでなく、MDF ファイルでその属性バリデータを明示的に宣言する必要もあります。明示的に宣言しなかった場合、カスタマイズされたメソッドのコードは無視されます。
以下の例では、すべての ID アサーション MBean 実装の基本クラス weblogic.management.security.authentication.IdentityAsserterImpl
を示します。
IdentityAsserterImpl は、認証プロバイダ MBean 実装を拡張し、認証プロバイダの MBean 実装がコンフィグレーション属性にアクセスできるようにします。
8.1 では、次の手順で可能になります。
IdentityAsserter1 という ID アサーション プロバイダを作成します。MDF ファイルで、このプロバイダが weblogic.management.security.authentication.IdentityAsserter
を拡張するように指定します。
WebLogic MBeanMaker を使用して MBean タイプの生成MBeanMaker で生成された実装ファイルは通常、IdentityAsserter1Impl.java
という名前になります。これは、weblogic.management.security.authentication.IdentityAsserterImpl
を拡張します。
そのため、MBean は、属性バリデータ メソッドを持つ activeTypes
属性を継承します。validateActiveTypes(String[] activeTypes)
メソッドにより、サポートされているタイプのみが activeTypes
に含まれます。
実装ファイルを変更し、validateActiveTypes
メソッドの別の実装を指定します。たとえば、アクティブなタイプをさらに制限したり、ルールを緩めたりすることができます。
8.1 では、IdentityAsserter1 の validateActiveTypes
実装が使用されます。
バージョン 9.0 以降では、基本 IdentityAsserter の validateActiveTypes
実装が代わりに使用されます。つまり、IdentityAsserter1 の validateActiveTypes
実装は、通知なしで無視されます。
バージョン 9.0 以降でのこの違いに対処するには、IdentityAsserter1 の MDF ファイルの MBeanOperation サブ要素で属性バリデータを再宣言します。