| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 12cリリース1(12.1.1) B65927-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 12cリリース1(12.1.1) B65927-02 |
|
前 |
次 |
開発作業を綿密に計画すると、カスタム・セキュリティ・プロバイダの開発に要する時間と労力を大幅に削減できます。以下の節では、最初に知っておくと役立つ、セキュリティ・プロバイダの概念と機能について詳しく説明します。
作成できるセキュリティ・プロバイダには様々なタイプがありますが(『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・プロバイダのタイプに関する項を参照)、それらのプロバイダはすべて同じアーキテクチャに基づきます。図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セキュリティ・フレームワークは以下のことを行います。
セキュリティ・レルムでセキュリティ・プロバイダと関連付けられたMBeanタイプを見つけます。
MBeanタイプからセキュリティ・プロバイダのランタイム・クラス(2つある場合は「Provider」SSPIを実装する方のランタイム・クラス)の名前を取得します。
セキュリティ・プロバイダが初期化(構成データの読込み)に使用する適切なMBeanインスタンスを渡します。
このため、ランタイム・クラス(1つまたは複数)およびMBeanタイプの両方で「セキュリティ・プロバイダ」と呼ばれるものが形成されます。
「開発プロセスの概要」で説明されているように、カスタム・セキュリティ・プロバイダの開発ではまず最初に多くのセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してランタイム・クラスを作成します。この節では、以下の助けになる情報を提供します。
また、この節では各タイプのセキュリティ・プロバイダでどのSSPIを実装できるのかを示す「SSPIクイック・リファレンス」も提供します。
セキュリティ・プロバイダは、以下の制限事項に準拠している必要があります。
カスタム・セキュリティ・プロバイダのランタイム・クラスの実装には、WebLogicセキュリティ・フレームワークによるセキュリティ・チェックの実行を必要とするコードを含めることはできません。セキュリティ・プロバイダは実際にセキュリティ・チェックを実行し、WebLogicリソースへのアクセス権を付与するWebLogicセキュリティ・フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。
セキュリティ・プロバイダの実装内で、ローカル(同じサーバー、クラスタ、またはドメイン内)のJava Platform, Enterprise Edition (Java EE)バージョン5サービスを使用することはできません。これらの使用を試行することもサポートされていません。たとえば、セキュリティ・プロバイダから現在のドメイン内のEJBを呼び出すことは禁止されています。
他のドメインのJava EEサービスであれば、セキュリティ・プロバイダからアクセスおよび使用できます。
名前が「Provider」という接尾辞で終わる各SSPI (たとえばCredentialProvider)は、セキュリティ・プロバイダのサービスをWebLogicセキュリティ・フレームワークに公開します。これによって、セキュリティ・プロバイダの操作(初期化、開始、停止など)が可能になります。
図3-2,で示されているように、セキュリティ・サービスをWebLogicセキュリティ・フレームワークに公開するSSPIはWebLogic Serverによって提供され、そのすべてが以下のメソッドを持つSecurityProviderインタフェースを拡張します。
initialize
public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)
initializeメソッドは、セキュリティ・プロバイダの関連付けられたMBeanインスタンスに限定できるProviderMBeanを引数として取ります。そのMBeanインスタンスは生成するMBeanタイプから作成され、カスタム・セキュリティ・プロバイダをWebLogic Server環境で管理できるようにする構成データを含みます。この構成データがある場合は、initializeメソッドを使用してそれを抽出する必要があります。
securityServices引数は、カスタム・セキュリティ・プロバイダで監査サービスを取得して使用する際の取得先となるオブジェクトです。監査サービスと監査の詳細は、第10章「監査プロバイダ」および第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」を参照してください。
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セキュリティ・フレームワークに公開します(「「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アプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってポリシーをデプロイできる認可プロバイダでは、AuthorizationProvider SSPIではなくDeployableAuthorizationProviderV2 SSPIを実装する必要があります。しかし、DeployableAuthorizationProviderV2 SSPIはAuthorizationProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、認可プロバイダがポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの認可プロバイダがDeployableAuthorizationProviderV2 SSPIをサポートする必要があり、サポートされていない場合、WebアプリケーションやEJBをデプロイできなくなります。
|
注意: セキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。 |
WebアプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってロールをデプロイできるロール・マッピング・プロバイダでは、RoleProvider SSPIではなくDeployableRoleProviderV2 SSPIを実装する必要があります。しかし、DeployableRoleProviderV2 SSPIはRoleProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、ロール・マッピング・プロバイダがセキュリティ・ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つのロール・マッピング・プロバイダがこのSSPIをサポートする必要があり、そうでなければ、WebアプリケーションやEJBをデプロイすることが不可能になります。
|
注意: セキュリティ・ロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。 |
|
注意: DeployableCredentialProviderインタフェースは、このリリースのWebLogic Serverで非推奨になりました。 |
リソース・アダプタ(RA)のデプロイメントにかわってセキュリティ・ポリシーをデプロイできる資格証明マッピング・プロバイダでは、CredentialProvider SSPIではなくDeployableCredentialProvider SSPIを実装する必要があります。しかし、DeployableCredentialProvider SSPIはCredentialProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、リソース・アダプタのデプロイメント作業では、資格証明マッピング・プロバイダが資格証明およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの資格証明マッピング・プロバイダがこのSSPIをサポートする必要があり、そうでなければ、リソース・アダプタをデプロイすることが不可能になります。
|
注意: 資格証明の詳細は、「資格証明マッピングの概念」を参照してください。セキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。 |
図3-3は、資格証明マッピング・プロバイダを使用してすべてのSSPIに共通の継承階層を示すとともに、ランタイム・クラスでどのようにそれらのインタフェースを実装できるのかを示します。この例では、Oracleが提供するSecurityProviderインタフェースと、CredentialProviderV2およびCredentialMapperV2 SSPIを使用します。図3-3は、CredentialProviderV2 SSPIおよびCredentialMapperV2 SSPIを実装するMyCredentialMapperProviderImplという単一のランタイム・クラスを表しています。
ただし、図3-3 SSPIを実装できる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の略で、JMX (Java Management eXtensions)で管理可能なリソースを表すJavaオブジェクトのことです。
|
注意: JMXは、標準的な管理アーキテクチャ、APIおよび管理サービスを定義する仕様です。『Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発』のJMXの理解に関する項を参照してください。 |
MBeanタイプは、MBeanのインスタンスのファクトリです。MBeanのインスタンスは、WebLogic Server管理コンソールを使用して作成できます。MBeanのインスタンスが作成されたら、管理コンソールでそのインスタンスを使用してカスタム・セキュリティ・プロバイダを構成および管理できます。
|
注意: すべてのMBeanインスタンスは自分の親タイプを認識しているので、MBeanタイプの構成を変更すると、管理コンソールを使用して作成したすべてのインスタンスの構成も更新されます。(詳細については、「SSPI MBeanの階層と管理コンソールに対する影響について」を参照してください)。 |
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を拡張するものであることを示しています。また、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管理コンソールのカスタム・セキュリティ・プロバイダの「プロバイダ固有」タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります。(「コンソール拡張機能の記述」を参照してください。)
|
注意: サンプル監査プロバイダは、カスタム属性の追加例を提供しています。 |
WL_HOME\server\lib\mbeantypesからロードされるクラスは、WebLogic Serverにデプロイされている他のJARファイルやEARファイルからは認識されません。共有する必要がある共通のユーティリティ・クラスがある場合、そのクラスはシステムのクラスパスに配置する必要があります。
|
注意: MBeanタイプをインストールするデフォルトのディレクトリは、 |
カスタム・プロバイダの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管理コンソール・ページに自動的に表示されます。これらの属性と操作は、カスタム・セキュリティ・プロバイダを構成および管理するために使用します。
|
注意: 認証セキュリティ・プロバイダに限っては、MDFで実装されるオプショナルSSPI MBeanで指定された属性と操作も管理コンソールで自動的にサポートされます。他のタイプのセキュリティ・プロバイダの場合、オプショナルSSPI MBeanから継承された属性/操作を管理コンソールで使用するには、コンソール拡張機能を記述する必要があります。詳細については、「コンソール拡張機能の記述」を参照してください。 |
図3-5は、WebLogic資格証明マッピングMDFを例に使用してセキュリティ・プロバイダのSSPI MBean階層を示すとともに、どの属性/操作がWebLogic資格証明マッピング・プロバイダの管理コンソールで表示されるのかを示します。
図3-5で示されているように、DefaultCredentialMapper MDFのSSPI MBeanの階層を実装することにより、図3-6のページが管理コンソールで表示されます。DefaultCredentialMapper MDFの部分的なリストは、例3-1に示してあります。
「名前」、「説明」、および「バージョン」の各フィールドは、Providerという基本必須SSPI MBeanから継承されDefaultCredentialMapper MDFに指定されている同名の属性から得られたものです。DefaultCredentialMapper MDF内のDisplayName属性から「名前」フィールドの値が生成されるほか、DescriptionとVersionの各属性からも、それぞれ対応するフィールドの値が生成されることに注意します。なお、「プロバイダ固有」ページの「資格証明マッピング・デプロイメントを有効化」フィールドが表示されているのは、DefaultCredentialMapper MDFの拡張元であるDeployableCredentialMapper必須SSPI MBeanにCredentialMappingDeploymentEnabled属性が定義されているためです。この管理コンソール・ページには、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-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管理コンソール・ページの「移行」タブに自動的に表示されます(図3-8を参照)。これにより、管理者は各セキュリティ・プロバイダのセキュリティ・データを個別にエクスポートおよびインポートすることができます。
|
注意: セキュリティ・プロバイダが移行機能を持っていない場合、そのセキュリティ・プロバイダの「移行」タブは管理コンソールに表示されません。 管理コンソールを使用して個々のセキュリティ・プロバイダのセキュリティ・データを移行する手順については、『Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する項を参照してください。 |
また、セキュリティ・レルムに移行機能を持つセキュリティ・プロバイダが構成されている場合、管理者はセキュリティ・レルム・レベルの「移行」タブ(図3-9を参照)を使用して、セキュリティ・レルムにあるすべてのセキュリティ・プロバイダのセキュリティ・データを一度にエクスポートまたはインポートできます。
|
注意: セキュリティ・レルム・レベルの「移行」タブは、移行機能を持つセキュリティ・プロバイダがセキュリティ・レルムで構成されているかどうかにかかわらず、管理コンソールに常に表示されます。ただし、「移行」タブが機能するのは、1つまたは複数のセキュリティ・プロバイダが移行機能を持っている場合だけです。 すべてのセキュリティ・プロバイダのセキュリティ・データを一度に移行する手順については、『Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する項を参照してください。 |
|
注意: オプションのSSPI MBeanであるExportMBeanおよびImportMBeanを拡張する場合は、管理コンソールではなくWebLogic Scripting Tool (WLST)を使用してセキュリティ・データを移行することもできます。詳細は、『Oracle WebLogic Scripting Tool』を参照してください。 |
MDFに属性または操作を追加する場合、管理コンソールで使用できるように、やはりコンソール拡張を記述する必要があります。
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は、データ・リストを扱うためだけでなく、例外用にも |
詳細は、Oracle WebLogic Server MBean APIリファレンスでExportMBeanインタフェースとweblogic.management.utilsパッケージを参照してください。
WebLogicリソースは、権限のないアクセスから保護することができるWebLogic Serverエンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダの開発者は、これらのセキュリティ・プロバイダが、WebLogicリソースおよびそれらのリソースのセキュリティに使用されるセキュリティ・ポリシーとどのように対話するかを理解しておく必要があります。
|
注意: セキュリティ・ポリシーは、以前のリリースのWebLogic ServerでWebLogicリソースを保護するために使用していたアクセス制御リスト(ACL)と権限にかわるものです。 |
以下の節では、セキュリティ・プロバイダとWebLogicリソースについて説明します。
|
注意: 詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。 |
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 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 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アプリケーション内の特定の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>
|
注意: getParentResourceメソッドの詳細は、Oracle WebLogic Server APIリファレンスで、定義済の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セキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。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セキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダまたはインタフェースで、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。
表3-12に、コンテキスト・ハンドラのサポートについて示します。
表3-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サーバーの構成に関する項で説明されている指示に従う必要があります。
|
注意: サンプル・セキュリティ・プロバイダは、プロパティ・ファイルを作成し、それらのデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザーおよびグループについての必要な情報が格納される |
外部LDAPサーバーなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダが必要とするユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。
データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ・プロバイダを構成する必要があります。そのためには、セキュリティ・プロバイダのMBean定義ファイル(MDF)でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMakerを通じてMDFを実行し、さらにいくつかの手順を行ってカスタム・セキュリティ・プロバイダのMBeanタイプを生成したら、WebLogic Server管理コンソールを使用してそれらの属性がデータベースを指すように設定します。
例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. 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>." /> ...
可能な限り、セキュリティ・プロバイダとセキュリティ・プロバイダ・データベースの間の初期化呼出しは、データベース・デリゲータという中間クラスを介して行う必要があります。データベース・デリゲータは、図3-11で示されているようにセキュリティ・プロバイダのランタイム・クラスおよびMBeanタイプと対話する必要があります。
データベース・デリゲータは、WebLogicの認証プロバイダと資格証明マッピング・プロバイダで使用されます。たとえば、WebLogic認証プロバイダはデータベース・デリゲータに働きかけてデフォルトのユーザーおよびグループで組込みLDAPサーバーを初期化します。デフォルトのユーザーおよびグループは、デフォルト・セキュリティ・レルムの認証サービスを提供するために必要な情報です。
カスタム・セキュリティ・プロバイダを開発するアプリケーション開発者およびセキュリティ・ベンダーは、データベース・デリゲータを使用することをお薦めします。データベース・デリゲータを使用すると、セキュリティ・プロバイダのデータベースが隠蔽され、データベースへの呼出しが一元化されるメリットがあります。
カスタム・セキュリティ・プロバイダのデータベースを作成または構成する際のベスト・プラクティスに代わる方法として、プロバイダの初期化中にのみJDBCConnectionService SSPIを使用し、WebLogicドメインに対して構成されているJDBCデータ・ソースにアクセスすることができます。
この機能を使用すると、カスタム・セキュリティ・プロバイダは、JDBCデータ・ソース(マルチ・データ・ソースを含む)を通じて提供されるデータベース・アクセス管理およびデータベース接続管理のあらゆる機能を利用できます。SQL文の実行方法と接続のコンテキスト内で結果を戻す方法については、http://download.oracle.com/javase/1.5.0/docs/api/java/sql/Connection.htmlを参照してください。
JDBCConnectionService SSPIを使用する際は、次の点に注意してください。
JDBCConnectionServiceは、カスタム・プロバイダの initialize()メソッドで取得します。
データ・ソースは、JNDIパスではなく、名前(sqlConnectionName)で識別されます。
初期化中はJDBCリソースを利用できないことがあります。JNDIおよびJDBCサブシステムが完全に初期化され、利用可能になるまでは、直接接続が戻されます。
JDBCデータ・ソースから戻されたデータベース接続を使用し終わったら、セキュリティ・プロバイダはreleaseConnectionメソッドを呼び出し、(Connectionオブジェクトを指定して、)接続を解放する必要があります。
例3-6は、JDBCConnectionService SSPIを使用して、指定したJDBCデータ・ソースからデータベース接続を取得する方法を示しています。
例には示されていませんが、JDBCConnectionService.getConnectionは、指定したJDBCデータ・ソースが利用できない場合にJDBCConnectionServiceExceptionを、データベース接続が利用できない場合にSQLExceptionをスローする可能性があります。JDBCConnectionService.releaseConnectionは、データベース接続が利用できない場合にSQLExceptionをスローする可能性があります。
例3-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データ・ソースへのアクセスを取得するためにセキュリティ・サービスを実装するには、次の手順に従います。
プロバイダの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サブ要素で属性バリデータを再宣言します。
