| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.6) B61617-04 |
|
 前 |
 次 |
以下の節では、WebLogic Serverで提供されているセキュリティ・プロバイダを構成する方法について説明します。
|
注意: WebLogic Serverには、多くの認証プロバイダとIDアサーション・プロバイダが組み込まれているので、これらについては別の章で詳しく説明します。第5章「認証プロバイダの構成」を参照してください。 |
デフォルトでは、ほとんどのWebLogicセキュリティ・プロバイダは通常WebLogic Serverをインストールすると実行できるように構成されています。ただし、以下のような状況では、構成情報を指定する必要があります。
WebLogic IDアサーション・プロバイダを使用する前に、アクティブなトークン・タイプを定義します。「IDアサーション・プロバイダの構成」を参照してください。
セキュリティ・レルム内のユーザーにトークンをマップするには、WebLogic IDアサーション・プロバイダでユーザー名マッパーを構成します。「WebLogic資格証明マッピング・プロバイダの構成」を参照してください。
デフォルト(アクティブ)セキュリティ・レルムで監査を使用するには、WebLogic監査プロバイダまたはカスタム監査プロバイダを構成します。「WebLogic監査プロバイダの構成」を参照してください。
WebLogic ServerでHTTPおよびKerberosベースの認証を使用します。第6章「Microsoftのクライアントに対するシングル・サインオンの構成」を参照してください。
SAMLアサーションに基づくIDアサーションを使用します。第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。
証明書失効を使用します。「証明書ルックアップおよび検証フレームワークの構成」を参照してください。
組込みLDAPサーバー以外のLDAPサーバーを使用するには、いずれかのLDAP認証プロバイダを構成します。LDAP認証プロバイダは、WebLogic認証プロバイダのかわりに、またはWebLogic認証プロバイダに加えて使用できます。「LDAP認証プロバイダの構成」を参照してください。
認証を行うために、データベースに格納されているユーザー、パスワード、グループ、およびグループ・メンバーシップ情報にアクセスします。「RDBMS認証プロバイダの構成」を参照してください。RDBMS認証プロバイダを使用すると、RDBMSセキュリティ・レルムからアップグレードできます。
認証のためにWindows NTのユーザーとグループを使用します。「Windows NT認証プロバイダの構成」を参照してください。Windows NT認証プロバイダは、Window NTセキュリティ・レルムのアップグレード・パスです。
新しいセキュリティ・レルムを作成する場合は、そのレルムのセキュリティ・プロバイダを構成します。「新しいセキュリティ・レルムの作成と構成:主な手順」を参照してください。
セキュリティ・レルムにカスタム・セキュリティ・プロバイダを追加する場合、またはWebLogicセキュリティ・プロバイダをカスタム・セキュリティ・プロバイダで置き換える場合は、カスタム・セキュリティ・プロバイダのオプションを構成します。カスタム・セキュリティ・プロバイダを作成する場合、管理コンソールから構成可能なオプションを実装できます。ただし、それらのオプションは実装に固有のものであり、このマニュアルでは扱われていません。『Oracle WebLogic Server管理コンソールの拡張』を参照してください。
セキュリティ・レルム内ではWebLogicが提供するセキュリティ・プロバイダか、またはカスタム・セキュリティ・プロバイダを使用できます。カスタム・セキュリティ・プロバイダを構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・セキュリティ・プロバイダの構成に関する項を参照してください。
セキュリティ・レルムには、特定のタイプのセキュリティ・プロバイダを複数構成できます。たとえば、複数のロール・マッピング・プロバイダや複数の認可プロバイダの使用が可能です。セキュリティ・レルム内に同じタイプの複数のセキュリティ・プロバイダがある場合、それらのプロバイダが呼び出される順序は、セキュリティ・プロセスの全体的な結果に影響を与える可能性があります。デフォルトでは、セキュリティ・プロバイダはレルムに追加された順序で呼び出されます。管理コンソールを使用すると、プロバイダの順序を変更できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・プロバイダの順番の変更に関する項を参照してください。
ベスト・プラクティスの場合、デフォルトでは、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対して並列変更を実行できます。このため、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。
ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされている場合とサポートされていない場合があります。カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダが並列呼出しをサポートしない場合、並列セキュリティ・ポリシーとロール変更を無効にして、かわりに各アプリケーションとモジュールがキューに配置され、連続してデプロイされる同期メカニズムを実行する必要があります。これを行わないと、プロバイダが並列呼出しをサポートしない場合、java.util.ConcurrentModificationException例外が生成されます。
この同期実行メカニズムは、次の2つの方法で有効にすることができます。
|
注意: 同期メカニズムを有効にすると、WebLogic Server XACMLプロバイダを含む、レルム内で構成されるすべてのデプロイ可能プロバイダが影響を受けます。同期メカニズムを有効にする場合、これらのプロバイダのパフォーマンスに悪影響があります。 |
WebLogic Server管理コンソール。レルムの「デプロイ可能プロバイダの同期を有効化」と「デプロイ可能プロバイダの同期のタイムアウト」の制御を設定します。
「デプロイ可能プロバイダの同期を有効化」制御により、各アプリケーションとモジュールがキューに配置されて連続してデプロイされる同期メカニズムが実行されます。
「デプロイ可能プロバイダの同期のタイムアウト」制御により、デプロイ可能セキュリティ・プロバイダ同期操作に関するタイムアウト値(ミリ秒)が設定されるか返されます。これは、以前のサイクルがスタック状態になるとデプロイメント・サイクルがキューで待機する最大時間です。
RealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性。WLSTから、RealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性を設定します。
Oracle WebLogic Server MBeanリファレンスのRealmMBeanに関する項を参照してください。
認可とは、ユーザーとリソースとのやり取りを限定して、整合性、機密性、および可用性を確実にするプロセスのことです。すなわち、認可では、ユーザーの身元などの情報に基づいてリソースへのアクセスを制御します。認可プロバイダを構成する必要があるのは、新しいセキュリティ・レルムを作成するときだけです。
デフォルトでは、新しく作成されるドメイン内のセキュリティ・レルムにはXACML認可プロバイダが含まれています。XACML認可プロバイダは、XACML (eXtensible Access Control Markup Language)を使用します。XACML認可プロバイダの使い方については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のXACMLドキュメントによるWebLogicリソースの保護に関する項を参照してください。WebLogic Serverには、独自のポリシー言語を使用するWebLogic認可プロバイダも用意されています。このプロバイダは「DefaultAuthorizer(デフォルト認可プロバイダ)」と呼ばれますが、デフォルトの認可プロバイダではなくなりました。
アプリケーションとモジュールのデプロイメント時にセキュリティ・ポリシーに対する並列変更を認可プロバイダがサポートする方法については、「デプロイメント時のセキュリティ・ポリシーとロール変更の同期の有効化」を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認可プロバイダの構成に関する項を参照してください。
|
注意: WebLogic認可プロバイダでは、ロール、述部、およびそのルックアップするリソース・データをキャッシュすることによってパフォーマンスを向上します。こうしたキャッシュの構成については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のベスト・プラクティス: WebLogicプロバイダの使用時の資格のキャッシングの構成に関する項を参照してください。XACML認可では独自のキャッシュを使用しますが、このキャッシュは構成できません。 |
セキュリティ・レルムに複数の認可プロバイダが構成される場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAINのいずれかです。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の競合を解決し、最終決定を返します。
各セキュリティ・レルムでは1つの採決プロバイダが必要であり、アクティブな採決プロバイダは1つだけでなければなりません。デフォルトでは、WebLogicセキュリティ・レルムにはWebLogic裁決プロバイダが構成されます。セキュリティ・レルムでは、WebLogic裁決プロバイダまたはカスタム裁決プロバイダのいずれかを使用できます。
|
注意: 管理コンソールでは、WebLogic裁決プロバイダを「デフォルト裁決プロバイダ」と呼びます。 |
WebLogic裁決プロバイダの構成オプションの大部分は、デフォルトで定義されています。しかし、「完全一致の許可が必要」オプションを設定することによって、WebLogic裁決プロバイダが、構成された認可プロバイダからのPERMITおよびABSTAIN票をどのように処理するかを指定できます。
このオプションを有効(デフォルト)にした場合、裁決プロバイダがtrueを投じるには、すべての認可プロバイダがPERMIT票を投じる必要があります。
このオプションを無効にした場合、ABSTAIN票はPERMIT票としてカウントされます。
ロール・マッピング・プロバイダは、特定のリソースのサブジェクトに付与されるロール・セットを計算します。ロール・マッピング・プロバイダは、このロール情報を認可プロバイダに提供します。これによって、認可プロバイダはWebLogicリソースに対して「アクセスできるか」という質問に答えることができます。デフォルトでは、WebLogicセキュリティ・レルムにはXACMLロール・マッピング・プロバイダが構成されます。XACMLロール・マッピング・プロバイダは、XACML (eXtensible Access Control Markup Language)を使用します。XACMLロール・マッピング・プロバイダの使い方については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のXACMLドキュメントによるWebLogicリソースの保護に関する項を参照してください。
WebLogic Serverには、独自のポリシー言語を使用するWebLogicロール・マッピング・プロバイダも用意されています。このプロバイダは「DefaultRoleMapper (デフォルト・ロール・マッピング・プロバイダ)」と呼ばれますが、新しく作成されるセキュリティ・レルムではデフォルトのロール・マッピング・プロバイダではなくなりました。セキュリティ・レルムでカスタム・ロール・マッピング・プロバイダを使用することもできます。
デフォルトでは、XACMLロール・マッピング・プロバイダの構成オプションの大部分が定義されています。しかし、「ロール・デプロイメントを有効化」オプションを設定して、このロール・マッピング・プロバイダがWebアプリケーションおよびEJB用のデプロイメント記述子の情報をセキュリティ・レルムにインポートするかどうかを指定できます。デフォルトでは、この設定は有効になっています。
「ロール・デプロイメントを有効化」をサポートするには、ロール・マッピング・プロバイダにDeployableRoleProvider SSPIを実装する必要があります。ロールは、XACMLロール・マッピング・プロバイダによって組込みLDAPサーバーに格納されます。
アプリケーションとモジュールのデプロイメント時にロールに対する並列変更をロール・マッピング・プロバイダがサポートする方法については、「デプロイメント時のセキュリティ・ポリシーとロール変更の同期の有効化」を参照してください。
ロール・マッピング・プロバイダの使用、開発、および構成については、以下を参照してください。
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループ、セキュリティ・ロールに関する項
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「ロール・マッピング・プロバイダ」
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロール・マッピング・プロバイダの構成に関する項
|
注意: WebLogicロール・マッピング・プロバイダでは、ロール、述部、およびそのルックアップするリソース・データをキャッシュすることによってパフォーマンスが向上します。こうしたキャッシュの構成については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のベスト・プラクティス: WebLogicプロバイダの使用時の資格のキャッシングの構成に関する項を参照してください。XACMLロール・マッピング・プロバイダでは独自のキャッシュを使用しますが、このキャッシュは構成できません。 |
監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査プロバイダはコンピュータのアクティビティの電子的な記録を生成します。
監査プロバイダの構成はオプションです。デフォルト・セキュリティ・レルム(myrealm)には監査プロバイダは構成されていません。WebLogic Serverには、WebLogic監査プロバイダ(管理コンソールではDefaultAuditor)というプロバイダが用意されています。また、カスタム監査プロバイダを開発することもできます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「監査プロバイダ」を参照してください。
WebLogic監査プロバイダは、表4-1で説明するイベントのログを記録できます。また、構成監査(「構成監査」を参照)を有効にした場合、WebLogic監査プロバイダは表4-4で説明するイベントのログを記録できます。
表4-1 WebLogic監査プロバイダのイベント
| 監査イベント | 意味 |
|---|---|
AUTHENTICATE |
単純認証(ユーザー名とパスワード)が発生しました。 |
ASSERTIDENTITY |
境界認証(トークン・ベース)が発生しました。 |
USERLOCKED |
無効なログイン試行によってユーザー・アカウントがロックされました。 |
USERUNLOCKED |
ユーザー・アカウントのロックがクリアされました。 |
USERLOCKOUTEXPIRED |
ユーザー・アカウントのロックの期限が切れました。 |
ISAUTHORIZED |
認可処理の試行が発生しました。 |
ROLEEVENT |
|
ROLEDEPLOY |
|
ROLEUNDEPLOY |
|
POLICYDEPLOY |
|
POLICYUNDEPLOY |
|
START_AUDIT |
監査プロバイダが起動しました。 |
STOP_AUDIT |
監査プロバイダが停止しました。 |
WebLogic監査プロバイダの構成オプションは大部分がデフォルトであらかじめ定義されています。また、WebLogic監査プロバイダはアクティブなセキュリティ・レルムに追加されると監査イベントの記録を開始します。ただし、次の設定については定義する必要があります。これらの設定は管理コンソールのプロバイダの「構成」→「プロバイダ固有」ページで行えます。WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して監査プロバイダを構成することもできます。
ローテーション時間(分) - 新しいDefaultAuditRecorder.logファイルを作成するまでの分数を指定します。指定された時間が経過すると、監査ファイルが閉じられて新しい監査ファイルが作成されます。DefaultAuditRecorder.YYYYMMDDHHMM.log (例: DefaultAuditRecorder.200405130110.log)という名前のバックアップ・ファイルが同じディレクトリ内に作成されます。
重大度 - WebLogic Serverデプロイメントに適した重大度です。WebLogic監査プロバイダは、指定された重大度のセキュリティ・イベント、およびそれより高い重大度のすべてのイベントを監査します。たとえば、重大度ERRORに設定した場合、WebLogic監査プロバイダは重大度がERROR、SUCCESS、およびFAILUREのセキュリティ・イベントを監査します。重大度をCUSTOMに設定すると、監査の必要な特定の重大度レベル(ERRORイベント、FAILUREイベントのみなど)を対象にすることもできます。監査イベントには、重大度の名前と数値順位が含まれています。このため、カスタム監査プロバイダは、名前または数値順位のいずれかによってイベントをフィルタ処理できます。監査は、以下のレベルのセキュリティ・イベントが発生したときに実行されます。
| イベント重大度 | 順位 |
|---|---|
| INFORMATION | 1 |
| WARNING | 2 |
| ERROR | 3 |
| SUCCESS | 4 |
| FAILURE | 5 |
WebLogic監査プロバイダによって記録されるすべての監査情報は、デフォルトではWL_HOME\yourdomain\yourserver\logs\DefaultAuditRecorder.logに保存されます。監査プロバイダはセキュリティ・レルム単位で構成されますが、各サーバーは監査データをサーバー・ディレクトリにある各自のログ・ファイルに書き込みます。次のJava起動オプションを使用すると、コマンド・ラインでDefaultAuditRecorder.log用に新しいディレクトリを指定できます。
-Dweblogic.security.audit.auditLogDir=c:\foo
新しいファイルの場所は、c:\foo\yourserver\logs\DefaultAuditRecorder.logになります。
詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「セキュリティ」を参照してください。
|
注意: 監査プロバイダを使用すると、わずか数個のイベントのログが記録される際にもWebLogic Serverのパフォーマンスに影響が及びます。 |
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。
監査イベントには、様々な情報やオブジェクトを保持できるContextHandlerが組み込まれています。WebLogic監査プロバイダのActive ContextHandler Entries属性を設定すると、ContextHandler内のどのContextElementエントリが監査プロバイダによって記録されるかを指定できます。デフォルトでは、どのContextElementsも監査されません。ContextHandler内のオブジェクトは、ほとんどの場合toStringメソッドを使用してログに記録されます。表4-2に、利用できるContextHandlerエントリの一覧を示します。
表4-2 監査用のコンテキスト・ハンドラ・エントリ
| コンテキスト要素名 | 説明とタイプ |
|---|---|
com.bea.contextelement. servlet.HttpServletRequest |
HTTPによるサーブレット・アクセス・リクエストまたはSOAPメッセージ。 javax.http.servlet.HttpServletRequest |
com.bea.contextelement. servlet.HttpServletResponse |
HTTPによるサーブレット・アクセス・レスポンスまたはSOAPメッセージ。 javax.http.servlet.HttpServletResponse |
com.bea.contextelement. wli.Message |
WebLogic Integrationメッセージ。メッセージは監査ログに送られます。 java.io.InputStream |
com.bea.contextelement. channel.Port |
リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・ポート。 java.lang.Integer |
com.bea.contextelement. channel.PublicPort |
リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・ポート。 java.lang.Integer |
com.bea.contextelement. channel.RemotePort |
リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・エンドのポート。 java.lang.Integer |
com.bea.contextelement. channel.Protocol |
リクエストの受け付けまたは処理を行うネットワーク・チャネルのリクエストを行うためのプロトコル。 java.lang.String |
com.bea.contextelement. channel.Address |
リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・アドレス。 java.lang.String |
com.bea.contextelement. channel.PublicAddress |
リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・アドレス。 java.lang.String |
com.bea.contextelement. channel.RemoteAddress |
リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・アドレス。 java.lang.String |
com.bea.contextelement. channel.ChannelName |
リクエストの受け付けまたは処理を行うネットワーク・チャネルの名前。 java.lang.String |
com.bea.contextelement. channel.Secure |
SSLによるリクエストの受け付けまたは処理を行うネットワーク・チャネルかどうかを示します。 java.lang.Boolean |
com.bea.contextelement. ejb20.Parameter[1-N] |
パラメータに基づくオブジェクト。 |
com.bea.contextelement. wsee.SOAPMessage |
javax.xml.rpc.handler.MessageContext |
com.bea.contextelement. entitlement.EAuxiliaryID |
WebLogic Serverの内部プロセスで使用されます。 weblogic.entitlement.expression.EAuxiliary |
com.bea.contextelement. security.ChainPrevalidatedBySSL |
SSLフレームワークが証明書チェーンを検証しました。つまり、チェーン内の証明書が相互に適切に署名しており、チェーンが終了する証明書がサーバーの信頼性のあるCAの1つであり、チェーンが基本制約ルールに準拠していて、チェーン内の証明書が期限切れではありませんでした。 java.lang.Boolean |
com.bea.contextelement. xml.SecurityToken |
このリリースのWebLogic Serverでは使用されません。 weblogic.xml.crypto.wss.provider.SecurityToken |
com.bea.contextelement. xml.SecurityTokenAssertion |
このリリースのWebLogic Serverでは使用されません。 java.util.Map |
com.bea.contextelement.
webservice.Integrity{id:XXXXX}
|
javax.security.auth.Subject |
com.bea.contextelement. saml.SSLClientCertificateChain |
SSLクライアント証明書チェーンがSSL接続から取得され、sender-vouches SAMLアサーションが受信されました。 java.security.cert.X509Certificate[] |
com.bea.contextelement. saml.MessageSignerCertificate |
Webサービス・メッセージに署名するための証明書。 java.security.cert.X509Certificate |
com.bea.contextelement. saml.subject.ConfirmationMethod |
SAMLアサーションのタイプ(bearer、artifact、sender-vouches、holder-of-key)。 java.lang.String |
com.bea.contextelement. saml.subject.dom.KeyInfo |
holder-of-key SAMLアサーションでのサブジェクト確認のために使用される org.w3c.dom.Element |
管理サーバーを構成して、ユーザーがドメイン内のリソースの構成を変更したときやドメイン内のリソースの管理操作を呼び出したときに、ログ・メッセージの送信と監査イベントの生成を行うようにすることができます。たとえば、ユーザーがドメイン内の管理対象サーバーのSSLを無効にすると、管理サーバーからログ・メッセージが送信されます。WebLogic監査プロバイダを有効にしている場合は、さらにセキュリティ・ログに監査イベントが書き込まれます。こうしたログ・メッセージと監査イベントにより、ドメインの構成の変更を監査、追跡できます。この機能を、構成監査といいます。
構成監査メッセージは、管理サーバーのローカル・ログ・ファイルに書き込まれます。デフォルトではドメイン全体のメッセージ・ログには書き込まれません。
構成監査情報は、認可イベントに格納されます。そのため、認可イベントを消費して構成監査情報にアクセスする方法もあります。ただし、認可イベント内の情報は構成の変更の実行が許可されたかどうかを示すものであり、構成の変更が実際に成功したかどうかは示されません(たとえば、変更が無効だったため失敗してしまっている場合もあります)。
構成監査の有効化は、以下のいずれかの方法で行えます。
管理コンソールを使用します。ドメインの「構成」→「全般」ページで、「構成監査のタイプ」を設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの構成監査の有効化に関する項を参照してください。
管理サーバーの起動時に、weblogic.Serverコマンドに次のJavaオプションのいずれかを含めます。
-Dweblogic.domain.ConfigurationAuditType="audit"
ドメインによって監査イベントのみが送信されます。
-Dweblogic.domain.ConfigurationAuditType="log"
ドメインによって構成監査メッセージのみが管理サーバーのログ・ファイルに書き込まれます。
-Dweblogic.domain.ConfigurationAuditType="logaudit"
ドメインによって監査イベントが送信され、構成監査メッセージが管理サーバーのログ・ファイルに書き込まれます。
『Oracle WebLogic Serverコマンド・リファレンス』の「weblogic.Serverコマンドライン・リファレンス」を参照してください。
WebLogic Scripting Toolを使用して、DomainMBeanのConfigurationAuditType属性の値を変更します。『Oracle WebLogic Scripting Tool』を参照してください。
構成監査メッセージの重大度は次のとおりです。
表4-3 構成監査メッセージの重大度
| 重大度 | 説明 |
|---|---|
|
SUCCESS |
構成の変更が正常に行われました。 |
|
FAILURE |
ユーザーの資格証明が十分でなかったため構成が変更されませんでした。 |
|
ERROR |
内部エラーのため構成が変更されませんでした。 |
構成監査メッセージは、159900 - 159910の範囲のメッセージIDで識別されます。
構成監査メッセージでは、MBeanオブジェクト名を使用してリソースを特定します。WebLogic Server MBeanのオブジェクト名は、階層データ・モデル内でのMBeanの場所を反映しています。この場所を反映させるために、オブジェクト名には親MBeanからの名前と値のペアが含まれています。たとえば、サーバーのLogMBeanのオブジェクト名は、mydomain:Name=myserverlog,Type=Log,Server=myserverです。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「WebLogic Server MBeanのデータ・モデル」を参照してください。
表4-4に、これらのメッセージをまとめます。
表4-4 構成監査メッセージの概要
| このイベントが発生した場合... | WebLogic ServerはこのIDのメッセージを生成します... | そしてこのメッセージ・テキストは... |
|---|---|---|
|
認可されたユーザーがリソースを作成します。 |
159900 |
USER username CREATED MBean-name ここで、 |
|
認可されていないユーザーがリソースを作成しようとします。 |
159901 |
USER username CREATED MBean-name FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace ここで、 |
|
認可されたユーザーがリソースを削除します。 |
159902 |
USER username REMOVED MBean-name
where |
|
認可されていないユーザーがリソースを削除しようとします。 |
159903 |
USER username REMOVE MBean-name
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace
where |
|
認可されたユーザーがリソースの構成を変更します。 |
159904 |
USER username MODIFIED MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value ここで、 |
|
認可されていないユーザーがリソースの構成を変更しようとします。 |
159905 |
USER username MODIFY MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace ここで、 |
|
認可されたユーザーがリソース操作を呼び出します。 たとえば、ユーザーがアプリケーションをデプロイするか、サーバー・インスタンスを起動します。 |
159907 |
USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters ここで、 |
|
認可されていないユーザーがリソース操作を呼び出そうとします。 |
159908 |
USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace ここで、 |
|
認可されたユーザーが構成監査を有効にします。 |
159909 |
USER username, Configuration Auditing is enabled
ここで、 |
|
認可されたユーザーが構成監査を無効にします。 |
159910 |
USER username, Configuration Auditing is disabled
ここで、usernameは構成監査を無効にしたWebLogic Serverユーザーを示します。 |
|
注意: 構成監査が有効かどうかに関係なく、認可されたユーザーがリソースを追加、変更、または削除するたびに、管理サブシステムからも重大度InfoのメッセージがID 140009で生成されます。例:<Sep 15, 2005 11:54:47 AM EDT> <Info> <Management> <140009> <Configuration changes for domain saved to the repository.> このメッセージでは、ドメインの構成が変更されたことは分かりますが、構成監査メッセージのような詳細情報は提供されません。また、このメッセージは、リソース操作を呼び出したときには生成されません。 |
表4-5に、構成監査メッセージの他のメッセージ属性をまとめます。これらの属性は、すべての構成監査メッセージで共通です。
表4-5 共通のメッセージ属性と値
| メッセージ属性 | 属性値 |
|---|---|
|
重大度 |
Info |
|
サブシステム |
Configuration Audit |
|
ユーザーID |
kernel identity この値は、どのユーザーがリソースの変更やリソース操作の呼出しを実行しても常に |
|
サーバー名 |
AdminServerName
ドメイン内のすべてのリソースの構成データが管理サーバーに保持されているため、この値は常に管理サーバーの名前になります。 |
|
マシン名 |
AdminServerHostName
ドメイン内のすべてのリソースの構成データが管理サーバーに保持されているため、この値は常に管理サーバーのホスト・マシンの名前になります。 |
|
スレッドID |
execute-thread
この値は、管理サーバーで現在実行されている実行スレッドの数によって異なります。 |
|
タイムスタンプ |
メッセージが生成されたときの |
監査イベントは、監査プロバイダによって読み込まれ、特定の方法で処理されるオブジェクトです。監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布する場合にセキュリティ・レルムによって使用されるプラガブルなコンポーネントです。
ドメインで監査イベントの送信を有効にすると、イベントが送信されます(表4-6を参照)。ドメインに対して構成されているすべての監査プロバイダは、これらのイベントを処理できます。
イベントの重大度はすべてSUCCESSになり、アクションを開始したセキュリティ・プリンシパル、権限が付与されていたかどうか、およびリクエストされたアクションのオブジェクト(MBeanまたはMBean属性)が示されます。
表4-6 構成監査の監査イベントの概要
| このイベントが発生した場合... | WebLogic Serverはこの監査イベント・オブジェクトを生成します... |
|---|---|
|
新しい構成アーティファクトを作成するリクエストが許可または回避されました。 |
weblogic.security.spi.AuditCreateConfigurationEvent |
|
既存の構成アーティファクトを削除するリクエストが許可または回避されました。 |
weblogic.security.spi.AuditDeleteConfigurationEvent |
|
既存の構成アーティファクトを変更するリクエストが許可または回避されました。 |
weblogic.security.spi.AuditInvokeConfigurationEvent |
|
既存の構成アーティファクトに対する操作の呼出しが許可または回避されました。 |
weblogic.security.spi.AuditSetAttributeConfigurationEvent |
デフォルトのWebLogic Server監査プロバイダを有効にすると、すべての監査イベントがログ・メッセージとしてその独自のログ・ファイルに書き込まれます。
作成または購入されたその他の監査プロバイダは、これらのイベントをフィルタ処理して、それらをLDAPサーバー、データベース、シンプル・ファイルなどの出力リポジトリに書き出すことができます。さらに、他のタイプのセキュリティ・プロバイダは、監査プロバイダからの監査サービスをリクエストできます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「監査プロバイダ」を参照してください。
資格証明マッピングとは、リモート・システム(既存のシステムやアプリケーションなど)の認証および認可メカニズムによって適切な資格証明セットを取得して、ターゲットのWebLogicリソースにアクセスしようとするリモート・ユーザーを認証するプロセスです。WebLogic資格証明マッピング・プロバイダは、WebLogic Serverサブジェクトを、リソースへのアクセス時に使用されるユーザー名とパスワードのペアにマップします。
デフォルトでは、WebLogic資格証明マッピング・プロバイダの構成オプションの大部分が定義されています。
|
注意: WebLogic Serverでは、「資格証明マッピング・デプロイメントを有効化」オプションを使用して、この資格証明マッピング・プロバイダがリソース・アダプタのデプロイメント記述子(weblogic-ra.xmlファイル)からセキュリティ・レルムに資格証明マップをインポートするかどうかを指定できます。ただし、このオプションは現在では非推奨になっています。資格証明マップをweblogic-ra.xmlファイルからデプロイする方法は、WebLogic Serverではサポートされません。 |
「資格証明マッピング・デプロイメントを有効化」をサポートするには、資格証明マッピング・プロバイダにDeployableCredentialProvider SSPIを実装する必要があります。資格証明マッピング情報は組込みLDAPサーバーに格納されます。
詳細については、以下を参照してください。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「資格証明マッピング・プロバイダ」を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの資格証明マッピング・プロバイダの構成に関する項および資格証明マッピングの作成に関する項を参照してください。
資格証明マップの使い方については、『Oracle WebLogic Serverリソース・アダプタのプログラミング』を参照してください。
WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。
資格証明マッピング・プロバイダの詳細は、「PKI資格証明マッピング・プロバイダの構成」と「SAML 1.1用のSAML資格証明マッピング・プロバイダの構成」を参照してください。
WebLogic ServerのPKI (公開鍵インフラストラクチャ)資格証明マッピング・プロバイダは、WebLogic Serverのサブジェクト(開始者)とターゲット・リソース(および必要であれば資格証明アクション)を、ターゲット・リソースへのアクセス時にアプリケーションで使用できるキー・ペアまたは公開証明書にマップします。PKI資格証明マッピング・プロバイダは、サブジェクトとリソース名を使用して対応する資格証明をキーストアから検索します。
PKI資格証明マッピング・プロバイダを使用するには、次を行う必要があります:
適切なキーを持つキーストアを構成し、そのキーストアをWebLogic Serverクラスタ内のすべてのマシンに配布します。キーストアのセット・アップは、WebLogic Serverの機能ではありません。キーストアの設定については、Java keytoolユーティリティのヘルプ(http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html)を参照してください。また、WebLogic Serverのキーストアとキーについては、第11章「IDと信頼の構成」を参照してください。
PKI資格証明マッピング・プロバイダを構成します。PKI資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルム(myrealm)には構成されていません。「PKI資格証明マッピング属性」と、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの資格証明マッピング・プロバイダの構成に関する項を参照してください。
資格証明マッピングを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのPKI資格証明マッピングの作成に関する項を参照してください。
PKI資格証明マッピング・プロバイダを構成するには、次の属性の値を設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの資格証明マッピング・プロバイダの構成に関する項を参照してください。
「キーストア・プロバイダ」 - Java Security API用のキーストア・プロバイダ。値が指定されていない場合、デフォルトのプロバイダ・クラスが使用されます。
「キーストアの種類」 - JKS (デフォルト)またはPKCS12。
「キーストアのパスフレーズ」 - キーストアへのアクセスに使用するパスワード。
「キーストア・ファイル名」 - サーバーが起動したディレクトリを基準としたキーストアの場所。
さらに、以下の2つの属性を任意で指定すると、一致するリソースまたはサブジェクトが存在しない場合、PKI資格証明マッピング・プロバイダが資格証明マッピングをどのように検索するかを指定できます。
「リソース階層を使用」 - リソースの種類ごとにリソース階層を上ることによって資格証明が検索されます。すべてのPKI資格証明の検索は特定のリソースから開始し、リソース階層を上ってすべての一致を見つけ出します。この属性はデフォルトで有効になっています。
「開始者のグループ名を使用」 - サブジェクトがPKI資格証明マッピング・プロバイダに渡されると、開始者がメンバーであるグループを調べることによって資格証明が検索されます。デフォルトでは、これは有効になっています。
必要な場合、資格証明マッピングに資格証明アクションというラベルを付けることができます。これは、資格証明マッピングの作成時に管理コンソールで行えます。資格証明アクションとは、様々な環境で使用される資格証明マッピングを区別する任意の文字列です。たとえば、ある資格証明マッピングでリモート・リソースからのメッセージを復号化し、別の資格証明マッピングで同じリソースへ送られるメッセージに署名するとします。これらの2つの資格証明マッピングを区別するには、サブジェクト開始者とターゲット・リソースでは不十分です。この場合、資格証明アクションを使用して、一方の資格証明マッピングにdecrypt、他方にsignというラベルを付けます。こうすると、PKI資格証明マッピング・プロバイダを呼び出すコンテナが、目的の資格証明アクション値をContextHandlerに指定してプロバイダに渡せるようになります。
PKI資格証明マッピングへの資格証明アクションの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのPKI資格証明マッピングの作成に関する項を参照してください。
WebLogic Serverのこのリリースには、2種類のSAML資格証明マッピング・プロバイダが用意されています。SAML資格証明マッピング・プロバイダ・バージョン2は構成オプションが大幅に拡張されており、新しいデプロイメントにはこのバージョンの使用をお薦めします。SAML資格証明マッピング・プロバイダ・バージョン1はWebLogic Server 9.1で非推奨になりました。セキュリティ・レルムに複数のSAML資格証明マッピング・プロバイダを含めることはできません。また、セキュリティ・レルムにSAML資格証明マッピング・プロバイダとSAML IDアサーション・プロバイダの両方が含まれる場合は、両方のバージョンが同じでなければなりません。バージョン2のSAMLプロバイダと同じセキュリティ・レルム内でバージョン1のSAMLプロバイダを使用しないでください。SAML資格証明マッピング・プロバイダ・バージョン1の構成については、WebLogic Server 9.0ドキュメントの『WebLogic Serverの保護』のSAML資格証明マッピング・プロバイダの構成に関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs90/secmanage/providers.html#SAML_cred)を参照してください。
WebLogic ServerのSAMLのサポートについては、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項およびWebLogic Securityフレームワークによるシングル・サインオンに関する項を参照してください。SAML資格証明マッピング・プロバイダをSAMLシングル・サインオン構成で使用する方法については、第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。
SAMLのアサーションの有効性は通常、期間で限定されます。SAML資格証明マッピング・プロバイダで生成されるアサーションのデフォルトの存続時間は、DefaultTimeToLive属性に指定されています。生成されたアサーションのデフォルトの存続時間は、様々なSAMLリライイング・パーティにおいてオーバーライドできます。
通常のアサーションは、NotBefore時間(デフォルトではそのアサーションが生成された(おおよその)時間に設定)から、NotOnOrAfter時間(NotBefore + TimeToLiveで計算)が経過するまで有効です。資格証明マッピング・プロバイダでソース・サイトと宛先サイト間のクロックの差を補うようにするには、SAML資格証明マッピング・プロバイダのDefaultTimeToLiveDelta属性を構成します。この存続時間オフセット値は、アサーションのNotBefore値を「現在の時間」の前後何秒に設定する必要があるのかを示す正の整数または負の整数です。DefaultTimeToLiveDeltaに値を設定すると、アサーションの存続期間は引続き(NotBefore + TimeToLive)として計算されますが、NotBefore値は(now + TimeToLiveDelta)に設定されます。たとえば、次のように設定したとします。
DefaultTimeToLive = 120 DefaultTimeToLiveDelta = -30
この場合アサーションが生成されると、存続期間は2分(120秒)になり、生成される30秒前から開始されます。
WebLogic Serverに含まれているSAML 2.0資格証明マッピング・プロバイダは、以下の用途でIDをアサートするために使用できるSAML 2.0アサーションを生成します。
SAML 2.0 Web SSOプロファイル
WS-Security SAMLトークン・プロファイル・バージョン1.1
表4-7に、SAML 2.0資格証明マッピング・プロバイダで生成されるアサーション・タイプをまとめます。
表4-7 SAML 2.0資格証明マッピング・プロバイダでサポートされるアサーション・タイプ
| アサーション・タイプ | 説明 |
|---|---|
bearer |
アサーションのサブジェクトはアサーションを伝達するベアラー。ただし、アサーションの SAML 2.0 WebブラウザSSOプロファイルおよびWS-Security SAMLトークン・プロファイル1.1で生成されるすべてのアサーションに使用します。 |
sender-vouches |
サブジェクトとは異なるIDプロバイダが、サブジェクトの検証を保証します。受信側がIDプロバイダとの信頼関係を確立している必要があります。 Webサービス・セキュリティSAMLトークン・プロファイル1.1でのみ使用されます。 |
holder-of-key |
アサーション内で表現されるサブジェクトが、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用して、リクエスト・メッセージの整合性を確保します。 Webサービス・セキュリティSAMLトークン・プロファイル1.1でのみ使用されます。 |
WebLogic ServerのSAML 2.0のサポートについては、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項およびWebLogic Securityフレームワークによるシングル・サインオンに関する項を参照してください。SAML 2.0資格証明マッピング・プロバイダをSAML 2.0シングル・サインオン構成で使用する方法については、第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。Webサービス用のサービス・プロバイダ・パートナ用に生成されたアサーションの確認方法の指定については、『Oracle WebLogic Server WebLogic Webサービスの保護』の「Security Assertion Markup Language (SAML)トークンのIDとしての使用」を参照してください。
SAML 2.0資格証明マッピング・プロバイダの構成は、SAML2CredentialMapperMBeanの属性を設定することで制御できます。SAML2CredentialMapperMBeanにアクセスするには、WebLogic Scripting Tool (WLST)を使用するか、管理コンソールの「セキュリティ・レルム」>「レルム名」>「プロバイダ」>「資格証明マッピング」ページでSAML2CredentialMapperを作成または選択します。これらの属性の詳細は、Oracle WebLogic Server MBeanリファレンスのSAML2CredentialMapperMBeanに関する項を参照してください。
SAML 2.0資格証明マッピング・プロバイダを構成するには、以下の属性を設定します。
発行者URI
このセキュリティ・プロバイダの名前です。サーバーごとのSAML 2.0プロパティを構成できる「SAML 2.0全般」ページでエンティティIDとして指定されている値と一致させる必要があります。
名前修飾子
名前マッパー・クラスで、サブジェクトの名前を修飾するセキュリティ・ドメインまたは管理ドメインとして使用します。名前修飾子を使用することで、サブジェクト名の競合を回避しながら、まったく別のユーザー・ストアから名前を結合することが可能になります。
アサーションの存続期間
生成されたアサーションが使用される可能性がある存続期間を制限する値です。有効期限を過ぎたアサーションは使用できなくなります。
キーの別名とパスワードに署名するWebサービス・アサーション
生成されたアサーションに署名するために使用します。
カスタム名前マッパー・クラス
SAML 2.0資格証明マッピング・プロバイダのデフォルトの名前マッパー・クラスをオーバーライドするカスタムJavaクラスです。サブジェクトを、アサーションに含まれるID情報にマップします。
生成属性
生成するアサーションに、認証済みのサブジェクトに関連付けられているグループ・メンバーシップ情報を含めるかどうかを指定します。
WebLogic ServerをIDプロバイダとして機能するように構成する場合は、SAML 2.0アサーションを生成するサービス・プロバイダ・パートナを作成して構成する必要があります。IDプロバイダ・サイトでアサーションを生成する必要が生じたときには、アサーションを生成すべきサービス・プロバイダ・パートナがSAML 2.0資格証明マッピング・プロバイダによって特定され、そのサービス・プロバイダ・パートナの構成に従ってアサーションが生成されます。
サービス・プロバイダ・パートナを構成する方法、およびそのパートナに構成する固有の情報は、パートナをWebシングル・サインオンに使用するかWebサービスに使用するかによって変わってきます。Webシングル・サインオン用のサービス・プロバイダ・パートナの場合は、パートナのメタデータ・ファイルをインポートし、そのパートナに関する以下のような基本情報を追加で指定する必要があります。
SAMLドキュメント(認証レスポンス、SAMLアーティファクト、アーティファクト・リクエストなど)に署名する必要があるかどうか
このパートナから受け取った署名付きドキュメントの検証に使用する証明書
SAMLアーティファクトをこのパートナに送信するために使用するバインディング
このパートナがローカル・サイトのバインディングに接続する際に使用するクライアントのユーザー名とパスワード
Webシングル・サインオン用のサービス・プロバイダ・パートナの構成については、以下を参照してください。
Webサービス用のサービス・プロバイダ・パートナの構成ではメタデータ・ファイルは使用しませんが、そのパートナに関する次の情報を指定する必要があります。
オーディエンスURI。このパートナ用に生成されるアサーションに含めるオーディエンス制約を指定します。
WebLogic Serverでは、Webサービス・ランタイムがパートナの検索に使用するパートナ検索文字列を保持する必要もあるため、オーディエンスURI属性がオーバーロードされています。「Webサービス・パートナに必要なパートナ検索文字列」を参照してください。
デフォルトの名前マッパーをオーバーライドするカスタム名前マッパー・クラス。このマッパー・クラスは、このパートナでのみ使用します。
このパートナ用に生成されるアサーションの有効期間属性を指定する値。
このパートナから受け取ったアサーションの確認方法。
Webサービス用のサービス・プロバイダ・パートナの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webサービス・サービス・プロバイダ・パートナの作成に関する項を参照してください。
Webサービス用のサービス・プロバイダ・パートナの場合は、オーディエンスURIも構成します。WebLogic Serverでは、以下のまったく異なる2つの用途に使用できるよう、オーディエンスURI属性がオーバーロードされています。
OASIS SAML 2.0仕様に従って、ターゲット・サービスのURLからなるオーディエンス制約を指定します。
パートナ・ルックアップ文字列を保持します。WebLogic Serverでは、実行時にこのルックアップ文字列を使用して、SAML 2.0アサーションの生成に使用するサービス・プロバイダ・パートナを見つけます。
パートナ・ルックアップ文字列には、パートナ・ルックアップに使用するエンドポイントURLを指定します。必要に応じて、生成するアサーションに含めるオーディエンスURI制約として使用することもできます。オーディエンスURIとしても使用できるパートナ・ルックアップ文字列を指定することで、特定のターゲットURLを2箇所(検索とオーディエンス制約)に指定する必要がなくなります。
|
注意: パートナ・ルックアップ文字列は、Webサービス・ランタイムが実行時にサービス・プロバイダ・パートナを見つけられるように構成する必要があります。 |
パートナ・ルックアップ文字列の構文は次のとおりです。
[target:char:]<endpoint-url>
この構文で、target:char:はパートナ・ルックアップ文字列を指定する接頭辞、charはハイフン(-)、プラス記号(+)、またはアスタリスク(*)のいずれか1つの特殊文字を表します。表4-8に示すように、この接頭辞によってパートナ・ルックアップの実行方法が決まります。
表4-8 サービス・プロバイダ・パートナ・ルックアップ文字列の構文
| ルックアップ文字列 | 説明 |
|---|---|
target:-:<endpoint-url>
|
URL この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、生成されるアサーションのオーディエンスURIとしては追加されません。 |
target:+:<endpoint-url>
|
URL プラス記号(+)をルックアップ文字列で使用すると、このサービス・プロバイダ・パートナ用に生成されるアサーション内のオーディエンスURIとして、エンドポイントURLが追加されます。 |
target:*:<endpoint-url>
|
文字列の先頭のパターンがURL 先頭の文字列パターンに一致するサービス・プロバイダ・パートナが複数見つかった場合は、一致した文字列パターンが最も長いパートナが選択されます。 この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、生成されるアサーションのオーディエンスURIとしては追加されません。 |
|
注意: 実行時にサービス・プロバイダ・パートナが見つかるようにするため、1つのパートナに1つ以上のパートナ・ルックアップ文字列を構成する必要があります。パートナが見つからない場合、そのパートナのアサーションは生成できません。targetルックアップ接頭辞を使用せずにエンドポイントURLを構成すると、従来のオーディエンスURIとして扱われるため、このサービス・プロバイダ・パートナ用に生成するアサーションに必ずオーディエンスURIを含める必要があります(これにより、このパートナに構成されている既存のオーディエンスURIとの下位互換性も確保できます。) |
SAML 2.0資格証明マッピング・プロバイダは、Webシングル・サインオン用に構成されたパートナごとに、信頼性のある証明書を管理しています。パートナとメッセージを交換している間に署名付きの認証またはアーティファクト・リクエストを受け取ると、信頼性のある証明書を使用してパートナの署名を検証します。パートナの証明書は、以下の用途に使用します。
SAML 2.0資格証明マッピング・プロバイダで署名付き認証リクエストまたはアーティファクト・リクエストを受け取ったときに信頼性を検証するため
アーティファクト解決サービス(ARS)からSSL接続経由でSAMLアーティファクトを取得しているサービス・プロバイダ・パートナの信頼性を検証するため
管理コンソールでは、構成したSAML 2.0資格証明マッピング・プロバイダのパートナ管理ページで、Webシングル・サインオン・サービス・プロバイダ・パートナの署名用証明書とトランスポート層クライアント証明書を表示できます。
WebLogic Serverは、Webサービス・リクエスト、双方向SSL、または他の保護された対話の一部としてデジタル証明書を受け取る場合があります。これらの証明書を検証するために、WebLogic Serverには証明書ルックアップおよび検証(CLV)フレームワークが組み込まれています。このフレームワークの役割は、X.509証明書チェーンを検索および検証することです。CLVフレームワークの主要な要素は、証明書パス・ビルダーと証明書パス検証プロバイダです。CLVフレームワークでは、証明書チェーンへの参照が与えられている場合、そのチェーンを見つけて検証する1つ(および唯一)のアクティブな証明書パス・ビルダーと、証明書チェーンを検証するゼロまたは1つ以上の証明書パス検証プロバイダが必要です。
WebLogic Serverが証明書を受け取ると、CLVフレームワークは、証明書パス・ビルダーとして構成されているセキュリティ・プロバイダを使用して証明書チェーンを検索および検証します。証明書チェーンを検索および検証したら、構成されている各証明書パス検証プロバイダを構成された順に呼び出して、証明書チェーンをさらに検証します。証明書パス・ビルダーとすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。
チェーンが有効になるのは、以下のすべての条件がtrueの場合です。
チェーン内の証明書が正しく相互署名されています。
サーバーの信頼性のあるCAの1つである証明書でチェーンが終了しています。
チェーンが基本制約ルール(チェーン内に証明書の発行が許可されていない証明書で発行された証明書がない、など)に準拠しています。
チェーン内の証明書が期限切れではありません。
WebLogic Serverには、2種類のCLVセキュリティ・プロバイダが用意されています。証明書パス・ビルダーと証明書パス検証プロバイダの両方として機能するWebLogic証明書パス・プロバイダ(「証明書パス・プロバイダ」を参照)と、証明書レジストリ(「証明書レジストリ」を参照)です。WebLogic証明書パス・プロバイダは、証明書チェーン全体に対して信頼性のあるCAベースの検証を行う場合に使用します。証明書レジストリは、証明書が登録されているかどうかだけを検証する場合に使用します。どちらの検証も行う場合、両方を使用します(証明書レジストリを現在のビルダーとして指定します)。
証明書ルックアップと検証の詳細は、第11章「IDと信頼の構成」を参照してください。
WebLogic Serverのデフォルト・セキュリティ・レルムには、WebLogic証明書パス・プロバイダが構成されます。この証明書パス・プロバイダには、証明書パス・ビルダーと証明書パス検証プロバイダという2つの機能があります。証明書パス・プロバイダは、目的の証明書または証明書チェーンを受け取ります。必要な場合、サーバーの信頼性のあるCAのリストを使用して証明書チェーンを完成させます。チェーンの作成後、証明書パス・プロバイダはチェーンを検証します。つまり、チェーン内の署名、チェーンの期限切れ、チェーンの基本制約、およびチェーンがサーバーの信頼性のあるCAの1つによって発行された証明書で終了していることをチェックします。
WebLogic証明書パス・プロバイダの構成は必要ありません。ただし、「現在のビルダー」属性を使用して、証明書パス・プロバイダをアクティブな証明書チェーン・ビルダーとして使用するかどうかを指定できます。
証明書レジストリは、WebLogic Serverへのアクセスが許可されている信頼性のある証明書のリストを明示的に登録できるセキュリティ・プロバイダです。証明書レジストリをセキュリティ・レルムの一部として構成した場合、その証明書レジストリに登録されている証明書だけが有効であると見なされます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。証明書レジストリから証明書を削除することによって、証明書を即座に無効にできます。このレジストリは、組込みLDAPサーバーに格納されます。
証明書レジストリは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証しますが、それ以外の検証は行いません。証明書レジストリをセキュリティ・レルムの証明書パス・ビルダーとして使用し、WebLogic証明書パス・プロバイダまたは別のセキュリティ・プロバイダを使用してチェーン全体の検証を行う場合、各サーバーの信頼性のあるキーストアに中間およびルートCAを登録し、証明書レジストリに目的の証明書を登録する必要があります。
WebLogic Serverのデフォルト・セキュリティ・レルムには、証明書レジストリは含まれていません。証明書レジストリを構成したら、WebLogic管理コンソールを使用してレジストリの証明書を追加、削除、および参照できます。Java keytoolユーティリティを使用すると、証明書をキーストアからファイルにエクスポートできます。管理コンソールを使用すると、PEMまたはDERファイルの証明書をファイル・システムから証明書レジストリにインポートできます。また、管理コンソールでは、証明書の内容(サブジェクトDN、発行者DN、シリアル番号、有効日、フィンガープリントなど)を参照できます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの証明書パス・プロバイダの構成に関する項を参照してください。
