ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server のセキュリティ
11g リリース 1 (10.3.1)
B55516-01
 

目次
目次
戻る
戻る 		 次へ
次へ		  

4 WebLogic セキュリティ プロバイダのコンフィグレーション

以下の節では、WebLogic Server で提供されているセキュリティ プロバイダをコンフィグレーションする方法について説明します。


注意 :

WebLogic Server には、多くの認証プロバイダと ID アサーション プロバイダが組み込まれているので、これらについては別の章で詳しく説明します。「認証プロバイダのコンフィグレーション」を参照してください。

セキュリティ プロバイダをコンフィグレーションする必要がある場合

デフォルトでは、ほとんどの WebLogic セキュリティ プロバイダは通常 WebLogic Server をインストールすると実行できるようにコンフィグレーションされています。ただし、以下のような状況では、コンフィグレーション情報を指定する必要があります。

セキュリティ レルム内では WebLogic が提供するセキュリティ プロバイダか、またはカスタム セキュリティ プロバイダを使用できます。カスタム セキュリティ プロバイダをコンフィグレーションするには、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「カスタム セキュリティ プロバイダのコンフィグレーション」を参照してください。

セキュリティ プロバイダの並び替え

セキュリティ レルムには、特定のタイプのセキュリティ プロバイダを複数コンフィグレーションできます。たとえば、複数のロール マッピング プロバイダや複数の認可プロバイダの使用が可能です。セキュリティ レルム内に同じタイプの複数のセキュリティ プロバイダがある場合、それらのプロバイダが呼び出される順序は、セキュリティ プロセスの全体的な結果に影響を与える可能性があります。デフォルトでは、セキュリティ プロバイダはレルムに追加された順序で呼び出されます。Administration Console を使用すると、プロバイダの順序を変更できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「セキュリティ プロバイダの順番の変更」を参照してください。

認可プロバイダのコンフィグレーション

認可とは、ユーザとリソースとのやり取りを限定して、整合性、機密性、および可用性を確実にするプロセスのことです。すなわち、認可では、ユーザの身元などの情報に基づいてリソースへのアクセスを制御します。認可プロバイダをコンフィグレーションする必要があるのは、新しいセキュリティ レルムを作成するときだけです。

デフォルトでは、新しく作成されるドメイン内のセキュリティ レルムには XACML 認可プロバイダが含まれています。XACML 認可プロバイダは、XACML (eXtensible Access Control Markup Language) を使用します。XACML 認可プロバイダの使い方については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。WebLogic Server には、独自のポリシー言語を使用する WebLogic 認可プロバイダも用意されています。このプロバイダは「DefaultAuthorizer (デフォルト認可プロバイダ)」と呼ばれますが、デフォルトの認可プロバイダではなくなりました。

Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「認可プロバイダのコンフィグレーション」を参照してください。


注意 :

WebLogic 認可プロバイダでは、ロール、述部、およびそのルックアップするリソース データをキャッシュすることによってパフォーマンスを向上します。こうしたキャッシュのコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ベスト プラクティス : WebLogic プロバイダの使用時に資格のキャッシングをコンフィグレーションする」を参照してください。XACML 認可では独自のキャッシュを使用しますが、このキャッシュはコンフィグレーションできません。

WebLogic 裁決プロバイダのコンフィグレーション

セキュリティ レルムに複数の認可プロバイダがコンフィグレーションされる場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAIN のいずれかです。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の衝突を解決し、最終決定を返します。

各セキュリティ レルムでは 1 つの採決プロバイダが必要であり、アクティブな採決プロバイダは 1 つだけでなければなりません。デフォルトによって、WebLogic セキュリティ レルムには WebLogic 裁決プロバイダがコンフィグレーションされます。セキュリティ レルムでは、WebLogic 裁決プロバイダまたはカスタム裁決プロバイダのいずれかを使用できます。


注意 :

Administration Console では、WebLogic 裁決プロバイダを「デフォルト裁決プロバイダ」と呼びます。

WebLogic 裁決プロバイダのコンフィグレーション オプションの大部分は、デフォルトで定義されています。しかし、[完全一致の許可が必要] オプションを設定することによって、WebLogic 裁決プロバイダが、コンフィグレーションされた認可プロバイダからの PERMIT および ABSTAIN 票をどのように処理するかを指定できます。

ロール マッピング プロバイダのコンフィグレーション

ロール マッピング プロバイダは、特定のリソースのサブジェクトに付与されるロール セットを計算します。ロール マッピング プロバイダは、このロール情報を認可プロバイダに提供します。これによって、認可プロバイダは WebLogic リソースに対して「アクセスできるか」という質問に答えることができます。デフォルトでは、WebLogic セキュリティ レルムには XACML ロール マッピング プロバイダがコンフィグレーションされます。XACML ロール マッピング プロバイダは、XACML (eXtensible Access Control Markup Language) を使用します。XACML ロール マッピング プロバイダの使い方については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。

WebLogic Server には、独自のポリシー言語を使用する WebLogic ロール マッピング プロバイダも用意されています。このプロバイダは「DefaultRoleMapper (デフォルト ロール マッピング プロバイダ)」と呼ばれますが、新しく作成されるセキュリティ レルムではデフォルトのロール マッピング プロバイダではなくなりました。セキュリティ レルムでカスタム ロール マッピング プロバイダを使用することもできます。

デフォルトによって、XACML ロール マッピング プロバイダのコンフィグレーション オプションの大部分が定義されています。しかし、[ロール デプロイメントを有効化] オプションを設定して、このロール マッピング プロバイダが Web アプリケーションおよび EJB 用のデプロイメント記述子の情報をセキュリティ レルムにインポートするかどうかを指定できます。デフォルトでは、この設定は有効になっています。

[ロール デプロイメントを有効化] をサポートするには、ロール マッピング プロバイダに DeployableRoleProvider SSPI を実装する必要があります。ロールは、XACML ロール マッピング プロバイダによって組み込み LDAP サーバに格納されます。

ロール マッピング プロバイダの使用、開発、およびコンフィグレーションについては、以下を参照してください。

WebLogic 監査プロバイダのコンフィグレーション

監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査プロバイダはコンピュータのアクティビティの電子的な記録を生成します。

監査プロバイダのコンフィグレーションは任意です。デフォルト セキュリティ レルム (myrealm) には監査プロバイダはコンフィグレーションされていません。WebLogic Server には、WebLogic 監査プロバイダ (Administration Console では DefaultAuditor) というプロバイダが用意されています。また、カスタム監査プロバイダを開発することもできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』の「監査プロバイダ」を参照してください。

WebLogic 監査プロバイダは、表 4-1 で説明するイベントのログを記録できます。また、コンフィグレーション監査 (「コンフィグレーション監査メッセージ」を参照) を有効にした場合、WebLogic 監査プロバイダは表 4-4 で説明するイベントのログを記録できます。

表 4-1 WebLogic 監査プロバイダのイベント

監査イベント 意味 
AUTHENTICATE

単純認証 (ユーザ名とパスワード) が発生した。

 
ASSERTIDENTITY

境界認証 (トークン ベース) が発生した。

 
USERLOCKED

無効なログイン試行によってユーザ アカウントがロックされた。

 
USERUNLOCKED

ユーザ アカウントのロックがクリアされた。

 
USERLOCKOUTEXPIRED

ユーザ アカウントのロックの期限が切れた。

 
ISAUTHORIZED

認可処理の試行が発生した。

 
ROLEEVENT

getRoles イベントが発生した。

 
ROLEDEPLOY

deployRole イベントが発生した。

 
ROLEUNDEPLOY

undeployRole イベントが発生した。

 
POLICYDEPLOY

deployPolicy イベントが発生した。

 
POLICYUNDEPLOY

undeployPolicy イベントが発生した。

 
START_AUDIT

監査プロバイダが起動した。

 
STOP_AUDIT

監査プロバイダが停止した。

WebLogic 監査プロバイダのコンフィグレーション オプションは大部分がデフォルトであらかじめ定義されています。また WebLogic 監査プロバイダはアクティブなセキュリティ レルムに追加されると監査イベントの記録を開始します。ただし、以下の設定については定義する必要があります。これらの設定は Administration Console のプロバイダの [コンフィグレーション｜プロバイダ固有] ページで行えます。WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用して監査プロバイダをコンフィグレーションすることもできます。

WebLogic 監査プロバイダによって記録されるすべての監査情報は、デフォルトでは WL_HOME\yourdomain\yourserver\logs\DefaultAuditRecorder.log に保存されます。監査プロバイダはセキュリティ レルム単位でコンフィグレーションされますが、各サーバは監査データをサーバ ディレクトリにある各自のログ ファイルに書き込みます。次の Java 起動オプションを使用すると、コマンドラインで DefaultAuditRecorder.log 用に新しいディレクトリを指定できます。

-Dweblogic.security.audit.auditLogDir=c:\foo

新しいファイルの場所は、c:\foo\yourserver\logs\DefaultAuditRecorder.log になります。

詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「セキュリティ」を参照してください。


注意 :

監査プロバイダを使用すると、わずか数個のイベントのログが記録される際にも WebLogic Server のパフォーマンスに影響が及びます。

詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「監査プロバイダのコンフィグレーション」を参照してください。

監査 ContextHandler 要素

監査イベントには、さまざまな情報やオブジェクトを保持できる 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 アサーションでのサブジェクト確認のために使用される <ds:KeyInfo> 要素。

org.w3c.dom.Element

管理サーバをコンフィグレーションして、ユーザがドメイン内のリソースのコンフィグレーションを変更したときやドメイン内のリソースの管理操作を呼び出したときに、ログ メッセージの送信と監査イベントの生成を行うようにすることができます。たとえば、ユーザがドメイン内の管理対象サーバの SSL を無効にすると、管理サーバからログ メッセージが送信されます。WebLogic 監査プロバイダを有効にしている場合は、さらにセキュリティ ログに監査イベントが書き込まれます。こうしたログ メッセージと監査イベントにより、ドメインのコンフィグレーションの変更を監査、追跡できます。この機能を、コンフィグレーション監査といいます。

コンフィグレーション監査メッセージは、管理サーバのローカル ログ ファイルに書き込まれます。デフォルトではドメイン全体のメッセージ ログには書き込まれません。

コンフィグレーション監査情報は、認可イベントに格納されます。そのため、認可イベントを消費してコンフィグレーション監査情報にアクセスする方法もあります。ただし、認可イベント内の情報はコンフィグレーションの変更の実行が許可されたかどうかを示すものであり、コンフィグレーションの変更が実際に成功したかどうかは示されません (たとえば、変更が無効だったため失敗してしまっている場合もあります)。

コンフィグレーション監査の有効化

コンフィグレーション監査の有効化は、以下のいずれかの方法で行えます。

  • Administration Console を使用する。ドメインの [コンフィグレーション｜全般] ページで、[コンフィグレーション監査の種類] を設定します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「コンフィグレーション監査の有効化」を参照してください。

  • 管理サーバの起動時に、weblogic.Server コマンドに以下の Java オプションのいずれかを含める。

    • -Dweblogic.domain.ConfigurationAuditType="audit"

      ドメインによって監査イベントのみが送信されます。

    • -Dweblogic.domain.ConfigurationAuditType="log"

      ドメインによってコンフィグレーション監査メッセージのみが管理サーバのログ ファイルに書き込まれます。

    • -Dweblogic.domain.ConfigurationAuditType="logaudit"

      ドメインによって監査イベントが送信され、コンフィグレーション監査メッセージが管理サーバのログ ファイルに書き込まれます。

    『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。

  • WebLogic Scripting Tool を使用して、DomainMBean の ConfigurationAuditType 属性の値を変更する。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean のデータ モデル」を参照してください。

表 4-4 に、これらのメッセージをまとめます。

表 4-4 コンフィグレーション監査メッセージの概要

発生したイベント 生成されるメッセージの ID メッセージの内容

認可されたユーザがリソースを作成した。

 
159900 

USER username CREATED MBean-name

ここで、username はログインしてリソースを作成した WebLogic Server ユーザを示す。

認可されていないユーザがリソースを作成しようとした。

 
159901 

USER username CREATED MBean-name 
FAILED weblogic.management.
NoAccessRuntimeException: 
exception-text stack-trace

ここで、username は認可されていない WebLogic Server ユーザを示す。

認可されたユーザがリソースを削除した。

 
159902

USER username REMOVED MBean-name 
ここで、username はログインしてリソースを削除した WebLogic Server ユーザを示す。

認可されていないユーザがリソースを削除しようとした。

 
159903

USER username REMOVE MBean-name 
FAILED weblogic.management.
NoAccessRuntimeException: 
exception-text stack-trace 
ここで、username は認可されていない WebLogic Server ユーザを示す。

認可されたユーザがリソースのコンフィグレーションを変更した。

 
159904

USER username MODIFIED MBean-name 
ATTRIBUTE attribute-name 
FROM old-value TO new-value

ここで、username はログインしてリソースのコンフィグレーションを変更した WebLogic Server ユーザを示す。

認可されていないユーザがリソースのコンフィグレーションを変更しようとした。

 
159905 

USER username MODIFY MBean-name 
ATTRIBUTE attribute-name 
FROM old-value TO new-value 
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace

ここで、username は認可されていない WebLogic Server ユーザを示す。

認可されたユーザがリソースのオペレーションを呼び出した。

例 : ユーザがアプリケーションをデプロイした。ユーザがサーバ インスタンスを起動した。

 
159907

USER username INVOKED ON
MBean-name 
METHOD operation-name 
PARAMS specified-parameters

ここで、username はログインしてリソースのオペレーションを呼び出した WebLogic Server ユーザを示す。

認可されていないユーザがリソースのオペレーションを呼び出そうとした。

 
159908 

USER username INVOKED ON
MBean-name 
METHOD operation-name 
PARAMS specified-parameters  
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace

ここで、username は認可されていない WebLogic Server ユーザを示す。

認可されたユーザがコンフィグレーション監査を有効にした。

 
159909 

USER username, Configuration Auditing is enabled

ここで、username はコンフィグレーション監査を有効にした WebLogic Server ユーザを示す。

認可されたユーザがコンフィグレーション監査を無効にした。

 
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

この値は、どのユーザがリソースの変更やリソース オペレーションの呼び出しを実行しても常に kernel identity になる。

サーバ名

 
AdminServerName

ドメイン内のすべてのリソースのコンフィグレーション データが管理サーバに保持されているため、この値は常に管理サーバの名前になる。

マシン名

 
AdminServerHostName

ドメイン内のすべてのリソースのコンフィグレーション データが管理サーバに保持されているため、この値は常に管理サーバのホスト マシンの名前になる。

スレッド ID

 
execute-thread

この値は、管理サーバで現在実行されている実行スレッドの数によって異なる。

タイムスタンプ

メッセージが生成されたときの timeStamp。

監査イベントと監査プロバイダ

監査イベントは、監査プロバイダによって読み込まれ、特定の方法で処理されるオブジェクトです。監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布する場合にセキュリティ レルムによって使用されるプラグイン可能なコンポーネントです。

ドメインで監査イベントの送信を有効にすると、イベントが送信されます (表 4-6 を参照)。ドメインに対してコンフィグレーションされているすべての監査プロバイダは、これらのイベントを処理できます。

イベントの重大度はすべて SUCCESS になり、アクションを開始したセキュリティ プリンシパル、パーミッションが付与されていたかどうか、および要求されたアクションのオブジェクト (MBean または MBean 属性) が示されます。

表 4-6 コンフィグレーション監査の監査イベントの概要

発生したイベント 生成される監査イベント オブジェクト

新しいコンフィグレーション アーティファクトを作成するリクエストが許可または回避された。

 
weblogic.security.spi.AuditCreateConfigurationEvent

既存のコンフィグレーション アーティファクトを削除するリクエストが許可または回避された。

 
weblogic.security.spi.AuditDeleteConfigurationEvent

既存のコンフィグレーション アーティファクトを変更するリクエストが許可または回避された。

 
weblogic.security.spi.AuditInvokeConfigurationEvent

既存のコンフィグレーション アーティファクトに対するオペレーションの呼び出しが許可または回避された。

 
weblogic.security.spi.AuditSetAttributeConfigurationEvent

デフォルトの WebLogic Server 監査プロバイダを有効にすると、すべての監査イベントがログ メッセージとしてその独自のログ ファイルに書き込まれます。

作成または購入されたその他の監査プロバイダは、これらのイベントをフィルタ処理して、それらを LDAP サーバ、データベース、シンプル ファイルなどの出力リポジトリに書き出すことができます。さらに、他のタイプのセキュリティ プロバイダは、監査プロバイダからの監査サービスを要求できます。『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』の「監査プロバイダ」

WebLogic 資格マッピング プロバイダのコンフィグレーション

資格マッピングとは、リモート システム (既存のシステムやアプリケーションなど) の認証および認可メカニズムによって適切な資格セットを取得して、対象の WebLogic リソースにアクセスしようとするリモート ユーザを認証するプロセスです。WebLogic 資格マッピング プロバイダは、WebLogic Server サブジェクトを、リソースへのアクセス時に使用されるユーザ名とパスワードのペアにマップします。

デフォルトによって、WebLogic 資格マッピング プロバイダのコンフィグレーション オプションの大部分が定義されています。


注意 :

WebLogic Server では、[資格マッピング デプロイメントを有効化] オプションを使用して、この資格マッピング プロバイダがリソース アダプタのデプロイメント記述子 (weblogic-ra.xml ファイル) からセキュリティ レルムに資格マップをインポートするかどうかを指定できます。ただし、このオプションは現在では非推奨になっています。資格マップを weblogic-ra.xml ファイルからデプロイする方法は、WebLogic Server ではサポートされません。

[資格マッピング デプロイメントを有効化] をサポートするには、資格マッピング プロバイダに DeployableCredentialProvider SSPI を実装する必要があります。資格マッピング情報は組み込み LDAP サーバに格納されます。

詳細については、以下を参照してください。

PKI 資格マッピング プロバイダのコンフィグレーション

WebLogic Server の PKI (公開鍵インフラストラクチャ) 資格マッピング プロバイダは、WebLogic Server のサブジェクト (開始者) と対象リソース (および必要であれば資格アクション) を、対象リソースへのアクセス時にアプリケーションで使用できるキー ペアまたは公開証明書にマップします。PKI 資格マッピング プロバイダは、サブジェクトとリソース名を使用して対応する資格をキーストアから検索します。

PKI 資格マッピング プロバイダを使用するには、次の手順に従います。

  1. 適切なキーを持つキーストアをコンフィグレーションし、そのキーストアを WebLogic Server クラスタ内のすべてのマシンに配布します。キーストアのセットアップは、WebLogic Server の機能ではありません。キーストアの設定については、Java keytool ユーティリティのヘルプ (http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html) を参照してください。また、WebLogic Server のキーストアとキーについては、「ID と信頼のコンフィグレーション」を参照してください。

  2. PKI 資格マッピング プロバイダをコンフィグレーションします。PKI 資格マッピング プロバイダは、デフォルト セキュリティ レルム (myrealm) にはコンフィグレーションされていません。「PKI 資格マッピング属性」と、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「資格マッピング プロバイダのコンフィグレーション」を参照してください。

  3. 資格マッピングを作成します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「PKI 資格マッピングの作成」を参照してください。

PKI 資格マッピング属性

PKI 資格マッピング プロバイダをコンフィグレーションするには、以下の属性の値を設定します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「資格マッピング プロバイダのコンフィグレーション」を参照してください。

  • [キーストア プロバイダ] - Java Security API 用のキーストア プロバイダ。値が指定されていない場合、デフォルトのプロバイダ クラスが使用されます。

  • [キーストアの種類] - JKS (デフォルト) または PKCS12。

  • [キーストアのパスフレーズ] - キーストアへのアクセスに使用するパスワード。

  • [キーストア ファイル名] - サーバが起動したディレクトリを基準としたキーストアの場所。

さらに、以下の 2 つの属性を任意で指定すると、一致するリソースまたはサブジェクトが存在しない場合、PKI 資格マッピング プロバイダが資格マッピングをどのように検索するかを指定できます。

  • [リソース階層を使用] - リソースの種類ごとにリソース階層を上ることによって資格が検索されます。すべての PKI 資格の検索は特定のリソースから開始し、リソース階層を上ってすべての一致を見つけ出します。この属性はデフォルトで有効になっています。

  • [開始者のグループ名を使用] - サブジェクトが PKI 資格マッピング プロバイダに渡されると、開始者がメンバーであるグループを調べることによって資格が検索されます。デフォルトでは、これは有効になっています。

資格アクション

必要な場合、資格マッピングに資格アクションというラベルを付けることができます。これは、資格マッピングの作成時に Administration Console で行えます。資格アクションとは、さまざまな環境で使用される資格マッピングを区別する任意の文字列です。たとえば、ある資格マッピングでリモート リソースからのメッセージを復号化し、別の資格マッピングで同じリソースへ送られるメッセージに署名するとします。これらの 2 つの資格マッピングを区別するには、サブジェクト開始者と対象リソースでは不十分です。この場合、資格アクションを使用して、一方の資格マッピングに decrypt、他方に sign というラベルを付けます。こうすると、PKI 資格マッピング プロバイダを呼び出すコンテナが、目的の資格アクション値を ContextHandler に指定してプロバイダに渡せるようになります。

PKI 資格マッピングへの資格アクションの追加については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「PKI 資格マッピングの作成」を参照してください。

SAML 1.1 用の SAML 資格マッピング プロバイダのコンフィグレーション

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 マニュアルの「SAML 資格マッピング プロバイダのコンフィグレーション」(http://otndnld.oracle.co.jp/document/products/wls/docs90/secmanage/providers.html#SAML_cred) を参照してください。

WebLogic Server の SAML のサポートについては、『Oracle Fusion Middleware Oracle WebLogic Server Security について』の「SAML (Security Assertion Markup Language)」および「WebLogic Security フレームワークによるシングル サインオン」を参照してください。SAML 資格マッピング プロバイダを SAML シングル サインオン コンフィグレーションで使用する方法については、「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 セキュリティ アサーションのソースとして機能するようにコンフィグレーションする場合には、SAML アサーションの生成を要求できるパーティを登録する必要があります。各 SAML リライイング パーティに対して、使用する SAML プロファイル、そのリライイング パーティの詳細、およびそのリライイング パーティに対するアサーションで予想される属性を指定できます。詳細については、以下を参照してください。

SAML 2.0 用の SAML 2.0 資格マッピング プロバイダのコンフィグレーション

WebLogic Server に含まれている SAML 2.0 資格マッピング プロバイダは、以下の用途で ID をアサートするために使用できる SAML 2.0 アサーションを生成します。

表 4-7 に、SAML 2.0 資格マッピング プロバイダで生成されるアサーション タイプをまとめます。

表 4-7 SAML 2.0 資格マッピング プロバイダでサポートされるアサーション タイプ

アサーション タイプ 説明 
bearer

アサーションのサブジェクトはアサーションを伝達するベアラ。ただし、アサーションの <SubjectConfirmationData> 要素に含まれている属性を使用して確認を行うためのオプション制約が適用される。

SAML 2.0 Web ブラウザ SSO プロファイルおよび WS-Security SAML トークン プロファイル 1.1 で生成されるすべてのアサーションに使用する。

 
sender-vouches

サブジェクトとは異なる ID プロバイダが、サブジェクトの検証を保証する。受信側が ID プロバイダとの信頼関係を確立している必要がある。

WS-Security SAML トークン プロファイル 1.1 でのみ使用する。

 
holder-of-key

アサーション内で表現されるサブジェクトが、受信側で信頼されていない可能性のある X.509 証明書をサブジェクトで使用して、リクエスト メッセージの整合性を確保する。

WS-Security SAML トークン プロファイル 1.1 でのみ使用する。

WebLogic Server の SAML 2.0 のサポートについては、『Oracle Fusion Middleware Oracle WebLogic Server Security について』の「SAML (Security Assertion Markup Language)」および「WebLogic Security フレームワークによるシングル サインオン」を参照してください。SAML 2.0 資格マッピング プロバイダを SAML 2.0 シングル サインオン コンフィグレーションで使用する方法については、「Web ブラウザと HTTP クライアントによるシングル サインオンのコンフィグレーション」を参照してください。Web サービス用のサービス プロバイダ パートナ用に生成されたアサーションの確認方法の指定については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Security Assertion Markup Language (SAML) トークンの ID としての使用」を参照してください。

SAML 2.0 資格マッピング プロバイダの属性

SAML 2.0 資格マッピング プロバイダのコンフィグレーションは、SAML2CredentialMapperMBean の属性を設定することで制御できます。SAML2CredentialMapperMBean にアクセスするには、WebLogic Scripting Tool (WLST) を使用するか、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッピング] ページで SAML2CredentialMapper を作成または選択します。SAML2CredentialMapperMBean 属性の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server SAML 2.0 API Reference』の「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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SAML 2.0 Web サービス サービス プロバイダ パートナの作成」を参照してください。

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 <endpoint-url> に完全に一致するパートナを検索する。たとえば、target:-:http://www.avitek.com:7001/myserver/myservicecontext/myservice-endpoint の場合は、アサーションの生成に使用するサービス プロバイダに一致する可能性のあるエンドポイントを直接指定している。

この形式のパートナ検索文字列の場合、エンドポイント URL は、生成されるアサーションのオーディエンス URI としては追加されない。

 
target:+:<endpoint-url>

URL <endpoint-url> に完全に一致するパートナを検索する。

プラス記号 (+) を使用したパートナ検索文字列の場合は、エンドポイント URL が、このサービス プロバイダ パートナ用に生成されるアサーション内のオーディエンス URI として追加される。

 
target:*:<endpoint-url>

文字列の先頭のパターンが URL <endpoint-url> に一致するパートナを検索する。たとえば、target:*:http://www.avitek.com:7001/myserver の場合は、http://www.avitek.com:7001/myserver/contextA/endpointA や http://www.avitek.com:7001/myserver/contextB/endpointB など、http://www.avitek.com:7001/myserver で始まるすべてのエンドポイント URL が、このサービス プロバイダに一致する。

先頭の文字列パターンに一致するサービス プロバイダ パートナが複数見つかった場合は、一致した文字列パターンが最も長いパートナが選択される。

この形式のパートナ検索文字列の場合、エンドポイント URL は、生成されるアサーションのオーディエンス URI としては追加されない。


注意 :

実行時にサービス プロバイダ パートナが見つかるようにするため、1 つのパートナに 1 つ以上のパートナ検索文字列をコンフィグレーションする必要があります。パートナが見つからない場合、そのパートナのアサーションは生成できません。

target 検索プレフィックスを使用せずにエンドポイント URL をコンフィグレーションすると、従来のオーディエンス URI として扱われるため、このサービス プロバイダ パートナ用に生成するアサーションに必ずオーディエンス URI を含める必要があります (これにより、このパートナにコンフィグレーションされている既存のオーディエンス URI との下位互換性も確保できます)。

デフォルト パートナの指定

デフォルトのサービス プロバイダ パートナ エントリを指定したい場合は、1 つまたは複数のデフォルト パートナのオーディエンス URI エントリに、すべての target を対象とするワイルドカード一致を含めることができます。実際のワイルドカード URI は、Web サービス ランタイムが使用する特定の形式に合わせる必要があります。次に例を示します。

  • target:*:http://

  • target:*:https://

パートナ証明書の管理

SAML 2.0 資格マッピング プロバイダは、Web シングル サインオン用にコンフィグレーションされたパートナごとに、信頼性のある証明書を管理しています。パートナとメッセージを交換している間に署名付きの認証またはアーティファクト リクエストを受け取ると、信頼性のある証明書を使用してパートナの署名を検証します。パートナの証明書は、以下の用途に使用します。

  • SAML 2.0 資格マッピング プロバイダで署名付き認証リクエストまたはアーティファクト リクエストを受け取ったときに信頼性を検証するため

  • アーティファクト解決サービス (ARS) から SSL 接続経由で SAML アーティファクトを取得しているサービス プロバイダ パートナの信頼性を検証するため

Administration Console では、コンフィグレーションした SAML 2.0 資格マッピング プロバイダのパートナ管理ページで、Web シングル サインオン サービス プロバイダ パートナの署名用証明書とトランスポート層クライアント証明書を表示できます。

サービス プロバイダ パートナの属性をコンフィグレーションするための Java インタフェース

Web サービスで使用できるオペレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server API Reference』の com.bea.security.saml2.providers.registry.Partner Java インタフェースを参照してください。

証明書検索および検証フレームワークのコンフィグレーション

WebLogic Server は、Web サービス リクエスト、双方向 SSL、または他の保護された対話の一部としてデジタル証明書を受け取る場合があります。これらの証明書を検証するために、WebLogic Server には証明書検索および検証 (CLV) フレームワークが組み込まれています。このフレームワークの役割は、X.509 証明書チェーンを検索および検証することです。CLV フレームワークの主要な要素は、証明書パス ビルダと証明書パス検証プロバイダです。CLV フレームワークでは、証明書チェーンへの参照が与えられている場合、そのチェーンを見つけて検証する 1 つ (および唯一) のアクティブな証明書パス ビルダと、証明書チェーンを検証するゼロまたは 1 つ以上の証明書パス検証プロバイダが必要です。

WebLogic Server が証明書を受け取ると、CLV フレームワークは、証明書パス ビルダとしてコンフィグレーションされているセキュリティ プロバイダを使用して証明書チェーンを検索および検証します。証明書チェーンを検索および検証したら、コンフィグレーションされている各証明書パス検証プロバイダをコンフィグレーションされた順に呼び出して、証明書チェーンをさらに検証します。証明書パス ビルダとすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。

チェーンが有効になるのは、以下のすべての条件が true の場合です。

WebLogic Server には、2 種類の CLV セキュリティ プロバイダが用意されています。証明書パス ビルダと証明書パス検証プロバイダの両方として機能する WebLogic 証明書パス プロバイダ (「証明書パス プロバイダ」を参照) と、証明書レジストリ (「証明書レジストリ」を参照) です。WebLogic 証明書パス プロバイダは、証明書チェーン全体に対して信頼性のある CA ベースの検証を行う場合に使用します。証明書レジストリは、証明書が登録されているかどうかだけを検証する場合に使用します。どちらの検証も行う場合、両方を使用します (証明書レジストリを現在のビルダとして指定する)。

証明書の検索と検証の詳細については、「ID と信頼のコンフィグレーション」を参照してください。

証明書パス プロバイダ

WebLogic Server のデフォルト セキュリティ レルムには、WebLogic 証明書パス プロバイダがコンフィグレーションされます。この証明書パス プロバイダには、証明書パス ビルダと証明書パス検証プロバイダという 2 つの機能があります。証明書パス プロバイダは、目的の証明書または証明書チェーンを受け取ります。必要な場合、サーバの信頼性のある CA のリストを使用して証明書チェーンを完成させます。チェーンの作成後、証明書パス プロバイダはチェーンを検証します。つまり、チェーン内の署名、チェーンの期限切れ、チェーンの基本制約、およびチェーンがサーバの信頼性のある CA の 1 つによって発行された証明書で終了していることをチェックします。

WebLogic 証明書パス プロバイダのコンフィグレーションは必要ありません。ただし、[現在のビルダ] 属性を使用して、証明書パス プロバイダをアクティブな証明書チェーン ビルダとして使用するかどうかを指定できます。

証明書レジストリ

証明書レジストリは、WebLogic Server へのアクセスが許可されている信頼性のある証明書のリストを明示的に登録できるセキュリティ プロバイダです。証明書レジストリをセキュリティ レルムの一部としてコンフィグレーションした場合、その証明書レジストリに登録されている証明書だけが有効であると見なされます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。証明書レジストリから証明書を削除することによって、証明書を即座に無効にできます。このレジストリは、組み込み LDAP サーバに格納されます。

証明書レジストリは、証明書パス ビルダと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証しますが、それ以外の検証は行いません。証明書レジストリをセキュリティ レルムの証明書パス ビルダとして使用し、WebLogic 証明書パス プロバイダまたは別のセキュリティ プロバイダを使用してチェーン全体の検証を行う場合、各サーバの信頼性のあるキーストアに中間およびルート CA を登録し、証明書レジストリに目的の証明書を登録する必要があります。

WebLogic Server のデフォルト セキュリティ レルムには、証明書レジストリは含まれていません。証明書レジストリをコンフィグレーションしたら、WebLogic Administration Console を使用してレジストリの証明書を追加、削除、および参照できます。Java keytool ユーティリティを使用すると、証明書をキーストアからファイルにエクスポートできます。Administration Console を使用すると、PEM または DER ファイルの証明書をファイル システムから証明書レジストリにインポートできます。また、Administration Console では、証明書の内容 (サブジェクト DN、発行者 DN、シリアル番号、有効日、フィンガープリントなど) を参照できます。

Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「証明書パス プロバイダのコンフィグレーション」を参照してください。

WebLogic キーストア プロバイダのコンフィグレーション


注意 :

WebLogic キーストア プロバイダは非推奨になりました。下位互換性のためにのみサポートされています。代わりに Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、Java キーストアを使用することで利用できます。

WebLogic キーストア プロバイダのコンフィグレーションについては、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「キーストアのコンフィグレーション」を参照してください。

  戻る
戻る 		 次へ
次へ
 

目次
目次