2 設計上の考慮事項
この章の内容は次のとおりです。
セキュリティ・プロバイダの一般的なアーキテクチャ
作成できるセキュリティ・プロバイダには様々なタイプがありますが(『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・プロバイダのタイプに関する項を参照)、それらのプロバイダはすべて同じ一般的なアーキテクチャに基づきます。図2-1に、セキュリティ・プロバイダの一般的なアーキテクチャを示します。このアーキテクチャの説明については図の下を参照してください。
ノート:
SSPIおよびSSPIを使用して作成するランタイム・クラス(実装)は両方とも.javaファイルです。図2-1の左側を参照してください。
図2-1の右側のファイルと同様、MyFooMBeanは.xmlファイルとして開始します。このファイルで、SSPI MBeanを拡張(および任意で実装)します。このMBean定義ファイル(MDF)がWebLogic MBeanMakerユーティリティで実行される場合、このユーティリティではMBeanタイプ用の.javaファイルが生成されます。「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください
図2-1は、カスタム・セキュリティ・プロバイダの開発時に作成された1つのランタイム・クラス(MyFooProviderImpl
)とMBeanタイプ(MyFooMBean
)の関係を示しています。プロセスはWebLogic Serverインスタンスの起動時に始まり、WebLogicセキュリティ・フレームワークは以下のことを行います。
-
セキュリティ・レルムでセキュリティ・プロバイダと関連付けられたMBeanタイプを見つけます。
-
MBeanタイプからセキュリティ・プロバイダのランタイム・クラス(2つある場合はProvider SSPIを実装する方のランタイム・クラス)の名前を取得します。
-
セキュリティ・プロバイダが初期化(構成データの読込み)に使用する適切なMBeanインスタンスを渡します。
このため、ランタイム・クラス(1つまたは複数)およびMBeanタイプの両方でセキュリティ・プロバイダと呼ばれるものが形成されます。
セキュリティ・サービス・プロバイダ・インタフェース(SSPI)
「開発プロセスの概要」で説明されているように、カスタム・セキュリティ・プロバイダの開発ではまず最初に多くのセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してランタイム・クラスを作成します。この節では、以下の助けになる情報を提供します。
また、この節では各タイプのセキュリティ・プロバイダでどのSSPIを実装できるのかを示す「SSPIクイック・リファレンス」も提供します。
2つの重要な制限について
セキュリティ・プロバイダは、以下の制限事項に準拠している必要があります。
-
カスタム・セキュリティ・プロバイダのランタイム・クラスの実装には、WebLogicセキュリティ・フレームワークによるセキュリティ・チェックの実行を必要とするコードを含めることはできません。セキュリティ・プロバイダは実際にセキュリティ・チェックを実行し、WebLogicリソースへのアクセス権を付与するWebLogicセキュリティ・フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。
-
セキュリティ・プロバイダの実装内で、ローカル(同じサーバー、クラスタ、またはドメイン内)のJava Platform, Enterprise Edition (Java EE)サービスを使用することはできません。これらの使用を試行することもサポートされていません。たとえば、セキュリティ・プロバイダから現在のドメイン内のEJBを呼び出すことは禁止されています。
他のドメインのJava EEサービスであれば、セキュリティ・プロバイダからアクセスおよび使用できます。
ノート:
カスタム・セキュリティ・プロバイダを記述する場合は、Oracle WebLogic Server Java APIリファレンスに記載されているように、パブリックWebLogicサーバー・クラスのみを使用してください。内部WebLogic ServerまたはWebLogic Securityプロバイダ・クラスを使用または拡張しないでください。予期しない結果が発生する可能性があります。Provider」SSPIの目的について
名前がProviderという接尾辞で終わる各SSPI (たとえばCredentialProvider
)は、セキュリティ・プロバイダのサービスをWebLogicセキュリティ・フレームワークに公開します。これによって、セキュリティ・プロバイダの操作(初期化、開始、停止など)が可能になります。
図2-2,で示されているように、セキュリティ・サービスをWebLogicセキュリティ・フレームワークに公開する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
オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。
詳細は、「バルク認可プロバイダ」、「バルク裁決プロバイダ」および「バルク・ロール・マッピング・プロバイダ」を参照してください。
実装するProviderインタフェースの決定
名前が接頭辞Deployable
で始まり接尾辞Provider
で終わるSSPIの実装(DeployableRoleProviderV2
など)は、「「Provider」SSPIの目的について」で説明されているとおり、カスタム・セキュリティ・プロバイダのサービスをWebLogicセキュリティ・フレームワークに公開します。ただし、それらのSSPIの実装では追加のタスクも実行されます。これらのSSPIはまた、サーブレット・デプロイメント記述子(web.xml
、weblogic.xml
)、EJBデプロイメント記述子(ejb-jar.xml
、weblogic-ejb.jar.xml
)、およびEARデプロイメント記述子(application.xml
、weblogic-application.xml
)をはじめとするデプロイメント記述子におけるセキュリティのサポートを提供します。
認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダには、デプロイ可能バージョンのProvider SSPIがあります。
ノート:
セキュリティ・ポリシー、セキュリティ・ロール、および資格証明を格納するセキュリティ・プロバイダ・データベースが読取り専用の場合、認可、ロール・マッピング、および資格証明マッピングの各セキュリティ・プロバイダ用にデプロイ可能ではないバージョンのSSPIを実装できます。ただし、その場合でも、デプロイメントを処理するセキュリティ・プロバイダのデプロイ可能バージョンを構成する必要があります。
DeployableAuthorizationProviderV2 SSPI
WebアプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってセキュリティ・ポリシーのデプロイをサポートする認可プロバイダでは、AuthorizationProvider
SSPIではなくDeployableAuthorizationProviderV2
SSPIを実装する必要があります。しかし、DeployableAuthorizationProviderV2
SSPIはAuthorizationProvider
SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、認可プロバイダがセキュリティ・ポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの認可プロバイダがDeployableAuthorizationProviderV2
SSPIをサポートする必要があり、サポートされていない場合、WebアプリケーションやEJBをデプロイできなくなります。
ノート:
セキュリティ・ポリシーの詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のセキュリティ・ポリシーを参照してください。
DeployableRoleProviderV2 SSPI
WebアプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってセキュリティ・ロールのデプロイをサポートするロール・マッピング・プロバイダでは、RoleProvider
SSPIではなくDeployableRoleProviderV2
SSPIを実装する必要があります。しかし、DeployableRoleProviderV2
SSPIはRoleProvider
SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、ロール・マッピング・プロバイダがセキュリティ・ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つのロール・マッピング・プロバイダがこのSSPIをサポートする必要があり、サポートされていない場合、WebアプリケーションやEJBをデプロイできなくなります。
ノート:
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
DeployableCredentialProvider SSPI
ノート:
DeployableCredentialProviderインタフェースは、このリリースのWebLogic Serverで非推奨になりました。
リソース・アダプタ(RA)のデプロイメントにかわってセキュリティ・ポリシーのデプロイをサポートする資格証明マッピング・プロバイダでは、CredentialProvider
SSPIではなくDeployableCredentialProvider
SSPIを実装する必要があります。しかし、DeployableCredentialProvider
SSPIはCredentialProvider
SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、リソース・アダプタのデプロイメント作業では、資格証明マッピング・プロバイダが資格証明およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの資格証明マッピング・プロバイダがこのSSPIをサポートする必要があり、サポートされていない場合、リソース・アダプタをデプロイできなくなります。
ノート:
「資格証明マッピングの概念」を参照してください。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。
SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する
図2-3は、資格証明マッピング・プロバイダを使用してすべてのSSPIに共通の継承階層を示すとともに、ランタイム・クラスでどのようにそれらのインタフェースを実装できるのかを示します。この例では、Oracleが提供するSecurityProvider
インタフェースと、CredentialProviderV2
およびCredentialMapperV2
SSPIを使用します。図2-3は、CredentialProviderV2
SSPIおよびCredentialMapperV2
SSPIを実装するMyCredentialMapperProviderImpl
という単一のランタイム・クラスを表しています。
ただし、図2-3 SSPIを実装できる1つの方法のみを示します(単一のランタイム・クラスを作成する方法)。必要に応じて、図2-4で示されているように2つのランタイム・クラスを使用することもできます。2つとは、名前がProvider
で終わるSSPI (CredentialProviderV2
など)の実装のためのランタイム・クラスと、他のSSPI (CredentialMapperV2
SSPIなど)の実装のためのランタイム・クラスです。
2つのランタイム・クラスがある場合、名前がProvider
で終わるSSPIを実装するクラスは他のSSPIを実装するランタイム・クラスを生成するためのファクトリとして機能します。たとえば、図2-4では、MyCredentialMapperProviderImpl
がMyCredentialMapperImpl
を生成するためのファクトリとして機能します。
ノート:
実行時実装クラスを2つにする場合は、セキュリティ・プロバイダのMBeanタイプを生成するときに必ず両方の実行時実装クラスをMBean JARファイル(MJF)に格納する必要があります。「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください。
SSPIクイック・リファレンス
表2-1に、セキュリティ・プロバイダのタイプ(およびそれらのコンポーネント)と、その開発に使用するSSPIおよびその他のインタフェースとの対応を示します。
表2-1 セキュリティ・プロバイダとそのコンポーネント、および対応するSSPI
タイプ/コンポーネント | SSPI/インタフェース |
---|---|
認証プロバイダ |
|
LoginModule (JAAS) |
|
IDアサーション・プロバイダ |
|
IDアサータ |
|
プリンシパル検証プロバイダ |
|
認可 |
|
アクセス決定 |
|
裁決プロバイダ |
|
Adjudicator |
|
ロール・マッピング・プロバイダ |
|
ロール・マッパー |
|
監査プロバイダ |
|
監査チャネル |
|
資格証明マッピング・プロバイダ |
|
資格証明マッパー |
|
証明書パス・プロバイダ |
|
バージョン管理可能なアプリケーションのプロバイダ |
|
ノート:
カスタム・セキュリティ・プロバイダのランタイム・クラスを作成するために使用するSSPIは、Oracle WebLogic Server Java APIリファレンスのweblogic.security.spi.packageにあります。
セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean
「開発プロセスの概要」で説明されているように、カスタム・セキュリティ・プロバイダ開発の2番目のステップでは、カスタム・セキュリティ・プロバイダのMBeanタイプを生成します。この節では、以下の助けになる情報を提供します。
また、この節ではどの必須SSPI MBeanを拡張する必要があるのか、そしてどのオプショナルSSPI MBeanを各タイプのセキュリティ・プロバイダで実装できるのかを示す「SSPI MBeanクイック・リファレンス」も提供します。
MBeanタイプが必要な理由について
カスタム・セキュリティ・プロバイダのランタイム・クラスを作成することに加えて、MBeanタイプを生成することも必要です。MBeanという用語はマネージドBeanの略で、JMX (Java Management eXtensions)で管理可能なリソースを表すJavaオブジェクトのことです。
ノート:
JMXは、標準的な管理アーキテクチャ、APIおよび管理サービスを定義する仕様です。Oracle WebLogic Server JMXによる管理可能アプリケーションの開発のJMXの理解を参照してください。
MBeanタイプは、MBeanのインスタンスのファクトリです。MBeanのインスタンスは、WebLogic Server管理コンソールを使用して作成できます。MBeanのインスタンスが作成されたら、WebLogic Server管理コンソールでそのMBeanインスタンスを使用してカスタム・セキュリティ・プロバイダを構成および管理できます。
ノート:
すべてのMBeanインスタンスは自分の親タイプを認識しているので、MBeanタイプの構成を変更すると、WebLogic Server管理コンソールを使用して作成したすべてのインスタンスの構成も更新されます。(詳細は、「SSPI MBeanの階層と管理コンソールに対する影響について」を参照してください。)
拡張および実装するSSPI MBeanの決定
MBeanタイプを作成するにはSSPI MBeanというMBeanインタフェースを使用します。カスタム・セキュリティ・プロバイダ用のMBeanタイプを作成するのに利用できるSSPI MBeanには、以下の2つのタイプがあります。
-
必須SSPI MBean。セキュリティ・プロバイダをWebLogic Server環境内で構成および管理できるようにするための基本的なメソッドが定義されるので、拡張する必要があります。
-
オプショナルSSPI MBean。セキュリティ・プロバイダを管理するための追加メソッドが定義されるので実装することができます。セキュリティ・プロバイダのタイプが異なれば、利用できるオプショナルSSPI MBeanも異なります。
「SSPI MBeanクイック・リファレンス」を参照してください。
MBean定義ファイル(MDF)の基本的な要素について
MBean定義ファイル(MDF)は、WebLogic MBeanMakerユーティリティで、MBeanタイプを構成するJavaファイルを生成するために使用されるXMLファイルです。すべてのMDFでは、作成済のセキュリティ・プロバイダのタイプに固有の必須SSPI MBeanを拡張する必要があり、オプショナルSSPI MBeanを実装できます。
例2-1に、サンプルのMBean定義ファイル(MDF)を示します。その内容の説明については、リストの下を参照してください。(具体的には、WebLogic資格証明マッピング・プロバイダのMBeanタイプの生成に使用するMDFです。DeployableCredentialProviderインタフェースは、このリリースのWebLogic Serverで非推奨になったので注意してください。
ノート:
MDF要素の構文についての詳細なリファレンスは、「MBean定義ファイル(MDF)要素の構文」に収められています。
例2-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を拡張するものであることを示しています。また、UserPasswordCredentialMapEditor
オプショナルSSPI MBeanを実装することで、追加の管理機能も含んでいます。
<MBeanAttribute>
タブで定義されているProviderClassName
、Description
、およびVersion
の各属性は、セキュリティ・プロバイダの基本的な構成方法を定義するものであり、Provider
という基本必須SSPI MBeanから継承されるものなので、セキュリティ・プロバイダのMBeanタイプを生成するために使用されるどのようなMDFでも必須です(図2-5を参照)。ProviderClassName
属性は特に重要です。ProviderClassName
属性の値は、セキュリティ・プロバイダのランタイム・クラスのJavaファイル名(すなわち、Provider
という文字列で終わる適切なSSPIの実装)です。例2-1で示されているサンプルのランタイム・クラスは、DefaultCredentialMapperProviderImpl.java
です。
例2-1では示されていませんが、<MBeanAttribute>
タグや<MBeanOperation>
タグを使用してMDFに属性や操作を追加できます。ほとんどのカスタム属性は、WebLogic Server管理コンソールのカスタム・セキュリティ・プロバイダの「プロバイダ固有」タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります。
ノート:
サンプル監査プロバイダは、カスタム属性の追加例を提供しています。
カスタム・プロバイダとクラスパス
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操作から例外のスロー
カスタム・プロバイダのMBeanは、JDK例外の型またはweblogic.management.utils
例外の型のみをスローする必要があります。それ以外の場合、JMXクライアントには、例外を受け付ける必要があるコードが含まれていない可能性があります。
-
型付き例外の場合、その型から独自の例外の型を派生させてスローするのではなく、MBeanメソッドのthrow句から正しい型のみをスローする必要があります。
-
ネストされた例外の場合は、JDK例外の型または
weblogic.management.utils
例外のみをスローする必要があります。 -
ランタイム例外の場合は、JDK例外のみをスローするか、JDK例外を介してのみ渡す必要があります。
MBean属性に対して非クリア・テキスト値の指定
「MBeanAttributeサブ要素」に示すように、Encrypted属性を使用すると、MBean属性の値がクリア・テキストとして表示されないように指定できます。たとえば、パスワードの入力を取得したときにMBean属性の値を暗号化する場合などです。以下のコードでは、Encrypted属性の使用例を示します。
<MBeanAttribute Name = "PrivatePassPhrase" Type = "java.lang.String" Encrypted = "true" Default = """" Description = "The Keystore password." />
動的MBean属性の使用
Dynamic MBeanは、管理インタフェースを実行時に定義するMBeanです。たとえば、構成MBeanは、XMLファイルの解析により、公開する属性の名前と型を決定できます。動的とマークされたMBean属性は、サーバーを再起動しなくても変更できます。MBean属性を動的として宣言すると、その値は実行中のサーバーで変更されると自動的に更新されます。セキュリティ・プロバイダ実装が、実行時にinitialize
メソッドに渡されたMBeanオブジェクトから値を読み取ると、プロバイダは最後に更新された値を受け取ります。
詳細は、次を参照してください。
-
セキュリティ・プロバイダ・インタフェースの
initialize
メソッドについては、「Provider SSPIの目的について」を参照してください。 -
動的MBean属性とその指定方法については、「MBeanAttributeサブ要素」を参照してください。
SSPI MBeanの階層と管理コンソールに対する影響について
MBean定義ファイル(MDF)で拡張する必須SSPI MBean (基本SSPI MBeanであるProvider
に至るまで)に指定されている属性と操作はすべて、関連するセキュリティ・プロバイダのWebLogic Server管理コンソール・ページに自動的に表示されます。これらの属性と操作は、カスタム・セキュリティ・プロバイダを構成および管理するために使用します。
ノート:
認証セキュリティ・プロバイダに限っては、MDFで実装されるオプショナルSSPI MBeanで指定された属性と操作もWebLogic Server管理コンソールで自動的にサポートされます。他のタイプのセキュリティ・プロバイダの場合、オプショナルSSPI MBeanから継承された属性/操作をWebLogic Server管理コンソールで使用するには、コンソール拡張機能を記述する必要があります。
図2-5は、WebLogic資格証明マッピングMDFを例に使用してセキュリティ・プロバイダのSSPI MBean階層を示すとともに、どの属性/操作がWebLogic資格証明マッピング・プロバイダのWebLogic Server管理コンソールで表示されるのかを示します。
図2-5で示されているように、DefaultCredentialMapper
MDFのSSPI MBeanの階層を実装することにより、図2-6のページがWebLogic Server管理コンソールで表示されます。DefaultCredentialMapper
MDFの部分的なリストは、例2-1に示してあります。
図2-6 DefaultCredentialMapper WebLogic Server管理コンソール・ページ
![図2-6の説明が続きます 図2-6の説明が続きます](img/con_cm21.gif)
「図2-6 DefaultCredentialMapper WebLogic Server管理コンソール・ページ」の説明
「名前」、「説明」、および「バージョン」の各フィールドは、Provider
という基本必須SSPI MBeanから継承されDefaultCredentialMapper
MDFに指定されている同名の属性から得られたものです。DefaultCredentialMapper
MDF内のDisplayName
属性から「名前」フィールドの値が生成されるほか、Description
とVersion
の各属性からも、それぞれ対応するフィールドの値が生成されることに注意します。なお、「プロバイダ固有」ページの「資格証明マッピング・デプロイメントを有効化」フィールドが表示されているのは、DefaultCredentialMapper
MDFの拡張元であるDeployableCredentialMapper
必須SSPI MBeanにCredentialMappingDeploymentEnabled
属性が定義されているためです。このWebLogic Server管理コンソール・ページには、UserPasswordCredentialMapEditor
オプショナルSSPI MBeanのDefaultCredentialMapper
の実装に対応するフィールドは表示されません。
WebLogic MBeanMakerによって提供されるものについて
WebLogic MBeanMakerは、MBean定義ファイル(MDF)を入力とし、MBeanタイプのファイルを出力するコマンドライン・ユーティリティです。WebLogic MBeanMakerを使用して作成したMDFを実行すると、以下のことが行われます。
-
必須SSPI MBeanから継承された属性(MDFに追加されたカスタム属性も同様)により、WebLogic MBeanMakerによってMBeanタイプの情報ファイルに完全なゲッター/セッター・メソッドが生成されます。(MBean情報ファイルは図2-7には示されていません。)「MBean情報ファイルについて」を参照してください。
必要な開発者のアクション: なし。これらのメソッドでさらなる作業は必要ありません。
-
オプショナルSSPI MBeanから継承された操作により、MBeanの実装ファイルでメソッドが継承されます(メソッドの実装は一から記述しなければなりません)
必要な開発者のアクション: 現時点では、WebLogic MBeanMakerでは継承されたメソッドのメソッド・スタブが生成されません。したがって、適切な実装を提供する必要があります。
-
MDFに追加されたカスタム操作により、WebLogic MBeanMakerがメソッド・スタブを生成します。
必要な開発者のアクション: メソッドの実装を提供する必要があります。ただし、WebLogic MBeanMakerでスタブが生成されるので、Javaメソッドのシグネチャを参照する必要はありません。
これを図2-7に示します。
MBean情報ファイルについて
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 MBeanクイック・リファレンス
カスタム・セキュリティ・プロバイダの開発の一部として実装する必要のあるSSPIのリストに基づいて、拡張する必要のある必須SSPI MBeanを表2-2で特定できます。また、表2-3から表2-5では、セキュリティ・プロバイダを管理するために実装できるオプショナルSSPI MBeanを特定できます。
表2-2 必須SSPI MBean
タイプ | パッケージ名 | 必須SSPI MBean |
---|---|---|
認証プロバイダ |
|
|
IDアサーション・プロバイダ |
|
|
認可プロバイダ |
|
|
裁決プロバイダ |
|
|
ロール・マッピング・プロバイダ |
|
|
監査プロバイダ |
|
|
資格証明マッピング・プロバイダ |
|
|
証明書パス・プロバイダ |
|
|
ノート:
表2-2に示した必須SSPI MBeanは、weblogic.management.security.<Package_Name>
というパッケージに定義されています。
表2-3 認証用オプショナルSSPI MBean
オプショナルSSPI MBean | 用途 |
---|---|
|
グループを作成します。当該グループがすでに存在する場合には、例外がスローされます。 |
|
グループのメンバーを列挙します。 |
|
グループに関するデータを読み込みます。 |
|
グループを削除します。 |
|
あるユーザーまたはグループが所属するグループを列挙します。 |
|
ユーザーを作成、編集、および削除します。 |
|
ユーザーのパスワードを変更します。 |
|
ユーザーに関するデータを読み込みます。 |
|
ユーザーを削除します。 |
表2-4 認可用オプショナルSSPI MBean
オプショナルSSPI MBean | 用途 |
---|---|
|
ポリシーを作成、編集および削除するための補助メソッド。 |
|
プロバイダでポリシーの消費をサポートすることを示します。 |
|
セキュリティ・ポリシーを作成、編集、および削除します。 |
|
ポリシーに関するデータをリストします。 |
|
セキュリティ・ポリシーに関するデータを読み込みます。 |
|
ポリシーをポリシー・ストアで管理します。 |
|
セキュリティ・ロールを作成、編集、および削除します。 |
|
セキュリティ・ロールに関するデータを読み込みます。 |
|
ロールに関するデータをリストします。 |
ノート:
表2-4に示した認可用オプショナルSSPI MBeanは、weblogic.management.security.authorization
パッケージに定義されています。
表2-5 資格証明マッピング用オプショナルSSPI MBean
オプショナルSSPI MBean | 用途 |
---|---|
|
WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを編集します。 |
|
WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを読み込みます。 |
|
WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを読み込みます。 |
ノート:
表2-5に示した資格証明マッピング用オプショナルSSPI MBeanは、weblogic.management.security.credentials
パッケージに定義されています。
セキュリティ・データの移行
一部の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には、表2-6および表2-7に示されている属性と操作が含まれています。
表2-6 ExportMBeanオプショナルSSPI MBeanの属性と操作
属性/操作 | 説明 |
---|---|
|
セキュリティ・プロバイダがサポートしているエクスポート・データ・フォーマットのリスト。 |
|
セキュリティ・プロバイダがサポートしているエクスポート制約のリスト。 |
|
プロバイダ固有のセキュリティ・データを指定されたフォーマットでエクスポートします。 |
|
プロバイダ固有のデータをエクスポートするフォーマットを指定する |
|
プロバイダ固有のデータをエクスポートするためのファイルのフルパスを指定する ノート: セキュリティ・データの移行をサポートするWebLogicセキュリティ・プロバイダは、(作業対象のサーバーを基準とする)相対パスでも指定できるように実装されています。すでに存在しているディレクトリを指定する必要があります。ディレクトリはWebLogic Serverによって作成されません。 |
|
プロバイダ固有のデータをエクスポートする場合の制約を指定する |
ノート:
Oracle WebLogic Server Java APIリファレンスのExportMBeanインタフェースに関する項を参照してください。
表2-7 ImportMBeanオプショナルSSPI MBeanの属性と操作
属性/操作 | 説明 |
---|---|
|
セキュリティ・プロバイダがサポートしているインポート・データ・フォーマットのリスト。 |
|
セキュリティ・プロバイダがサポートしているインポート制約のリスト。 |
|
プロバイダ固有のデータを指定されたフォーマットでインポートします。 |
|
プロバイダ固有のデータをインポートするフォーマットを指定する |
|
プロバイダ固有のデータをインポートするためのファイル名のフルパスを指定する ノート: セキュリティ・データの移行をサポートするWebLogicセキュリティ・プロバイダは、(作業対象のサーバーを基準とする)相対パスでも指定できるように実装されています。すでに存在しているディレクトリを指定する必要があります。ディレクトリはWebLogic Serverによって作成されません。 |
|
プロバイダ固有のデータをインポートする場合の制約を指定する |
ノート:
Oracle WebLogic Server Java APIリファレンスのImportMBeanインタフェースに関する項を参照してください。
セキュリティ・データの移行に関する管理コンソールのサポート
カスタム・セキュリティ・プロバイダのMDFで拡張可能な他のオプショナルSSPI MBeanと違い、ExportMBean
およびImportMBean
オプショナルSSPI MBeanから継承した属性および操作は、関連付けられているセキュリティ・プロバイダのWebLogic Server管理コンソール・ページの「移行」タブに自動的に表示されます(図2-8を参照)。これにより、管理者は各セキュリティ・プロバイダのセキュリティ・データを個別にエクスポートおよびインポートすることができます。
ノート:
セキュリティ・プロバイダが移行機能を持っていない場合、そのセキュリティ・プロバイダの「移行」タブはWebLogic Server管理コンソールに表示されません。
『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・データの移行に関する項を参照してください。
また、セキュリティ・レルムに移行機能を持つセキュリティ・プロバイダが構成されている場合、管理者はセキュリティ・レルム・レベルの「移行」タブ(図2-9を参照)を使用して、セキュリティ・レルムにあるすべてのセキュリティ・プロバイダのセキュリティ・データを一度にエクスポートまたはインポートできます。
ノート:
セキュリティ・レルム・レベルの「移行」タブは、移行機能を持つセキュリティ・プロバイダがセキュリティ・レルムで構成されているかどうかにかかわらず、WebLogic Server管理コンソールに常に表示されます。ただし、「移行」タブが機能するのは、1つまたは複数のセキュリティ・プロバイダが移行機能を持っている場合だけです。
『Oracle WebLogic Serverセキュリティの管理』のセキュリティ・データの移行に関する項を参照してください。
ノート:
オプションのSSPI MBeanであるExportMBeanおよびImportMBeanを拡張する場合は、WebLogic Server管理コンソールではなくWebLogic Scripting Tool (WLST)を使用してセキュリティ・データを移行することもできます。『WebLogic Scripting Toolの理解』を参照してください。
MDFに属性または操作を追加する場合、WebLogic Server管理コンソールで使用できるように、やはりコンソール拡張を記述する必要があります。
セキュリティ・プロバイダの開発者向け管理ユーティリティ
weblogic.management.utils
パッケージには、開発者にとって特にカスタム・セキュリティ・プロバイダのMBeanタイプを生成する際に役立つ、補足的な管理インタフェースと例外が含まれています。カスタム・セキュリティ・プロバイダを開発する際に、これらのインタフェースと例外を実装する必要はありません(カスタム・セキュリティ・プロバイダのMDFでオプショナルSSPI MBeanを実装してこれらを継承する場合を除く)。
ノート:
このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティMBeanにも使用できるものなので、weblogic.management.securityではなくこのパッケージに入っています。様々な種類のMBeanについては、Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のWebLogic ServerサブシステムMBeanの概要を参照してください。
weblogic.management.utils
パッケージには、以下のユーティリティが含まれています。
-
一般例外
-
大きなデータ・リストを扱うためのメソッドを提供するインタフェース
-
外部LDAPサーバーと通信するために必要な構成属性を含むインタフェース
ノート:
Manageable Sample Authenticationは、データ・リストを扱うためだけでなく、例外用にも
weblogic.management.utils
パッケージを使用します。
weblogic.management.utilsパッケージについては、Oracle WebLogic Server Java APIリファレンスを参照してください。
セキュリティ・プロバイダとWebLogicリソース
WebLogicリソースは、権限のないアクセスから保護することができるWebLogic Serverエンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダの開発者は、これらのセキュリティ・プロバイダが、WebLogicリソースおよびそれらのリソースのセキュリティに使用されるセキュリティ・ポリシーとどのように対話するかを理解しておく必要があります。
ノート:
セキュリティ・ポリシーは、以前のリリースのWebLogic ServerでWebLogicリソースを保護するために使用していたアクセス制御リスト(ACL)と権限にかわるものです。
以下の節では、セキュリティ・プロバイダとWebLogicリソースについて説明します。
WebLogicリソースのアーキテクチャ
weblogic.security.spi
パッケージに定義されているResource
インタフェースは、権限のないアクセスから保護できるWebLogicリソースを表すオブジェクトを定義します。weblogic.security.service
パッケージに定義されているResourceBase
クラスは、より詳細なWebLogicリソース・タイプの抽象基底クラスで、リソースを拡張するためのモデルです。(図2-10と「WebLogicリソースのタイプ」を参照してください。)
ResourceBase
クラスには、Oracleが提供するgetID
、getKeys
、getValues
、およびtoString
メソッドの実装が含まれています。WebLogic Server APIリファレンス(Javadoc)のResourceBaseクラスに関する項を参照してください。
このアーキテクチャにより、特定のWebLogicリソースを意識することなくセキュリティ・プロバイダを開発できます。このため、新しいリソース・タイプが追加されても、セキュリティ・プロバイダを修正する必要がありません。
WebLogicリソースのタイプ
図2-10に示したように、weblogic.security.service
パッケージの特定のクラスはResourceBase
クラスの拡張であるため、WebLogicリソースの特定のタイプの実装を提供します。以下のWebLogicリソースの実装を使用できます。
-
管理リソース
-
アプリケーション・リソース
-
COMリソース
-
コントロール・リソース
-
EISリソース
-
EJBリソース
-
JDBCリソース
-
JMSリソース
-
JNDIリソース
-
リモート・リソース
-
サーバー・リソース
-
URLリソース
-
Webサービス・リソース
-
ワーク・コンテキスト・リソース
ノート:
weblogic.security.serviceパッケージについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』およびOracle WebLogic Server Java APIリファレンスを参照してください。
WebLogicリソース識別子
各WebLogicリソース(「WebLogicリソースのタイプ」を参照)は、そのtoString()
表現か、またはgetID()
メソッドを使用して取得したIDによって識別できます。
toString()メソッド
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リソースに戻せます)。
ノート:
例2-2に、toString()メソッドを使用してWebLogicリソースを識別する方法を示します。
リソースIDとgetID()メソッド
定義済みの各WebLogicリソース・タイプに定義されているgetID()
メソッドは、セキュリティ・プロバイダでWebLogicリソースを一意に識別するために使用できる64ビット・ハッシュ・コードを返します。リソースIDは、以下のアルゴリズムを使用して、高速の実行時キャッシングに効果的に使用できます。
-
WebLogicリソースを取得します。
-
getID
メソッドを使用してWebLogicリソースのリソースIDを取得します。 -
キャッシュ内でそのリソースIDをルックアップします。
-
リソースIDが見つかれば、それに対応するセキュリティ・ポリシーを返します。
-
リソースIDが見つからなければ、以下を実行します。
-
toString()
メソッドを使用して、セキュリティ・プロバイダ・データベース内でWebLogicリソースをルックアップします。 -
リソースIDとセキュリティ・ポリシーをキャッシュに格納します。
-
セキュリティ・ポリシーを返します。
ノート:
例2-3に、認可プロバイダで
getID()
メソッドを使用してWebLogicリソースを識別する方法と、そのアルゴリズムの実装例を示します。
-
このメソッドは何度実行しても同じ値を返すという保証はないので、このリソースIDを使用してセキュリティ・プロバイダ・データベースにWebLogicリソースに関する情報を格納しないようにしてください。かわりに、WebLogicリソースのtoString()
メソッドを使用して、リソース対セキュリティ・ポリシーおよびリソース対セキュリティ・ロール・マッピングを、対応するセキュリティ・プロバイダ・データベースに格納するようにします。
ノート:
「セキュリティ・プロバイダ・データベースの初期化」および「toString()メソッド」を参照してください。
WebLogicリソースのデフォルト・グループの作成
カスタム認証プロバイダのランタイム・クラスを記述する場合は、デフォルト・グループをいくつか作成しておく必要があります。表2-8は、このタスクを行う場合に役立つ情報を示しています。
表2-8 デフォルト・グループとグループ・メンバーシップ
グループ名 | グループ・メンバーシップ |
---|---|
|
空、または管理ユーザー |
|
空 |
|
空 |
|
空 |
|
空 |
|
|
WebLogicリソースのデフォルト・セキュリティ・ロールの作成
カスタム・ロール・マッピング・プロバイダのランタイム・クラスを記述する場合は、デフォルト・グローバル・ロールをいくつか作成しておく必要があります。表2-9は、このタスクを行う場合に役立つ情報を示しています。
表2-9 デフォルト・グローバル・ロールとグループの関連付け
グローバル・ロール名 | グループの関連付け |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ノート:
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
WebLogicリソースのデフォルト・セキュリティ・ポリシーの作成
カスタム認可プロバイダのランタイム・クラスを記述する場合は、デフォルト・セキュリティ・ポリシーをいくつか作成しておく必要があります。これらのデフォルト・セキュリティ・ポリシーで、初期状態から様々なタイプのWebLogicリソースを保護します。表2-10は、このタスクを行う場合に役立つ情報を示しています。
表2-10 WebLogicリソースのデフォルト・セキュリティ・ポリシー
WebLogicリソース・コンストラクタ | セキュリティ・ポリシー |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ノート:
アプリケーションおよびCOMリソースにはデフォルト・セキュリティ・ポリシーを設定しないでください(つまり、デフォルトですべてのユーザーに権限を付与しないでください)。
セキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップ
例2-2に、認可プロバイダのランタイム・クラスでWebLogicリソースをルックアップする方法について示します。このアルゴリズムは、認可プロバイダのセキュリティ・プロバイダ・データベースにWebLogicリソースのセキュリティ・ポリシーへのマッピングが格納されていることを前提にしています。例2-2に示すアルゴリズムの使用、つまりgetParentResource
メソッドの呼出しの使用は必須ではありません。(「単一親リソース階層」を参照してください。)
例2-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リソースのルックアップ・アルゴリズムを最適化できます。(例2-2に示したようにtoString
メソッドだけを使用すると、文字列が頻繁に連結されるためパフォーマンスが低下する場合があります。)getID
メソッドはWebLogicリソース自身の内部で計算されキャッシュされるハッシュ処理なのでより高速で効率的です。このため、getID
メソッドを使用すると、toString
値の計算リソースにつき一度だけで済みます(例2-3を参照)。
例2-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アプリケーション内の特定のEnterprise 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>
ノート:
Oracle WebLogic Server Java APIリファレンスの定義済WebLogicリソース・タイプのいずれか、またはResourceインタフェースに関する項を参照してください。
URLリソースのパターン・マッチング
Javaサーブレット2.3仕様のSRV.11.1およびSRV.11.2節では、(http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html
)サーブレット・コンテナのパターン・マッチングのルールが説明されています。これらのルールは、URLリソースに対しても使用されます。以下の例では、URLリソースのパターン・マッチングに関するいくつかの重要な概念を示します。
例1
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>
例2
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クラスです。ContextHandler
インタフェースを使用すると、内部WebLogicリソース・コンテナでWebLogicセキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandlerは本質的には名前と値のリストなので、セキュリティ・プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandlerの使用には、WebLogicリソース・コンテナとセキュリティ・プロバイダの間の緊密な連携が不可欠です。ContextHandlerの名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement
オブジェクトによって表されます。
ノート:
weblogic.security.serviceパッケージについては、Oracle WebLogic Server Java APIリファレンスを参照してください。
リソース・タイプには様々なコンテキスト要素があり、その値をカスタム・プロバイダ開発の一部として検査できます。つまり、すべてのコンテナがすべてのコンテキスト要素を渡すとは限らないことになります。
表2-11に、利用できるContextHandler
エントリの一覧を示します。
表2-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アサーションでのサブジェクト確認のために使用される
|
例2-4では、URL (Web)リソースのContextHandlerを介して、HttpServletRequest
およびHttpServletResponse
コンテキスト要素オブジェクトにアクセスする方法を示します。このコードはたとえば、AccessDecision
SSPI実装のisAccessAllowed()
メソッドで使用できます。(「AccessDecision SSPIの実装」を参照してください。)
例2-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セキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダまたはインタフェースで、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。
表2-12に、コンテキスト・ハンドラのサポートについて示します。
表2-12 コンテキスト・ハンドラがサポートされるメソッドとクラス
メソッド | 説明 |
---|---|
|
|
|
AdjudicatorV2 SSPIインタフェースの実装は裁決プロバイダの一部であり、すべてのアクセス決定の |
|
JAAS |
|
|
|
|
|
|
|
getContextメソッドは必要に応じてContextHandlerオブジェクトを取得でき、ContextHandlerオブジェクトによって資格証明マッピングの監査イベントに関する付加的なデータが指定されます。 |
|
|
|
|
|
|
|
IdentityAsserterV2プロバイダを使用するとセキュリティ・フレームワークでassertIdentityメソッドにContextHandlerを渡すことが可能になります。ContextHandlerオブジェクトは必要に応じて、IDアサーションで使用する付加的な情報の取得に使用できます。ContextHandlerを使用すると、たとえばユーザーがHttpServletRequestから特別な情報を抽出したり、HttpServletResponseにCookieを設定したりできるようになります。 |
|
ContextHandlerはJAAS EJBおよびサーブレット・コンテナでは、Principal Authenticatorを呼び出す際にCallbackHandlerへContextHandlerを追加する必要があります。具体的には、 |
|
|
|
WebLogic Serverバージョン9.0以降では、
|
セキュリティ・プロバイダ・データベースの初期化
ノート:
この項を読む前に、Oracle WebLogic Serverのセキュリティの理解のセキュリティ・プロバイダ・データベースに目を通しておいてください。
セキュリティ・プロバイダ・データベースは、少なくとも、認証、認可、ロール・マッピング、および資格証明マッピングの各プロバイダで必要なデフォルトのユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、または資格証明で初期化する必要があります。セキュリティ・プロバイダが使用可能になる前に、所定のセキュリティ・プロバイダのデータベースを初期化する必要があります。また、カスタム・セキュリティ・プロバイダのランタイム・クラスを記述する際に、データベースの機能を考慮する必要があります。セキュリティ・プロバイダのデータベースの初期化に使用する方法は、ユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、または資格証明情報の格納に外部管理のデータベースを使用するかどうか、およびデータベースがすでに存在するのか作成する必要があるのかなど、多くの要因に左右されます。
以下の節では、セキュリティ・プロバイダ・データベースを初期化するためのベスト・プラクティスについて説明します。
ベスト・プラクティス:データベースがない場合のシンプルなデータベースの作成
認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、または資格証明マッピング・プロバイダは、それが初めて使用されるときには、セキュリティ・サービスを提供するために必要な情報のあるデータベースを見つけようとします。セキュリティ・プロバイダがデータベースを見つけられない場合は、セキュリティ・プロバイダにデータベースを作成させて、デフォルトのユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明を自動的に格納することができます。このオプションは、開発およびテストに便利です。
WebLogicセキュリティ・プロバイダとサンプル・セキュリティ・プロバイダは両方ともこのプラクティスに従います。WebLogicの認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、ユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明の情報を組込みLDAPサーバーに格納します。これらのWebLogicセキュリティ・プロバイダのいずれかを使用する場合は、Oracle WebLogic Serverセキュリティの管理の組込みLDAPサーバーの構成の手順を参照してください。
ノート:
サンプル・セキュリティ・プロバイダは、プロパティ・ファイルを作成し、それらのデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザーおよびグループについての必要な情報が格納されるSampleAuthenticatorDatabase.java
というファイルが作成されます。
ベスト・プラクティス:既存のデータベースの構成
外部LDAPサーバーなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダが必要とするユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。
データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ・プロバイダを構成する必要があります。そのためには、セキュリティ・プロバイダのMBean定義ファイル(MDF)でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMakerを通じてMDFを実行し、さらにいくつかのステップを行ってカスタム・セキュリティ・プロバイダのMBeanタイプを生成したら、WebLogic Server管理コンソールを使用してそれらの属性がデータベースを指すように設定します。
ノート:
「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください。
例2-5に、WebLogic LDAP認証プロバイダのMDFに属する一部のカスタム属性を例として示します。これらの属性を使用することにより、WebLogic LDAP認証プロバイダのデータベース(外部LDAPサーバー)についての情報を指定することができるので、プロバイダでユーザーおよびグループについての情報を見つけることができます。
例2-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. If such an attribute does not exist, WebLogic Server determines if a user is a member of a group by evaluating the URLs on the dynamic group. 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>." /> ...
ベスト・プラクティス:データベース初期化の委託
可能な限り、セキュリティ・プロバイダとセキュリティ・プロバイダ・データベースの間の初期化呼出しは、データベース・デリゲータという中間クラスを介して行う必要があります。データベース・デリゲータは、図2-11で示されているようにセキュリティ・プロバイダのランタイム・クラスおよびMBeanタイプと対話する必要があります。
データベース・デリゲータは、WebLogicの認証プロバイダと資格証明マッピング・プロバイダで使用されます。たとえば、WebLogic認証プロバイダはデータベース・デリゲータに働きかけてデフォルトのユーザーおよびグループで組込みLDAPサーバーを初期化します。デフォルトのユーザーおよびグループは、デフォルト・セキュリティ・レルムの認証サービスを提供するために必要な情報です。
カスタム・セキュリティ・プロバイダを開発するアプリケーション開発者およびセキュリティ・ベンダーは、データベース・デリゲータを使用することをお薦めします。データベース・デリゲータを使用すると、セキュリティ・プロバイダのデータベースが隠蔽され、データベースへの呼出しが一元化されるメリットがあります。
ベスト・プラクティス: JDBC接続セキュリティ・サービスAPIを使用したデータベース接続の取得
カスタム・セキュリティ・プロバイダのデータベースを作成または構成する際のベスト・プラクティスに代わる方法として、プロバイダの初期化中にのみJDBCConnectionService
SSPIを使用し、WebLogicドメインに対して構成されているJDBCデータ・ソースにアクセスすることができます。
この機能を使用すると、カスタム・セキュリティ・プロバイダは、JDBCデータ・ソース(マルチ・データ・ソースを含む)を通じて提供されるデータベース・アクセス管理およびデータベース接続管理のあらゆる機能を利用できます。SQL文の実行方法と接続のコンテキスト内で結果を戻す方法については、http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html
を参照してください。
JDBCConnectionService
SSPIを使用する際は、次の点に注意してください。
-
JDBCConnectionService
は、カスタム・プロバイダのinitialize()
メソッドで取得します。 -
データ・ソースは、JNDIパスではなく、名前(
sqlConnectionName
)で識別されます。 -
初期化中はJDBCリソースを利用できないことがあります。JNDIおよびJDBCサブシステムが完全に初期化され、利用可能になるまでは、直接接続が戻されます。
-
JDBCデータ・ソースから戻されたデータベース接続を使用し終わったら、セキュリティ・プロバイダは
releaseConnection
メソッドを呼び出し、(Connection
オブジェクトを指定して、)接続を解放する必要があります。
例2-6は、JDBCConnectionService
SSPIを使用して、指定したJDBCデータ・ソースからデータベース接続を取得する方法を示しています。
例には示されていませんが、JDBCConnectionService.getConnection
は、指定したJDBCデータ・ソースが利用できない場合にJDBCConnectionServiceException
を、データベース接続が利用できない場合にSQLException
をスローする可能性があります。JDBCConnectionService.releaseConnection
は、データベース接続が利用できない場合にSQLException
をスローする可能性があります。
例2-6 JDBCConnectionService APIを使用したJDBCデータ・ソースへのアクセス
JDBCConnectionService dbService = null; if (services instanceof SecurityServicesJDBC) { try { dbService = ((SecurityServicesJDBC)services).getJDBCConnectionService(); System.out.println("Obtained the JDBCConnectionService, " + dbService); Connection conn = dbService.getConnection("oracle-database"); PreparedStatement statement = conn.prepareStatement("select sysdate from dual"); ResultSet rs= statement.executeQuery(); while (rs.next()) { String s1 = rs.getString(1); System.out.println("Sys date =" + s1); } dbService.releaseConnection(conn); } catch(Exception e) { e.printStackTrace(); }
JDBC接続セキュリティ・サービスの実装: 主なステップ
JDBCデータ・ソースへのアクセスを取得するためにセキュリティ・サービスを実装するには、次の手順に従います。
-
プロバイダの
initialize()
メソッドで、SecurityServicesJDBC
インタフェースのgetJDBCConnectionService
メソッドを呼び出して、JDBC接続サービスを取得します。 -
JDBC接続サービス・インスタンスに対して
getConnection
メソッドを呼び出し、WebLogicドメインで構成されているJDBCデータ・ソースの名前を渡します。 -
適切なデータベース・コマンド(プリコンパイルされた文や問合せなど)を追加します。
-
接続インスタンスを解放するには、JDBC接続サービス・インスタンスに対して
releaseConnection
メソッドを呼び出す必要があります。
属性バリデータの相違点
バリデータは、様々な種類の式を検証できるクラスによって実装されるインタフェースです。このリリースの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
を拡張するように指定します。 -
MBeanタイプの生成するには、WebLogic MBeanMakerを使用します。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サブ要素で属性バリデータを再宣言します。