Oracle® Fusion Middleware

Oracle WebLogic Server 10.3.6の保護

11g リリース1 (10.3.6)

B61617-11(原本部品番号:E13707-14)

2017年7月

このドキュメントでは、セキュリティ・レルム、プロバイダ、IDと信頼、SSL、互換性セキュリティの設定など、WebLogic Server 10.3.6でセキュリティを構成する方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server 10.3.6の保護, 11gリリース1 (10.3.6)

B61617-11

Copyright © 2007, 2017, Oracle and/or its affiliates. All rights reserved.

原本著者: Oracle Corporation

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- WebLogic Server配布キットのセキュリティ・サンプル

- ダウンロード可能な他のサンプル

- セキュリティに関する新機能と変更点

2 セキュリティ管理の概要

- WebLogic Serverのセキュリティ・レルム

- セキュリティ・プロバイダ

- セキュリティ・ポリシーとWebLogicリソース

- WebLogicリソース

- デプロイメント記述子とWebLogic Server管理コンソール

- WebLogic Serverのデフォルト・セキュリティ構成

- WebLogicセキュリティの構成: 主な手順

- セキュリティの構成方法

- 互換性セキュリティとは

- 互換性セキュリティで実行できる管理タスク

3 デフォルト・セキュリティ構成のカスタマイズ

- デフォルト・セキュリティ構成をカスタマイズする理由

- 新しいセキュリティ・レルムを作成する前に

- 新しいセキュリティ・レルムの作成と構成: 主な手順

4 WebLogicセキュリティ・プロバイダの構成

- セキュリティ・プロバイダを構成する必要がある場合

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

- デプロイメント時のセキュリティ・ポリシーとロール変更の同期を有効化

- 認可プロバイダの構成

- WebLogic裁決プロバイダの構成

- ロール・マッピング・プロバイダの構成

- WebLogic監査プロバイダの構成

- 監査ContextHandler要素

- 構成監査

- 構成監査の有効化

- 構成監査メッセージ

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

- WebLogic資格証明マッピング・プロバイダの構成

- PKI資格証明マッピング・プロバイダの構成

- PKI資格証明マッピング属性

- 資格証明アクション

- SAML 1.1用のSAML資格証明マッピング・プロバイダの構成

- アサーションの存続期間の構成

- リライイング・パーティ・レジストリ

- SAML 2.0用のSAML 2.0資格証明マッピング・プロバイダの構成

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

- サービス・プロバイダ・パートナ

- Webサービス・パートナに必要なパートナ・ルックアップ文字列

- パートナ証明書の管理

- サービス・プロバイダ・パートナの属性を構成するためのJavaインタフェース

- 証明書ルックアップおよび検証フレームワークの構成

- 証明書パス・プロバイダ

- 証明書レジストリ

- WebLogicキーストア・プロバイダの構成

5 認証プロバイダの構成

- 認証プロバイダの選択

- 複数の認証プロバイダの使用

- JAAS制御フラグ・オプションの設定

- 認証プロバイダの順序の変更

- WebLogic認証プロバイダの構成

- ユーザー属性の設定

- LDAP認証プロバイダの構成

- WebLogic Serverに含まれるLDAP認証プロバイダ

- LDAP認証プロバイダを使用するための要件

- LDAP認証プロバイダの構成: 主な手順

- 他のLDAPサーバーへのアクセス

- SSL用のLDAP認証プロバイダの有効化

- 動的グループとWebLogic Server

- WebLogicプリンシパルでのGUIDおよびLDAP DNデータの使用

- Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでの
ユーザーおよびグループの構成

- ユーザーおよびグループの名前タイプの構成

- 静的グループの構成

- LDAP認証プロバイダのフェイルオーバーの構成

- LDAPフェイルオーバーの例1

- LDAPフェイルオーバーの例2

- Oracle Unified Directory用認証プロバイダの構成

- Active Directory認証プロバイダの参照への遵守

- WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上

- グループ・メンバーシップ・キャッシュの最適化

- 接続プール・サイズとユーザー・キャッシュの最適化

- iPlanet認証プロバイダでの動的グループの構成によるパフォーマンスの向上

- プリンシパル検証プロバイダ・キャッシュの最適化

- Active Directory認証プロバイダの構成によるパフォーマンスの向上

- 外部LDAPサーバーからの管理者ユーザーの構成: 例

- RDBMS認証プロバイダの構成

- 一般的なRDBMS認証プロバイダ属性

- データ・ソース属性

- グループ検索属性

- グループ・キャッシング属性

- SQL認証プロバイダの構成

- パスワード属性

- SQL文属性

- 読取り専用SQLオーセンティケータの構成

- カスタムDBMSオーセンティケータの構成

- プラグイン・クラス属性

- Windows NT認証プロバイダの構成

- ドメイン・コントローラの設定

- LogonTypeの設定

- UPN名の設定

- SAML認証プロバイダの構成

- パスワード検証プロバイダの構成

- パスワード検証プロバイダのパスワード構成ルール

- パスワード検証プロバイダとWebLogic認証プロバイダの併用

- LDAP認証プロバイダでのパスワード検証プロバイダの使用

- WLSTを使用したパスワード検証プロバイダの作成と構成

- パスワード検証プロバイダのインスタンスの作成

- パスワード構成ルールの指定

- IDアサーション・プロバイダの構成

- LDAP X509 IDアサーション・プロバイダの仕組み

- LDAP X509 IDアサーション・プロバイダの構成: 主な手順

- ネゴシエーションIDアサーション・プロバイダの構成

- SAML 1.1用のSAML IDアサーション・プロバイダの構成

- アサーティング・パーティ・レジストリ

- 証明書レジストリ

- SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成

- IDプロバイダ・パートナ

- サーブレットに対するIDアサーションの順序付け

- サーバー・キャッシュのIDアサーション・パフォーマンスの構成

- ユーザー名マッパーの構成

- カスタム・ユーザー名マッパーの構成

6 Microsoftのクライアントに対するシングル・サインオンの構成

- Microsoftのクライアントに対するシングル・サインオンの概要

- Microsoftのクライアントを含むSSOに必要なシステム要件

- MicrosoftクライアントでSSOをサポートするためのホスト・コンピュータの要件

- SSOを使用するMicrosoftクライアントをサポートするためのクライアント・コンピュータの要件

- Microsoftのクライアントに対するシングル・サインオン: 主な手順

- Kerberosを使用するためのネットワーク・ドメインの構成

- WebLogic Server用のKerberos識別情報の作成

- ステップ1: ホスト・コンピュータのユーザー・アカウントの作成

- ステップ2: Kerberosに準拠するユーザー・アカウントの構成

- ステップ3: サービス・プリンシパル名の定義とサービスのキータブの作成

- WindowsシステムでのSPNの定義とキータブの作成

- UNIXシステムでのSPNの定義とキータブの作成

- ステップ4: 正しい設定の検証

- ステップ5: デフォルトのJDKセキュリティ・ポリシー・ファイルの更新

- Microsoftのクライアントで統合Windows認証を使用するための構成

- .NET Webサービスの構成

- Internet Explorerブラウザの構成

- ローカル・イントラネット・ドメインの構成

- イントラネット認証の構成

- プロキシ設定の検証

- Internet Explorer 6.0用の統合認証の設定

- Mozilla Firefoxブラウザの構成

- Java SEクライアント・アプリケーションの構成

- JAASログイン・ファイルの作成

- IDアサーション・プロバイダの構成

- WebLogic ServerでのKerberos認証における起動引数の使用

- Microsoftのクライアントに対するSSOの構成の検証

7 WebブラウザとHTTPクライアントによるシングル・サインオンの構成

- SAMLホワイト・ペーパーを使用したシングル・サインオンの構成

- Webシングル・サインオン・シナリオ用SAMLのAPIサンプル

- SAML 1.1サービスの構成

- SAML 1.1でのシングル・サインオンの有効化: 主な手順

- ソース・サイトの構成: 主な手順

- 宛先サイトの構成: 主な手順

- シングル・サインオン用のSAML 1.1ソース・サイトの構成

- SAML 1.1資格証明マッピング・プロバイダの構成

- ソース・サイト・フェデレーション・サービスの構成

- リライイング・パーティの構成

- デフォルトのアサーション・ストアの置換え

- シングル・サインオン用のSAML 1.1宛先サイトの構成

- SAML IDアサーション・プロバイダの構成

- 宛先サイト・フェデレーション・サービスの構成

- アサーティング・パーティの構成

- WLSTを使用したリライイング・パーティとアサーティング・パーティの構成

- SAML 2.0サービスの構成

- SAML 2.0サービスの構成: 主な手順

- SAML 2.0全般サービスの構成

- SAML 2.0全般サービスについて

- メタデータ・ファイルの公開と配布

- SAML 2.0シングル・サインオン用のIDプロバイダ・サイトの構成

- SAML 2.0資格証明マッピング・プロバイダの構成

- SAML 2.0 IDプロバイダ・サービスの構成

- Webシングル・サインオン・サービス・プロバイダ・パートナの作成と構成

- SAML 2.0シングル・サインオン用のサービス・プロバイダ・サイトの構成

- SAML 2.0 IDアサーション・プロバイダの構成

- SAML認証プロバイダの構成

- SAML 2.0全般サービスの構成

- SAML 2.0サービス・プロバイダ・サービスの構成

- Webシングル・サインオンIDプロバイダ・パートナの作成と構成

- パートナ・サイト、証明書、サービス・エンドポイント情報の表示

- SAML 2.0におけるWebアプリケーション・デプロイメントの考慮事項

- デプロイメント記述子に関する推奨事項

- クラスタ環境におけるログイン・アプリケーションの考慮事項

- 強制認証とパッシブ属性の有効化による無効な構成

- SAML 1.1および2.0のデバッグの有効化

- SAMLデバッグ・スコープおよび属性について

- コマンドラインを使用してデバッグの有効化

- WebLogic Server管理コンソールを使用してデバッグの有効化

- WebLogic Scripting Toolを使用してデバッグの有効化

- 標準出力へのデバッグ・メッセージの送信

8 セキュリティ・データの移行

- セキュリティ・データ移行の概要

- 移行の概念

- WebLogicセキュリティ・プロバイダでサポートされるフォーマットと制約

- WLSTを使用したデータの移行

9 組込みLDAPサーバーの管理

- 組込みLDAPサーバーの構成

- 組込みLDAPサーバーのレプリケーション

- LDAPブラウザからの組込みLDAPサーバーの内容の表示

- 組込みLDAPサーバーの情報のエクスポートおよびインポート

- LDAPアクセス制御の構文

- アクセス制御ファイル

- アクセス制御の場所

- アクセス制御のスコープ

- アクセス権

- 属性の権限

- エントリの権限

- 属性タイプ

- サブジェクト・タイプ

- 評価ルールの付与または拒否

- バックアップおよびリカバリ

10 RDBMSセキュリティ・ストアの管理

- RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダ

- RDBMSセキュリティ・ストアの構成

- RDBMSセキュリティ・ストアを使用するドメインの作成

- データベース接続プロパティの指定

- データベース接続のテスト

- セキュリティ・データ・ストア内でのRDBMS表の作成

- RDBMSセキュリティ・ストアのJMSトピックの構成

- 障害発生時のJMS接続リカバリの構成

- RDBMSセキュリティ・ストアを使用するドメインのアップグレード

11 IDと信頼の構成

- 秘密鍵、デジタル証明書、信頼性のある認証局

- IDと信頼のサポートされるフォーマット

- IDキーストアと信頼キーストア

- WebLogic Serverが信頼を検索する方法

- IDと信頼の構成: 主な手順

- 秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得

- keytoolユーティリティの使い方

- CertGenユーティリティの使い方

- 独自の認証局の使い方

- Microsoft p7bフォーマットからPEMフォーマットへの変換

- Webブラウザのデジタル証明書の取得

- 証明書チェーンの使い方(非推奨)

- 秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納

- デモンストレーション用キーストアの使用

- キーストアの作成および秘密鍵と証明書の読込みに使用するツールとユーティリティ

- クライアントのデモ証明書の構成

- WebLogic Server用のIDおよび信頼キーストアの構成

- 本番用のキーストアの構成

- WebLogicキーストア・プロバイダによってアクセスされるファイルまたは
JKSキーストアに保存される鍵と証明書の構成

- キーストアの作成: サンプル

- 証明書コールバック・ハンドラを使用したエンド・ユーザー証明書の検証

- エンド・ユーザー証明書コールバック・ハンドラが機能する仕組み

- 証明書コールバック実装の作成

- WebLogic Serverを使用した証明書コールバックの構成

12 SSLの構成

- SSLの概要

- 一方向および双方向SSL

- サポートされるJava Secure Socket Extension (JSSE) SSL実装

- SSLの設定: 主な手順

- ホスト名検証の使い方

- デフォルトのWebLogic Serverホスト名検証の使用

- ワイルドカードのあるホスト名検証の使用

- ワイルドカードのあるホスト名検証の仕組み

- ワイルドカードのあるホスト名検証の構成

- カスタム・ホスト名検証の使用

- アウトバウンド双方向SSL接続のクライアント証明書の指定

- SSLのデバッグ

- SSLデバッグを有効化するためのコマンド・ライン・プロパティ

- JSSE使用時のSSLデバッグ

- SSL構成後におけるWebLogic Serverの起動の失敗

- SSLセッションの動作

- SSLを使用したRMI over IIOPの構成

- SSL証明書の検証

- 証明書検証のレベルの制御

- 証明書の証明書ポリシーの受け入れ

- 証明書チェーンのチェック

- 証明書ルックアップと検証のプロバイダ

- WebLogic ServerでのSSL証明書検証の動作

- 証明書検証に関する問題のトラブルシューティング

- WebLogic ServerでのnCipher JCEプロバイダの使い方

- SSLプロトコルのバージョンの指定

- weblogic.security.SSL.protocolVersionシステム・プロパティの使用

- weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用

- JSSEベースのSSL実装で有効なプロトコル

- CerticomベースのSSL実装で有効なプロトコル

- JSSEベースSSL実装の使用

- JSSEベースSSL実装の有効化と無効化

- 管理コンソールからのWebLogic Server用JSSEベースSSLの有効化/無効化

- weblogic.ssl.JSSEEnabledシステム・プロパティからのWebLogic Server用
JSSEベースSSL実装の有効化/無効化

- プログラムによるWebLogic Server用JSSEベースSSL実装の有効化/無効化

- スタンドアロン・クライアント用JSSEベースSSL実装の有効化/無効化

- JSSEベース実装とCerticom SSL実装とのシステム・プロパティの相違

- 暗号スイート

- サポートされる暗号スイートのリスト

- サポートされる暗号スイートの後方互換性

- 暗号スイート名の等価物

- WLSTを使用した暗号スイートの設定: サンプル

- JSSE SSLでのデバッグの使用

- X.509証明書失効チェック

- 証明書失効チェックの概要

- デフォルトのCRチェック構成の有効化

- デフォルトのCRチェックの構成

- CRチェック構成のカスタマイズ

- WebLogic Serverで使用するCRチェック方法の選択

- 失効ステータスを特定できない場合のSSL証明書パス検証の失敗

- Online Certificate Status Protocolの使用

- OCSPリクエストでのNonceの使用

- レスポンス・タイムアウト時間の設定

- OCSPレスポンス・ローカル・キャッシュの有効化および構成

- 証明書失効リストの使用

- 配布ポイントからの更新の有効化

- CRLローカル・キャッシュの構成

- 認証局オーバーライドの構成

- 一般的な認証局オーバーライド

- 認証局オーバーライドのOCSPプロパティの構成

- 認証局オーバーライドのCRLプロパティの構成

13 WebLogicドメインのセキュリティの構成

- クロス・ドメイン・セキュリティのサポートに関する重要な情報

- WebLogic Serverドメイン間の信頼関係の有効化

- WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化

- クロス・ドメイン・セキュリティの構成

- クロス・ドメイン・ユーザーの構成

- クロス・ドメイン・セキュリティ用の資格証明マッピングの構成

- グローバル信頼の有効化

- 接続フィルタの使用

- Java Authorization Contract for Containersの使用

- MBean属性の表示

- WebLogic Serverでのパスワードの保護の仕組み

- ユーザー・アカウントの保護

- JAAS認可を使用するドメインの構成

14 互換性セキュリティの使い方

- 互換性セキュリティの実行: 主な手順

- 互換性セキュリティMBeanの可視性制限

- CompatibilityRealmのデフォルト・セキュリティ構成

- レルム・アダプタ認証プロバイダの構成

- レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成

- レルム・アダプタ監査プロバイダの構成

- 互換性セキュリティでのユーザー・アカウントの保護

- 互換性セキュリティからの6.xセキュリティへのアクセス

15 セキュリティ構成MBean

- SSLMBean

- ServerMBean

- EmbeddedLDAPMBean

- RDBMSSecurityStoreMBean

- SecurityMBean

- SecurityConfigurationMBean

- RealmMBean

- WindowsNTAuthenticatorMBean

- CustomDBMSAuthenticatorMBean

- ReadonlySQLAuthenticatorMBean

- SQLAuthenticatorMBean

- DefaultAuditorMBean

- 互換性セキュリティMBean

- UserLockoutManagerMBean

- その他のセキュリティ・プロバイダMBean

A FIPSモードの有効化

- FIPSの概要

- サポートされるFIPS標準と暗号スイート

- JavaオプションでのFIPS 140-2モードの有効化

- java.securityでのFIPS 140-2モードの有効化

- FIPS 140-2モード有効時のJCEの検証

- Webサービスを使用する際の重要な考慮事項

- SHA-1セキュア・ハッシュ・アルゴリズムのサポートなし

- X509PKIPathv1トークンのサポートなし

はじめに

ここでは、このガイド『Oracle WebLogic Server 10.3.6の保護』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド『WebLogic Serverの保護』の内容と構成について説明し、WebLogic Server 10.3.6でのセキュリティに関する新機能と変更点を紹介します。

この章の内容は次のとおりです。

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- セキュリティに関する新機能と変更点

ドキュメントのスコープ

このドキュメントでは、セキュリティ・レルム、プロバイダ、IDと信頼、SSL、互換性セキュリティの設定など、WebLogic Serverのセキュリティを構成する方法について説明します。WebLogicのセキュリティに関するその他のドキュメントについては、「関連ドキュメント」を参照してください。

対象読者

このドキュメントは、以下の読者を対象としています。

- アプリケーション設計者 - セキュリティの目標を設定し、組織の全体的なセキュリティ・アーキテクチャを設計するだけでなく、WebLogic Serverのセキュリティ機能を評価して最適な実装方法を判断する設計者のことです。アプリケーション設計者は、セキュリティ・システムや最先端のセキュリティ技術とツールだけでなく、Javaプログラミング、Javaセキュリティ、およびネットワーク・セキュリティにも精通しています。

- セキュリティ開発者 - WebLogic Serverに統合されるセキュリティ製品のシステム・アーキテクチャとインフラストラクチャを定義し、WebLogic Serverで使用するカスタム・セキュリティ・プロバイダを開発する開発者のことです。アプリケーション設計者と連携して、セキュリティ・アーキテクチャを確実に設計に従って、セキュリティ・ホールが発生しないように実装します。また、セキュリティが確実に正しく構成されるよう、サーバー管理者とも連携します。セキュリティ開発者は、認証、認可、監査(AAA)、Java Management eXtension (JMX)などのJavaに対する深い知識、およびWebLogic Serverとセキュリティ・プロバイダの機能に対する実践的な知識といったセキュリティ概念をしっかりと理解しています。

- アプリケーション開発者 - クライアント・アプリケーションの開発、WebアプリケーションおよびEnterprise JavaBeans (EJB)へのセキュリティ機能の付加、および他のエンジニアリング・チーム、品質保証(QA)チーム、データベース・チームとの連携によるセキュリティ機能の実装などを主な業務とするJavaプログラマのことです。アプリケーション開発者は、Java (サーブレット、JSP、JSEEなどのJava EEコンポーネントを含む)とJavaセキュリティについての実用的かつ深い知識を備えています。

- サーバー管理者 - アプリケーション設計者と密接に連携しながら、サーバーおよびサーバー上で動作するアプリケーションのセキュリティ方式の設計、潜在的なセキュリティ・リスクの特定、およびセキュリティ上の問題を防止する構成の提案を行います。関連する責務として、重要な本番システムの保守、セキュリティ・レルムの構成と管理、サーバー・リソースとアプリケーション・リソースへの認証および認可方式の実装、セキュリティ機能のアップグレード、およびセキュリティ・プロバイダのデータベースの保守などが含まれる場合もあります。サーバー管理者は、Webサービス、WebアプリケーションとEJBのセキュリティ、公開鍵セキュリティ、SSL、SAML (Security Assertion Markup Language)を含むJavaセキュリティ・アーキテクチャに関する深い知識を備えています。

- アプリケーション管理者 - サーバー管理者と共同でセキュリティ構成や、認証および認可方式を実装および管理したり、定義されたセキュリティ・レルムでデプロイされたアプリケーション・リソースへのアクセスを設定および管理したりします。アプリケーション管理者は、セキュリティの概念やJavaセキュリティ・アーキテクチャの一般的な知識を備えています。また、Java、XML、デプロイメント記述子を理解し、サーバー・ログおよび監査ログでセキュリティ・イベントを特定できます。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- この章では、このマニュアルの対象読者、構成、および関連情報について説明します。

- 第2章「セキュリティ管理の概要」では、WebLogic Serverのデフォルト・セキュリティ構成、セキュリティの構成手順および互換性セキュリティについて説明します。

- 第3章「デフォルト・セキュリティ構成のカスタマイズ」では、いつデフォルトのセキュリティ構成をカスタマイズするか、新しいセキュリティ・レルムの構成要件、およびセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定する方法について説明します。

- 第4章「WebLogicセキュリティ・プロバイダの構成」では、WebLogic Serverのセキュリティ・プロバイダの構成オプションと、カスタム・セキュリティ・プロバイダを構成する方法について説明します。

- 第5章「認証プロバイダの構成」では、WebLogic Serverの認証プロバイダとその構成方法について説明します。

- 第6章「Microsoftのクライアントに対するシングル・サインオンの構成」では、SPNEGO (Simple and Protected Negotiate)メカニズムに基づいたWindows認証を使用して、Microsoftドメインの.NET Webサービス・クライアントまたはブラウザ・クライアント(Internet Explorerなど)とWebLogicドメインとの間の認証を構成する方法について説明します。

- 第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」では、SAML (Security Assertion Markup Language)に基づいた認証を使用して、WebLogicドメインとWebブラウザまたは他のHTTPクライアントの間の認証を構成する方法について説明します。

- 第8章「セキュリティ・データの移行」では、セキュリティ・レルムとセキュリティ・プロバイダの間でセキュリティ・データをエクスポートおよびインポートする方法について説明します。

- 第9章「組込みLDAPサーバーの管理」では、WebLogicセキュリティ・プロバイダによって使用される組込みLDAPサーバーに関連する管理タスクについて説明します。

- 第10章「RDBMSセキュリティ・ストアの管理」では、RDBMSセキュリティ・ストアを構成する手順について説明します。RDBMSセキュリティ・ストアには、組込みLDAPサーバーではなく、外部のRDBMSシステムの様々なセキュリティ・プロバイダで管理するセキュリティ・データを格納できます。RDBMSセキュリティ・ストアは、クラスタ環境のようにドメイン内に複数のサーバーが構成されている場合に、SAML 2.0サービスで使用します。

- 第11章「IDと信頼の構成」では、WebLogic ServerのIDと信頼を構成する方法について説明します。

- 第12章「SSLの構成」では、WebLogic ServerのSSLを構成する方法について説明します。

- 第13章「WebLogicドメインのセキュリティの構成」では、WebLogicドメインのセキュリティ構成オプションを設定する方法について説明します。

- 第14章「互換性セキュリティの使い方」では、WebLogic Server 6.xで開発されたセキュリティ・レルムとの後方互換性を保持するためのセキュリティ構成モードである互換性セキュリティの使用方法について説明します。

- 第15章「セキュリティ構成MBean」では、WebLogicセキュリティMBeanやMBean属性のうち、どれが動的(サーバーを再起動せずに変更可能)で、どれが動的でない(変更にサーバーの再起動が必要)かについて説明します。

関連情報

以下のOracle Oracle Fusion Middlewareドキュメントには、WebLogicセキュリティ・サービスに関する情報が記載されています。

- 『Oracle WebLogic Serverセキュリティの理解』 - WebLogicセキュリティ・サービスの機能の概要で、このサービスのアーキテクチャと働きについて説明します。WebLogicセキュリティを理解するための基礎となるドキュメントです。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』 - セキュリティ・ベンダーとアプリケーション開発者に対して、WebLogic Serverで使用できるカスタム・セキュリティ・プロバイダを開発するために必要な情報を提供します。

- 『Oracle WebLogic Server本番環境の保護』 - 本番環境にWebLogic Serverをデプロイする前に考慮する不可欠なセキュリティ手法について説明します。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 - 様々なタイプのWebLogicリソースを紹介し、WebLogic Serverを使用してそれらのリソースを保護するための情報を提供します。このドキュメントでは、URL (Web)リソースとEnterprise JavaBean (EJB)リソースのセキュリティについて重点的に説明します。

- 『Oracle WebLogic Serverセキュリティのプログラミング』 - Webアプリケーションのセキュリティを開発する方法について説明します。

- 『Oracle WebLogic Server WebLogic Webサービスの保護』 - セキュアなWebサービスを開発および構成する方法について説明します。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ - Oracle WebLogic Serverの管理コンソールを使用して、様々なセキュリティ構成タスクを実行できます。このオンライン・ヘルプでは、構成手順と構成可能な属性について説明します。

- 『Oracle WebLogic Serverアップグレード・ガイド』 - 旧バージョンのWebLogic Serverからこのリリースにアップグレードするために必要な手順などの情報を提供します。また、旧バージョンのWebLogic Serverからこのリリースへのアプリケーションの移行に関する情報も提供します。WebLogic Serverセキュリティのアップグレードの詳細は、『Oracle WebLogic Serverアップグレード・ガイド』のセキュリティ・プロバイダのアップグレードに関する項を参照してください。

- Oracle WebLogic Server APIリファレンス - このリリースのWebLogic Serverに付属している、サポート対象のWebLogicセキュリティ・パッケージのリファレンス・ドキュメントです。

セキュリティのサンプルとチュートリアル

「関連情報」に示したドキュメントの他にも、開発者向けに各種のサンプル・コードが提供されています。一部はWebLogic Serverに付属していますが、Oracle Technology Network (OTN)にも様々なサンプルが用意されています。OTNは、http://www.oracle.com/technetwork/indexes/samplecode/index.htmlからアクセスできます。

WebLogic Server配布キットのセキュリティ・サンプル

WebLogic Serverでは、任意でAPIサンプル・コードをWL_HOME\samples\server\examples\src\examples\securityにインストールできます。WL_HOMEはWebLogic Serverのインストール先の最上位ディレクトリを示します。サンプルをインストールするには、WebLogic Serverのインストール時に「カスタム」インストール・オプションを選択して、Serverサンプル・チェック・ボックスが選択されていることを確認します。

サンプル・サーバーを起動して、サンプルに関する情報や、WebLogic Serverの「起動」メニューからサンプルを実行する方法を取得できます。

WebLogicのセキュリティ機能については、次のサンプルを参照してください。

- Java認証および認可サービス

- アウトバウンドおよび双方向SSL

ダウンロード可能な他のサンプル

WebLogic Serverのその他のセキュリティ・サンプルは、Oracle Technology Network (OTN)(http://www.oracle.com/technetwork/indexes/samplecode/index.html)からダウンロードできます。これらのサンプルは、WebLogic Serverの既存のサンプル・ディレクトリ構造に解凍できる.zipファイルで配布されます。

ダウンロード可能なサンプルの構築と実行方法は、インストールされているWebLogic Serverのサンプルと同様です。詳細は、各サンプルのダウンロード・ページを参照してください。

セキュリティに関する新機能と変更点

バンドルされているパッチをインストールすると、WebLogic ServerのJSSEおよびJDK 7に対するFIPS 140-2のサポートが使用可能になります。これはデフォルトでは使用できません。詳細は、付録A「FIPSモードの有効化」を参照してください。

WebLogic Serverのこのリリースに追加された新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 セキュリティ管理の概要

この章では、WebLogic Server 10.3.6のセキュリティ・システムの基本機能について説明します。より広範囲の概要については、『Oracle WebLogic Serverセキュリティの理解』を参照してください。

この章の内容は以下のとおりです。

- WebLogic Serverのセキュリティ・レルム

- セキュリティ・プロバイダ

- セキュリティ・ポリシーとWebLogicリソース

- WebLogic Serverのデフォルト・セキュリティ構成

- WebLogicセキュリティの構成: 主な手順

- セキュリティの構成方法

- 互換性セキュリティとは

注意:
このドキュメントでは、6.xという用語はWebLogic Server 6.0および6.1、およびそれらに関連付けられたサービス・パックを表します。

WebLogic Serverのセキュリティ・レルム

WebLogic Serverのセキュリティ・サービスは、セキュリティの構成と管理を簡素化しながらも、WebLogic Serverデプロイメントを保護する堅牢な機能を提供します。セキュリティ・レルムは、スコーピング(有効範囲の設定)メカニズムとして機能します。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。1つのドメインに複数のセキュリティ・レルムを構成できますが、アクティブなセキュリティ・レルムに指定できるのはそのうちの1つだけです。WebLogic Serverには、以下の2つのデフォルト・セキュリティ・レルムが用意されています。

- myrealm - WebLogicの裁決、認証、IDアサーション、認可、ロール・マッピング、および資格証明マッピングの各プロバイダがデフォルトで構成されています。

- CompatibilityRealm - 6.xのセキュリティ構成との後方互換性を提供します。既存の6.xセキュリティ構成にはCompatibilityRealmを介してアクセスできます。

新しいセキュリティ・レルムを構成して認証機能と認可機能をカスタマイズし、必要なセキュリティ・サービスを用意します。次に、その新しいセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定します。

WebLogic Serverのデフォルト・セキュリティ構成については、「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。

セキュリティ・レルムを構成してデフォルト・セキュリティ・レルムに設定する方法については、第3章「デフォルト・セキュリティ構成のカスタマイズ」を参照してください。

互換性セキュリティの詳細は、第14章「互換性セキュリティの使い方」を参照してください。

セキュリティ・プロバイダ

セキュリティ・プロバイダは、認証や認可など、セキュリティの特定の側面を処理するモジュール・コンポーネントです。アプリケーションではデフォルトのWebLogicセキュリティ・プロバイダでサービスを利用できますが、WebLogicセキュリティ・サービスのインフラストラクチャは柔軟性が高いので、セキュリティ・ベンダーで独自のカスタム・セキュリティ・プロバイダをWebLogic Server用に作成することもできます。WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダを適宜組み合せて独自のセキュリティ・ソリューションを構築することができるので、ある分野では新たな技術の進歩を利用しつつ、それ以外の分野では実証済みの手法を堅持できるようになります。WebLogic管理コンソールを使用すると、統合された単一の管理インタフェースを通じてすべてのセキュリティ・プロバイダを管理できます。

WebLogicセキュリティ・サービスは、以下のセキュリティ・プロバイダをサポートしています。

- 認証 - ユーザーまたはシステム・プロセスの身元を証明または確認するプロセスのことです。認証にはまた、必要に応じて、身元情報を記憶したり、トランスポートしたり、様々なシステム・コンポーネントの利用に供する働きもあります。WebLogicセキュリティ・サービスによってサポートされる認証プロバイダは、以下の種類の認証を提供します。

- ユーザー名とパスワードによる認証

- WebLogic Serverで直接行われる証明書ベースの認証

- 外部Webサーバーを介してプロキシされるHTTP証明書ベースの認証

- IDアサーション - 境界認証(トークンを使用する特殊なタイプの認証)を行う認証プロバイダを、IDアサーション・プロバイダと呼びます。IDアサーションでは、リクエストの外部に存在するクライアント提供のトークンを使用してクライアントのIDを確立します。したがって、IDアサーション・プロバイダの機能は、トークンを検証してユーザー名にマップすることです。このマッピングがいったん完了すれば、認証プロバイダのLoginModuleを使用してユーザー名がプリンシパル(認証済みのユーザー、グループ、またはシステム・プロセス)に変換されます。

- 認可 - ユーザーとWebLogicリソースとのやり取りを限定して、整合性、機密性、および可用性を確保するプロセスです。つまり、認証プロバイダによってユーザーのIDが確立したら、認可はそのユーザーによるWebLogicリソースへのアクセスを許可するかどうかを決定します。認可プロバイダは、これらのサービスを提供します。

- ロール・マッピング - 1つまたは複数のロールを複数のユーザーに割り当て、特定のロールを持つユーザーのアクセス権を指定できます。ロール・マッピング・プロバイダは、指定されたリソースについてリクエスト側に付与される一連のロールを取得します。ロール・マッピング・プロバイダから認可プロバイダにこのロール情報が提供されるので、認可プロバイダは、ロール・ベースのセキュリティを用いるWebLogicリソース(WebアプリケーションやEnterprise JavaBeans (EJB))からの「アクセスできるか」という質問に答えることができます。

- 裁決 - セキュリティ・レルムに複数の認可プロバイダが構成される場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返すことがあります。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の競合を解決し、アクセスに関する最終決定を返します。

- 資格証明マッピング - 資格証明マップとは、WebLogic Serverで使用する資格証明と、レガシー・システムまたはリモート・システムで使用する資格証明とのマッピングです。WebLogic Serverではこのマップによって、そのシステム内の特定のリソースへの接続方法を認識します。つまり、資格証明マップを使用することで、WebLogic Serverが、認証済みのサブジェクトに代わってリモート・システムにログインできるようになります。資格証明マッピング・プロバイダはこのように資格証明をマップします。

- キーストア - 秘密鍵と信頼された認証局の証明書を格納する、パスワードで保護されたストアの作成と管理のためのメカニズムです。キーストアは、認証や署名を目的としてそれを必要とすることがあるアプリケーションから利用できます。WebLogic Serverのセキュリティ・アーキテクチャでは、WebLogicキーストア・プロバイダを使用してキーストアにアクセスします。

注意:
WebLogic Serverキーストア・プロバイダは非推奨になりました。後方互換性を保持するためにのみサポートされています。かわりにキーストアを使用してください。キーストアの構成の詳細は、「プロダクション用のキーストアの構成」を参照してください。

- 証明書ルックアップおよび検証(CLV) - IDと信頼のために、X.509証明書を検索および検証する必要があります。CLVプロバイダは、証明書、証明書チェーン、または証明書参照を受け取り、証明書パスを完成させ(必要な場合)、パス内のすべての証明書を検証します。CLVプロバイダには、2つのタイプがあります。

- 証明書パス・ビルダーは、証明書パスの検索と完成(必要な場合)、および証明書の検証を行います。

- 証明書パス検証プロバイダは、証明書パスの検索と完成(必要な場合)、証明書の検証、および追加の検証(失効チェックなど)を行います。

- 証明書レジストリ - 証明書レジストリは、セキュリティ・レルムに証明書失効チェックを追加するためのメカニズムです。証明書レジストリは、有効な証明書のリストを保持します。登録されている証明書のみが有効です。証明書レジストリから削除することによって、その証明書は失効します。このレジストリは、組込みLDAPサーバーに格納されます。証明書レジストリは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。

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

WebLogicセキュリティ・プロバイダで提供される機能の詳細は、第4章「WebLogicセキュリティ・プロバイダの構成」と第5章「認証プロバイダの構成」を参照してください。

デフォルトのセキュリティ構成については、「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。

カスタム・セキュリティ・プロバイダの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

セキュリティ・ポリシーとWebLogicリソース

WebLogic Serverは、セキュリティ・ポリシー(WebLogic Server 6.xで使用していたACLと権限にかわるもの)を使用してWebLogicリソースを保護します。セキュリティ・ポリシーは、WebLogicリソースへの「アクセス権は誰が持つか」という問いに答えます。セキュリティ・ポリシーは、WebLogicリソースとユーザー、グループ、またはセキュリティ・ロールの間の関連付けを定義するときに作成します。また、セキュリティ・ポリシーに時間の制約を関連付けることもできます。WebLogicリソースは、セキュリティ・ポリシーが割り当てられるまでは保護されません。

セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。このプロセスについて理解を深めるには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を読んでください。WebLogic Serverのデプロイメントに対するセキュリティを完全に構成するには、そのドキュメントをWebLogicセキュリティの保護とあわせて使用する必要があります。

WebLogicリソース

WebLogicリソースは、権限のないアクセスから保護することができる基底のWebLogic Serverエンティティを表す構造化オブジェクトです。WebLogic Serverでは、以下のリソースが定義されます。

- WebLogic Server管理コンソールやWebLogic Scripting Toolなどの管理リソース。

- エンタープライズ・アプリケーションを表すアプリケーション・リソース。このタイプのリソースには、EAR (エンタープライズ・アプリケーション・アーカイブ)ファイルと、EARに含まれるEJB JARファイルのような個々のコンポーネントがあります。

- Microsoftのフレームワークに従ってプログラム・コンポーネント・オブジェクトとして設計されるComponent Object Model (COM)リソース。このタイプのリソースには、Oracleの双方向型COM-Java (jCOM)ブリッジング・ツールを介してアクセスするCOMコンポーネントがあります。

- リソース・アダプタとして設計されるエンタープライズ情報システム(EIS)リソース。Javaアプリケーションと既存のエンタープライズ情報システムを統合できます。これらのリソース・アダプタは、コネクタとも呼ばれます。

- Enterprise JavaBean (EJB)リソース。EJB JARファイル、EJB JAR内の個々のEJB、およびEJBの個々のメソッドがあります。

- Java DataBase Connectivity (JDBC)リソース。接続プールのグループ、個々の接続プール、およびマルチプールがあります。

- Java Naming and Directory Interface (JNDI)リソース。

- Java Message Service (JMS)リソース。

- WebLogic Serverインスタンス(サーバー)に関連するサーバー・リソース。このタイプのリソースには、サーバーを起動、停止、ロック、またはロック解除する操作があります。

- Webアプリケーションに関連するURLリソース。このタイプのリソースには、Webアプリケーション・アーカイブ(WAR)ファイル、またはWebアプリケーションの個々のコンポーネント(サーブレットやJSPなど)があります。

注意:
Webリソースは非推奨になりました。かわりにURLリソースを使用してください。

- Webベースの分散アプリケーションのコンポーネント間で共有したり、コンポーネントとして使用したりできるサービスに関連したWebサービス・リソース。このタイプのリソースには、Webサービス全体、またはWebサービスの個々のコンポーネント(ステートレス・セッションEJB、そのEJB内の特定のメソッド、web-services.xmlファイルを含むWebアプリケーションなど)があります。

- リモート・リソース。

デプロイメント記述子とWebLogic Server管理コンソール

WebLogic Serverでは、セキュリティ・ロールおよびポリシーの構成モデルを選択できます。標準のJava Enterprise Editionモデルでは、ロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。WebLogicセキュリティ・サービスは、デプロイメント記述子に定義された情報を使用してWebアプリケーションまたはEJBのためにセキュリティ・ロールを付与し、セキュリティ・プロファイルを定義することができます。WebLogic Serverを最初に起動するときに、web.xml、weblogic.xml、ejb-jar.xml、またはweblogic-ejb-jar.xmlデプロイメント記述子に格納されたセキュリティ・ロールとセキュリティ・ポリシーの情報が、デフォルト・セキュリティ・レルムに構成されている認可プロバイダとロール・マッピング・プロバイダにロードされます。ロールやポリシーの情報は、後から管理コンソールで確認できます。(必要に応じ、別のセキュリティ・モデルを使用するようにセキュリティ・レルムを構成して、管理コンソールからこれらの情報を変更できるようにすることも可能です。)

デプロイメント記述子内の情報を利用するには、セキュリティ・レルム内の少なくとも1つの認可プロバイダとロール・マッピング・プロバイダがそれぞれDeployableAuthorizationProviderおよびDeployableRoleProviderセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装している必要があります。このSSPIを使用すると、プロバイダはデプロイメント記述子から情報を(検索ではなく)格納できます。デフォルトでは、WebLogic認可プロバイダとロール・マッピング・プロバイダがこのSSPIを実装しています。

管理コンソールからデプロイメント記述子内のセキュリティ・ロールとセキュリティ・ポリシーを変更し、それ以降もこの情報を管理コンソールから変更する予定がある場合は、管理コンソールで行った変更がWebLogic Serverの再起動時にデプロイメント記述子の古い情報で上書きされないように、セキュリティ・レルムに構成オプションを設定できます。

詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のWebアプリケーションおよびEJBリソースの保護のオプションに関する項を参照してください。

WebLogic Serverのデフォルト・セキュリティ構成

WebLogic Serverのセキュリティの構成と管理を簡素化するために、デフォルトのセキュリティ構成が用意されています。デフォルト・セキュリティ構成では、myrealmがデフォルト・セキュリティ・レルムとして設定され、WebLogic裁決、認証、IDアサーション、XACML認可、資格証明マッピング、XACMLロール・マッピング、および証明書パスの各プロバイダがセキュリティ・プロバイダとして定義されています。WebLogic Serverの組込みLDAPサーバーは、これらのデフォルト・セキュリティ・プロバイダ用のデータ・ストアとして使用されます。デフォルト・セキュリティ構成を使用するには、セキュリティ・レルムでユーザー、グループ、およびセキュリティ・ロールを定義し、セキュリティ・ポリシーを作成してドメイン内のWebLogicリソースを保護する必要があります。

注意:
WebLogic Serverには、WebLogic認可プロバイダとWebLogicロール・マッピング・プロバイダがあります。これらのプロバイダは、管理コンソールなどではそれぞれ「デフォルト認可プロバイダ」、「デフォルト・ロール・マッピング・プロバイダ」と呼ばれています。WebLogic Server 9.1から、新しく作成されるセキュリティ・レルムでは、これらのプロバイダはデフォルトのプロバイダではなくなりました。代わりに、XACML認可プロバイダとXACMLロール・マッピング・プロバイダがデフォルトのプロバイダになっています。

WebLogicセキュリティ・プロバイダで提供される機能の詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。これらのWebLogicセキュリティ・プロバイダがセキュリティ要件を必ずしも完全に満たしていない場合には、それらを補うか、あるいは入れ替えることができます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

デフォルト・セキュリティ構成では要件が満たされない場合、WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダを自由に組み合せて新しいセキュリティ・レルムを作成し、そのセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定できます。第3章「デフォルト・セキュリティ構成のカスタマイズ」を参照してください。

WebLogicセキュリティの構成: 主な手順

WebLogic Serverのセキュリティ機能は互いに関連しているので、セキュリティを構成する場合にどこから始めるべきか判断しにくいものです。実際、WebLogic Serverデプロイメントのセキュリティを構成する場合には、同じ作業を繰り返すこともあります。構成の手順はいくつかありますが、次の手順を実行することをお薦めします。

1. 「デフォルト・セキュリティ構成をカスタマイズする理由」に目を通して、デフォルト・セキュリティ構成を使用するかどうかを決定します。

- デフォルト・セキュリティ構成を使用する場合は、ステップ3に進みます。

- デフォルト・セキュリティ構成を使用しない場合は、ステップ2に進みます。

2. デフォルト・セキュリティ・レルムで、追加のセキュリティ・プロバイダを構成するか(たとえば、WebLogic認証プロバイダを使用するかわりにLDAP認証プロバイダを構成します)、またはカスタム・セキュリティ・プロバイダを構成します。この手順はオプションです。デフォルトでは、WebLogic Serverはデフォルト・セキュリティ・レルム(myrealm)のWebLogicセキュリティ・プロバイダを構成します。デフォルト・セキュリティ構成をカスタマイズする必要がある状況については、デフォルト・セキュリティ構成をカスタマイズする理由に関する項を参照してください。カスタム・セキュリティ・プロバイダの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

注意:
また、新しいセキュリティ・レルムを作成し、そのセキュリティ・レルムでセキュリティ・プロバイダ(WebLogicまたはカスタム)を構成し、そのセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定することもできます。第3章「デフォルト・セキュリティ構成のカスタマイズ」を参照してください。

3. 必要に応じて、組込みLDAPサーバーを構成します。WebLogic Serverの組込みLDAPサーバーは、デフォルト・オプションで構成されています。ただし、これらのオプションを変更して、組込みLDAPサーバーの使い方を環境に合わせて最適化できます。第9章「組込みLDAPサーバーの管理」を参照してください。

4. ユーザー・アカウントが適切に保護されていることを確認します。WebLogic Serverにはユーザー・アカウントを保護するための構成オプションが用意されています。デフォルトでは、属性は最高のセキュリティ・レベルに設定されています。ただし、WebLogic Serverの開発およびデプロイメント時には、ユーザー・アカウントに対する制限の緩和が必要な場合もあります。本番環境に移行する前に、ユーザー・アカウントのオプションが最高の保護レベルに設定されていることを確認してください。新しいセキュリティ・レルムを作成する場合は、ユーザーのロック・アウトのオプションを設定する必要があります。「WebLogic Serverでのパスワードの保護の仕組み」と「ユーザー・アカウントの保護」を参照してください。

5. セキュリティ・ポリシーでWebLogicリソースを保護します。セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。このプロセスについて理解を深めるには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を読んでください。WebLogic Serverのデプロイメントにおいてセキュリティを完全に構成するには、『Oracle WebLogic Server 10.3.6の保護』と『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を併読する必要があります。

6. WebLogic ServerのIDと信頼を構成します。この手順は省略可能ですが、実行することをお薦めします。第11章「IDと信頼の構成」を参照してください。

7. WebLogic Serverに対してSSLを有効にします。この手順は省略可能ですが、実行することをお薦めします。第12章「SSLの構成」を参照してください。

8. 本番に移行する場合、『Oracle WebLogic Server本番環境の保護』で説明されている追加のセキュリティ・オプションを確認し、実装してください。

また、以下のことを行うことができます。

- 接続フィルタを構成します。「接続フィルタの使用」を参照してください。

- WebLogicドメイン間の相互運用性を有効化します。「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」を参照してください。

セキュリティの構成方法

多くの場合、このドキュメントではWebLogic Server管理コンソールを使用してWebLogicセキュリティを構成する方法について説明しています。一般に、管理コンソールで実行できる構成タスクは、WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して実行することもできます。WLSTを使用したWebLogicセキュリティの管理は、『Oracle WebLogic Scripting Tool』のセキュリティ・データの管理に関する項を参照してください。JMX APIの使い方については、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のセキュリティ・レルムを管理するMBeanサーバーの選択に関する項を参照してください。

セキュリティ・レルムを管理する場合は、タスクに応じて2つの異なるMBeanサーバーを使用する必要があります。

- セキュリティMBean属性の値を設定する場合は、編集MBeanサーバーを使用します。

- セキュリティ・プロバイダMBeanでユーザー、グループ、ロール、およびポリシーを追加したり、他の操作を呼び出したりする場合は、実行時MBeanサーバーまたはドメイン実行時MBeanサーバーを使用します。

また、両立不能な変更が発生しないように、自身のクライアントや別のJMXクライアントに現在アクティブな編集セッションがある場合にはセキュリティ・プロバイダMBeanで操作を呼び出すことはできません。管理コンソールでは、この制限が自動的に適用され、適切なMBeanサーバーへのアクセスが自動的に行われます。管理コンソールを使用する場合には、「ドメイン」→「セキュリティ」→「全般」ページで「動的でない変更が行われた場合にセキュリティ管理操作を許可する」を有効化することで、この制限をオーバーライドできます。この属性をtrueに設定すると、ユーザーはサーバーを再起動しなくてもセキュリティ管理操作を実行できるようになります。この属性は、新しいMBean編集セッションが開始されると、falseにリセットされます。

たとえば、DefaultAuthenticatorMBeanのMinimumPasswordLength属性の値は、ドメインの構成ドキュメントに格納されています。このドキュメントに対するすべての変更はWebLogic Serverによって制御されているため、この属性の値を変更するには、編集MBeanサーバーを使用してドメインの構成に対してロックを取得する必要があります。DefaultAuthenticatorMBeanのcreateUser操作は、LDAPサーバーにデータを追加します。この操作はWebLogic Serverによって制御されていません。DefaultAuthenticatorMBeanの構成とそれがLDAPサーバーで使用するデータの間で両立不能な変更が発生しないように、自身や別のユーザーがMinimumPasswordLength属性の変更を行っている場合にはcreateUser操作を呼び出すことはできません。さらに、この属性の変更にはWebLogic Serverの再起動が必要になるため、サーバーが再起動するまでcreateUser操作を呼び出すことができません。

互換性セキュリティとは

互換性セキュリティとは、WebLogic Server 6.xで行ったセキュリティ構成をこのリリースのWebLogic Serverで実行するための機能です。互換性セキュリティでは、6.xのセキュリティ・レルム、ユーザー、グループ、およびACLの管理、ユーザー・アカウントの保護、レルム・アダプタ監査プロバイダの構成や、必要に応じてレルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成を行うことができます。

互換性セキュリティで使用可能なセキュリティ・レルムはCompatibilityRealmだけです。互換性レルムのレルム・アダプタ・プロバイダ(監査、裁決、認可、および認証)を使用すると、6.xセキュリティ・レルムの認証、認可、および監査サービスとの後方互換性を保持できます。詳細は、第14章「互換性セキュリティの使い方」を参照してください。

注意:
互換性セキュリティは非推奨になりました。今後のメジャー・リリースではサポートされなくなります。WebLogic ServerデプロイメントをこのリリースのWebLogic Serverのセキュリティ機能にアップグレードすることを強くお薦めします。互換性セキュリティは、このアップグレードの間だけ使用してください。

互換性セキュリティで実行できる管理タスク

互換性セキュリティではWebLogic Server 6.xでサポートされる認証、認可、およびカスタム監査の実装にしかアクセスできないので、6.xのすべてのセキュリティ・タスクが実行できるわけではありません。互換性セキュリティを使用するには:

- レルム・アダプタ監査プロバイダを構成します。詳細は、「レルム・アダプタ監査プロバイダの構成」を参照してください。

- weblogic.security.acl.CertAuthenticatorクラスの実装を使用するために、レルム・アダプタ認証プロバイダ内にIDアサーション・プロバイダを構成します。詳細は、「レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成」を参照してください。

注意:
レルム・アダプタ裁決プロバイダとレルム・アダプタ認可プロバイダは、6.xの既存のconfig.xmlファイルの情報を使用して、CompatibilityRealmにデフォルトで構成されています。これらのプロバイダはCompatibilityRealmでのみ使用できます。レルム・アダプタ認証プロバイダもCompatibilityRealmに自動的に構成されます。ただし、このプロバイダは、6.xセキュリティ・レルムに格納されたユーザーとグループにアクセスするために、他のレルムで構成することもできます。詳細は、「RDBMS認証プロバイダの構成」を参照してください。

- systemユーザーのパスワードを変更して、WebLogic Serverのデプロイメントを保護します。

- CompatibilityRealmでセキュリティ・レルムを管理します。

- CompatibilityRealmでセキュリティ・レルムの追加のユーザーを定義します。セキュリティ・レルムにグループを実装して、ユーザーをさらにまとめます。

- WebLogic ServerデプロイメントにあるリソースのACLと権限を管理します。

- WebLogicリソースのセキュリティ・ロールとセキュリティ・ポリシーを作成してCompatibilityRealmに追加します。詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

IDと信頼の構成、SSLの使用、接続フィルタの構成、およびドメイン間の相互運用性の有効化も可能ですが、これらのタスクはこのリリースのWebLogic Serverのセキュリティ機能を使用して実行します。次を参照してください:

- 第11章「IDと信頼の構成」

- 第12章「SSLの構成」

- 第13章「WebLogicドメインのセキュリティの構成」

3 デフォルト・セキュリティ構成のカスタマイズ

この章では、新しいセキュリティ・レルムを作成してWebLogic Server 10.3.6でデフォルトのセキュリティ構成をカスタマイズする方法について説明します。

この章の内容は以下のとおりです。

- デフォルト・セキュリティ構成をカスタマイズする理由

- 新しいセキュリティ・レルムを作成する前に

- 新しいセキュリティ・レルムの作成と構成: 主な手順

セキュリティ・プロバイダの構成の詳細は、第4章「WebLogicセキュリティ・プロバイダの構成」と第5章「認証プロバイダの構成」を参照してください。

セキュリティ・データの新しいセキュリティ・レルムへの移行については、第8章「セキュリティ・データの移行」を参照してください。

デフォルト・セキュリティ構成をカスタマイズする理由

WebLogic Serverのセキュリティの構成と管理を簡素化するために、デフォルトのセキュリティ構成が用意されています。デフォルト・セキュリティ構成では、myrealmがデフォルト(アクティブ)セキュリティ・レルムとして設定され、WebLogic裁決、認証、IDアサーション、資格証明マッピング、証明書パス、XACML認可、およびXACMLロール・マッピングの各プロバイダがセキュリティ・プロバイダとしてセキュリティ・レルムに定義されています。

以下のいずれかを行う場合、デフォルト・セキュリティ構成をカスタマイズします。

- デフォルト・レルムのセキュリティ・プロバイダの1つを別のセキュリティ・プロバイダで置き換えます。

- デフォルト・セキュリティ・レルムに追加のセキュリティ・プロバイダを構成します。(たとえば、2つの認証プロバイダを使用し、その1つで組込みLDAPサーバーを使用し、もう1つでWindows NTのユーザーおよびグループのストアを使用する場合)。

- WebLogic Serverの組込みLDAPサーバー以外のLDAPサーバーにアクセスする認証プロバイダを使用します。

- WebLogicオーセンティケータ(DefaultAuthenticatorとも呼ばれます)でユーザーおよびグループを定義するのではなく、ユーザーとグループの既存のストア(DBMSデータベースなど)を使用します。

- 認証を行う場合、ユーザー名に加えてプリンシパルのGUIDまたはDN属性を使用し、プリンシパルの一致で大文字/小文字が区別されないように指定します。

- デフォルト・セキュリティ・レルムに監査プロバイダを追加します。

- SAMLアサーションまたはKerberosトークンを処理するIDアサーション・プロバイダを使用します。

- 証明書レジストリを使用してセキュリティ・レルムに証明書失効を追加します。

- セキュリティ・プロバイダのデフォルト構成設定を変更します。

- セキュリティ・プロバイダ・データベースで並列セキュリティ・ポリシーとロール変更をそれぞれサポートしないカスタム認可プロバイダまたはロール・マッピング・プロバイダを使用します。

セキュリティ・レルムで様々なタイプのセキュリティ・プロバイダを構成する方法については、第4章「WebLogicセキュリティ・プロバイダの構成」と第5章「認証プロバイダの構成」を参照してください。

デフォルト・セキュリティ構成をカスタマイズする最も簡単な方法は、デフォルト・セキュリティ・レルム(myrealm)にセキュリティ・プロバイダを追加することです。しかしOracleではこの方法ではなく、完全に新しいセキュリティ・レルムを作成して、デフォルト・セキュリティ構成をカスタマイズすることをお薦めします。このようにすると、デフォルト・セキュリティ構成を簡単に元に戻せる状態が保たれます。作成した新しいレルムにセキュリティ・プロバイダを構成し、既存のデフォルト・レルムからユーザーやグループなどのセキュリティ・データを移行してから、新しいセキュリティ・レルムをデフォルト・レルムとして設定します。「新しいセキュリティ・レルムの作成と構成: 主な手順」を参照してください。

新しいセキュリティ・レルムを作成する前に

新しいセキュリティ・レルムを作成する前には、以下のことを決定する必要があります。

- どのセキュリティ・プロバイダを使用するか。WebLogic Serverには様々なセキュリティ・プロバイダがあり、カスタム・セキュリティ・プロバイダを作成したり入手したりすることもできます。有効なセキュリティ・レルムには、認証プロバイダ、認可プロバイダ、裁決プロバイダ、資格証明マッピング・プロバイダ、ロール・マッピング・プロバイダ、および証明書パス・ビルダーが必須です。また、必要に応じてIDアサーション・プロバイダ、監査プロバイダ、および証明書レジストリ・プロバイダを含めることもできます。新しいセキュリティ・レルムに同じ種類のプロバイダを複数含める場合(複数の認証プロバイダ、複数の認可プロバイダなど)、そうしたプロバイダが相互に通信する方法を決定する必要があります。「複数の認証プロバイダの使用」を参照してください。
また、カスタムの認可プロバイダまたはロール・マッピング・プロバイダは、セキュリティ・プロバイダ・データベースで並列セキュリティ・ポリシーとロール変更をれぞれサポートする場合とサポートしない場合があります。カスタムの認可プロバイダまたはロール・マッピング・セキュリティ・プロバイダが並列変更をサポートしない場合、WebLogicセキュリティ・フレームワークは同期メカニズムを実行するため、各アプリケーションとモジュールはキューに配置され、連続してデプロイされます。これを行うには、レルムに「デプロイ可能プロバイダの同期を有効化」制御と「デプロイ可能プロバイダの同期のタイムアウト」制御を設定します。

- WebアプリケーションやEJBリソースへのセキュリティ・ロールやセキュリティ・ポリシーの設定にどのようなモデルを使用するか。セキュリティ・ロールおよびポリシーは、デプロイメント記述子またはWebLogic管理コンソールを通じて設定できます。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のWebアプリケーションおよびEJBリソースの保護のオプションに関する項を参照してください。

- Webリソースを使用するかどうか。
Webリソースは非推奨になりました。新しいセキュリティ・レルムで、URLリソースではなくWebリソースを使用するカスタム認可プロバイダを構成する場合は、新しいセキュリティ・レルムの「非推奨のWebリソースを使用」を有効にしてください。このオプションによってサーブレット・コンテナの実行時の動作が変更され、認可を実行する際にURLリソースではなくWebリソースが使用されます。

注意:
新しいセキュリティ・レルムを作成する場合、少なくとも1つの認証プロバイダを構成して、アサートされたLoginModuleを返す必要があります。そうしないと、デプロイメント記述子に定義されるrun-asタグが有効になりません。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの新しいセキュリティ・レルムの構成に関する項を参照してください。

新しいセキュリティ・レルムの作成と構成: 主な手順

新しいセキュリティ・レルムを作成するには:

1. セキュリティ・レルムの名前を定義し、構成オプションを設定します。「新しいセキュリティ・レルムを作成する前に」、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプの新しいセキュリティ・レルムの構成に関する項を参照してください。

2. セキュリティ・レルムで必要なセキュリティ・プロバイダを構成します。有効なセキュリティ・レルムには、認証プロバイダ、認可プロバイダ、裁決プロバイダ、資格証明マッピング・プロバイダ、ロール・マッピング・プロバイダ、および証明書パス・ビルダーが必須です。第4章「WebLogicセキュリティ・プロバイダの構成」と第5章「認証プロバイダの構成」を参照してください。

3. 必要に応じて、IDアサーション、監査、および証明書レジストリ・プロバイダを定義します。第4章「WebLogicセキュリティ・プロバイダの構成」と第5章「認証プロバイダの構成」を参照してください。

4. 新しいセキュリティ・レルムでデフォルト認証プロバイダ、認可プロバイダ、資格証明マッピング・プロバイダ、またはロール・マッピング・プロバイダ、または証明書レジストリを構成した場合は、組込みLDAPサーバーの設定が適切であるかどうかを検証してください。第9章「組込みLDAPサーバーの管理」を参照してください。

5. 必要に応じて、セキュリティ・レルムのWebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスを向上させるためのキャッシュを構成します。「WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上」を参照してください。

6. 新しいセキュリティ・レルム内のWebLogicリソースをセキュリティ・ポリシーで保護します。セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。この手順について理解を深めるには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』に目を通してください。WebLogic Serverのデプロイメントに対するセキュリティを完全に構成するには、前述のマニュアルと『Oracle WebLogic Server 10.3.6の保護』を併読する必要があります。

7. 新しいセキュリティ・レルムで、既存のセキュリティ・レルムに定義されたセキュリティ・データ(ユーザーとグループ、ロールとポリシー、および資格証明マップ)も有効にする場合、既存のレルムからセキュリティ・データをエクスポートして新しいセキュリティ・レルムにインポートできます。第8章「セキュリティ・データの移行」を参照してください。

8. ロック・アウト属性を設定することによって、新しいセキュリティ・レルムのユーザー・アカウントを辞書攻撃から保護します。「ユーザー・アカウントの保護」を参照してください。

9. 新しいレルムをWebLogicドメインのデフォルト・セキュリティ・レルムとして設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・セキュリティ・レルムの変更に関する項を参照してください。

注意:
WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。『Oracle WebLogic Scripting Tool』を参照してください。

4 WebLogicセキュリティ・プロバイダの構成

この章では、WebLogic Server 10.3.6が提供するセキュリティ・プロバイダの構成方法について説明します。

この章の内容は以下のとおりです。

注意:
WebLogic Serverには、多くの認証プロバイダとIDアサーション・プロバイダが組み込まれているので、これらについては別の章で詳しく説明します。詳細は、第5章「認証プロバイダの構成」を参照してください。

- セキュリティ・プロバイダを構成する必要がある場合

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

- デプロイメント時のセキュリティ・ポリシーとロール変更の同期を有効化

- 認可プロバイダの構成

- WebLogic裁決プロバイダの構成

- ロール・マッピング・プロバイダの構成

- WebLogic監査プロバイダの構成

- WebLogic資格証明マッピング・プロバイダの構成

- PKI資格証明マッピング・プロバイダの構成

- SAML 1.1用のSAML資格証明マッピング・プロバイダの構成

- SAML 2.0用のSAML 2.0資格証明マッピング・プロバイダの構成

- 証明書ルックアップおよび検証フレームワークの構成

- WebLogicキーストア・プロバイダの構成

セキュリティ・プロバイダを構成する必要がある場合

デフォルトでは、ほとんどの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認可では独自のキャッシュを使用しますが、このキャッシュは構成できません。

WebLogic裁決プロバイダの構成

セキュリティ・レルムに複数の認可プロバイダが構成される場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返す可能性があります。この回答は、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ロール・マッピング・プロバイダでは独自のキャッシュを使用しますが、このキャッシュは構成できません。

WebLogic監査プロバイダの構成

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

監査プロバイダの構成はオプションです。デフォルト・セキュリティ・レルム(myrealm)には監査プロバイダは構成されていません。WebLogic Serverには、WebLogic監査プロバイダ(管理コンソールではDefaultAuditor)というプロバイダが用意されています。また、カスタム監査プロバイダを開発することもできます。詳細は、『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監査プロバイダはアクティブなセキュリティ・レルムに追加されると監査イベントの記録を開始します。ただし、次の設定については定義する必要があります。これらの設定は管理コンソールのプロバイダの「構成」→「プロバイダ固有」ページで行えます。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要素

監査イベントには、様々な情報やオブジェクトを保持できる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監査プロバイダを有効にしている場合は、さらにセキュリティ・ログに監査イベントが書き込まれます。こうしたログ・メッセージと監査イベントにより、ドメインの構成の変更を監査、追跡できます。この機能を、構成監査といいます。

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

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

構成監査の有効化

構成監査の有効化は、以下のいずれかの方法で行えます。

- 管理コンソールを使用します。ドメインの「構成」→「全般」ページで、「構成監査のタイプ」を設定します。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

ここで、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
where username identifies the WebLogic Server user who logged in and deleted a resource.

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

159903

USER username REMOVE MBean-name
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace
where username identifies the unauthorized WebLogic Server user.

認可されたユーザーがリソースの構成を変更します。

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 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資格証明マッピング・プロバイダは、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資格証明マッピング・プロバイダの構成」を参照してください。

PKI資格証明マッピング・プロバイダの構成

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

PKI資格証明マッピング・プロバイダを使用するには、次を行う必要があります:

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

2. PKI資格証明マッピング・プロバイダを構成します。PKI資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルム(myrealm)には構成されていません。「PKI資格証明マッピング属性」と、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの資格証明マッピング・プロバイダの構成に関する項を参照してください。

3. 資格証明マッピングを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのPKI資格証明マッピングの作成に関する項を参照してください。

PKI資格証明マッピング属性

PKI資格証明マッピング・プロバイダを構成するには、次の属性の値を設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの資格証明マッピング・プロバイダの構成に関する項を参照してください。

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

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

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

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

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

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

- 「イニシエータ・グループ名を使用」 - サブジェクトがPKI資格証明マッピング・プロバイダに渡されると、イニシエータがメンバーであるグループを調べることによって資格証明が検索されます。デフォルトでは、これは有効になっています。

資格証明アクション

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

PKI資格証明マッピングへの資格証明アクションの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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に関するドキュメントの『WebLogic Serverの保護』のSAML資格証明マッピング・プロバイダの構成に関する項(http://docs.oracle.com/cd/E13222_01/wls/docs90/secmanage/providers.html#SAML_cred)を参照してください。

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

- リライイング・パーティの構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1リライイング・パーティの構成に関する項

SAML 2.0用のSAML 2.0資格証明マッピング・プロバイダの構成

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

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

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セキュリティ・フレームワークによるシングル・サインオンに関する項を参照してください。SAML 2.0資格証明マッピング・プロバイダをSAML 2.0シングル・サインオン構成で使用する方法については、第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。Webサービス用のサービス・プロバイダ・パートナ用に生成されたアサーションの確認方法の指定については、『Oracle WebLogic Server WebLogic Webサービスの保護』のSecurity Assertion Markup Language (SAML)トークンのIDとしての使用に関する項を参照してください。

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

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シングル・サインオン・サービス・プロバイダ・パートナの作成と構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成に関する項

Webサービス用のサービス・プロバイダ・パートナの構成ではメタデータ・ファイルは使用しませんが、そのパートナに関する次の情報を指定する必要があります。

- オーディエンスURI。このパートナ用に生成されるアサーションに含めるオーディエンス制約を指定します。
WebLogic Serverでは、Webサービス・ランタイムがパートナの検索に使用するパートナ検索文字列を保持する必要もあるため、オーディエンスURI属性がオーバーロードされています。「Webサービス・パートナに必要なパートナ検索文字列」を参照してください。

- デフォルトの名前マッパーをオーバーライドするカスタム名前マッパー・クラス。このマッパー・クラスは、このパートナでのみ使用します。

- このパートナ用に生成されるアサーションの有効期間属性を指定する値。

- このパートナから受け取ったアサーションの確認方法。

Webサービス用のサービス・プロバイダ・パートナの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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>に完全に一致するパートナを検索します。

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

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エントリに、すべてのターゲットの有効なワイルドカード一致を含めることができます。実際のワイルドカードURIは、Webサービス・ランタイムが使用する特定の形式に合わせる必要があります。例:

- target:*:http://

- target:*:https://

パートナ証明書の管理

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

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

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

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

サービス・プロバイダ・パートナの属性を構成するためのJavaインタフェース

Webサービス・パートナで使用できる操作の詳細は、Oracle WebLogic Server APIリファレンスの「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の場合です。

- チェーン内の証明書が正しく相互署名されています。

- サーバーの信頼性のある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管理コンソール・オンライン・ヘルプの証明書パス・プロバイダの構成に関する項を参照してください。

WebLogicキーストア・プロバイダの構成

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

WebLogicキーストア・プロバイダの構成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

5 認証プロバイダの構成

この章では、WebLogic Server 10.3.6が提供する認証セキュリティ・プロバイダの構成方法について説明します。

WebLogic Serverには、数多くの認証セキュリティ・プロバイダが組み込まれています。ほとんどの認証プロバイダは同じように動作します。ユーザー名とパスワードの資格証明ペアが指定されると、認証プロバイダはそのデータ・ストアから対応するユーザーを見つけ出そうとします。これらの認証プロバイダの主な違いは、使用するデータ・ストアの種類にあります(使用可能なLDAPサーバーの1つ、SQLデータベース、またはその他のデータ・ストア)。ユーザー名とパスワードをベースとしたセキュリティ・プロバイダの他にも、WebLogic ServerにはIDアサーション認証プロバイダが組み込まれています。IDアサーション認証プロバイダは、ユーザー名とパスワードのペアではなく証明書またはセキュリティ・トークンを資格証明として使用します。

この章の内容は以下のとおりです。

- 認証プロバイダの選択

- 複数の認証プロバイダの使用

- WebLogic認証プロバイダの構成

- LDAP認証プロバイダの構成

- RDBMS認証プロバイダの構成

- Windows NT認証プロバイダの構成

- SAML認証プロバイダの構成

- パスワード検証プロバイダの構成

- IDアサーション・プロバイダの構成

認証プロバイダの選択

認証とは、ユーザーおよびシステム・プロセスのIDを証明または検証するプロセスです。認証にはまた、必要に応じて、身元情報を記憶したり、トランスポートしたり、様々なシステム・コンポーネントの利用に供する働きもあります。

WebLogic Serverのセキュリティ・アーキテクチャでサポートされているのは、パスワードと証明書に基づく認証(WebLogic Serverを直接用いる)、HTTP証明書に基づく認証(外部のWebサーバーを介して行う)、境界に基づく認証(Webサーバー、ファイアウォール、VPN)、および複数のセキュリティ・トークン・タイプ/プロトコルに基づく認証です。

WebLogic Serverには、以下のタイプの認証プロバイダが用意されています。

- WebLogic認証プロバイダ(DefaultAuthenticatorとも呼ばれます)。このプロバイダでは、WebLogic Serverの組込みLDAPサーバー内のユーザーおよびグループ情報にアクセスします。

- Oracle Internet Directory認証プロバイダは、LDAPバージョン3ディレクトリであるOracle Internet Directory内のユーザーおよびグループ情報にアクセスします。

- Oracle Virtual Directory認証プロバイダは、LDAPバージョン3対応のサービスであるOracle Virtual Directory内のユーザーおよびグループ情報にアクセスします。

- LDAP認証プロバイダでは、外部のLDAPストアにアクセスします。LDAP認証プロバイダを使用すると、任意のLDAPサーバーにアクセスできます。WebLogic Serverには、Open LDAP、Sun iPlanet、Microsoft Active Directory、およびNovell NDS LDAPサーバー用に構成済みのLDAP認証プロバイダが用意されています。

- RDBMS認証プロバイダでは、外部リレーショナル・データベースにアクセスします。WebLogic Serverには、SQL認証プロバイダ、読取り専用SQL認証プロバイダ、カスタムRDBMS認証プロバイダという3種類のRDBMS認証プロバイダが用意されています。

- WebLogic IDアサーション・プロバイダは、X.509およびIIOP-CSIv2トークンを検証します。必要に応じてユーザー名マッパーを使用して、そのトークンをWebLogic Serverセキュリティ・レルム内のユーザーにマップできます。

- SAML認証プロバイダ - Security Assertion Markup Language 1.1 (SAML)アサーションに基づいてユーザーを認証します。

- ネゴシエーションIDアサーション・プロバイダ - Simple and Protected Negotiate (SPNEGO)トークンを使用して、Kerberosトークンを取得および検証し、WebLogicユーザーにマップします。

- SAML IDアサーション・プロバイダは、SAMLセキュリティ・アサーションのコンシューマとして機能します。これによってWebLogic ServerがSAML宛先サイトとして機能し、シングル・サインオンでのSAMLの使用をサポートするようになります。

また、以下のプロバイダを使用することもできます。

- カスタム(非WebLogic)認証プロバイダ。このプロバイダは、さまざまなタイプの認証技術を備えています。

- カスタム(非WebLogic) IDアサーション・プロバイダ。このプロバイダは、さまざまなタイプのトークンをサポートしています。

複数の認証プロバイダの使用

各セキュリティ・レルムには、少なくとも1つの認証プロバイダが構成されている必要があります。WebLogicセキュリティ・フレームワークは、さまざまな要素からなる認証向けに、複数の認証プロバイダ(したがって、複数のLoginModule)をサポートします。そのため、複数の認証プロバイダを使用できます。また、1つのセキュリティ・レルムで複数のタイプの認証プロバイダを使用できます。たとえば、網膜スキャンに基づく認証とユーザー名/パスワードに基づく認証の両方を使用してシステムにアクセスする場合、2つの認証プロバイダを構成します。

複数の認証プロバイダを構成する方法は、認証プロセスの全体的な結果に影響することがあります。認証プロバイダ間にログインの依存関係を設定し、プロバイダ間のシングル・サインオンを可能にするには、各認証プロバイダのJAAS制御フラグを構成します。「JAAS制御フラグ・オプションの設定」を参照してください。

認証プロバイダは、セキュリティ・レルムで構成された順序で呼び出されます。したがって、認証プロバイダを構成する際は注意してください。WebLogic管理コンソールを使用すると、構成済みの認証プロバイダの順序を再設定して、それらが呼び出される順序を変更できます。「認証プロバイダの順序の変更」を参照してください。

JAAS制御フラグ・オプションの設定

複数の認証プロバイダを構成する場合、各認証プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスにおける認証プロバイダの使用方法を制御します。JAAS制御フラグは、WebLogic管理コンソールで設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJAAS制御フラグの設定に関する項を参照してください。また、WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して、認証プロバイダのJAAS制御フラグを設定することもできます。

JAAS制御フラグには以下の値があります。

- REQUIRED - 認証プロバイダは常に呼び出され、ユーザーは常に認証テストを通過する必要があります。認証が成功しても失敗しても、認証はプロバイダのリストの下方に進みます。

- REQUISITE - ユーザーはこの認証プロバイダの認証テストを通過する必要があります。ユーザーがこの認証プロバイダの認証テストを通過した場合、以降の認証プロバイダは実行されますが、(JAASの「制御フラグ」属性が「REQUIRED」に設定されている認証プロバイダを除いて)失敗してもかまいません。

- SUFFICIENT - ユーザーはこの認証プロバイダの認証テストを通過する必要はありません。認証が成功した場合、以降の認証プロバイダは実行されません。認証が失敗した場合、認証はプロバイダのリストの下方に進みます。

- OPTIONAL」 - ユーザーはこの認証プロバイダの認証テストを通過することも失敗することもできます。ただし、セキュリティ・レルムで構成されているすべての認証プロバイダでJAASの「制御フラグ」属性が「OPTIONAL」に設定されている場合、ユーザーは構成済みプロバイダのいずれかの認証テストを通過する必要があります。

既存のセキュリティ・レルムにさらに認証プロバイダを追加する場合、「制御フラグ」はデフォルトで「OPTIONAL」に設定されます。必要に応じて、各認証プロバイダが認証シーケンス内で適切に機能するように、「制御フラグ」の設定と認証プロバイダの順序を変更してください。

注意:
起動プロセスの一部として、WebLogic Serverは、セキュリティ・レルムで構成されているすべてのセキュリティ・プロバイダ(JAASの「制御フラグ」が「OPTIONAL」に設定されている認証プロバイダを含む)を初期化できる必要があります。セキュリティ・プロバイダの初期化処理が完了できないと、WebLogic Serverで起動に失敗し、次のようなエラー・メッセージが生成されます。

<BEA-090870> <The realm "myrealm" failed to be loaded:

認証プロバイダの順序の変更

WebLogic Serverが複数の認証プロバイダを呼び出す順序は、認証プロセスの全体的な結果に影響します。「認証プロバイダ」表には、呼び出される順序で認証プロバイダが表示されます。デフォルトでは、認証プロバイダは構成された順序で呼び出されます。管理コンソールを使用すると、認証プロバイダの順序を変更できます。認証プロバイダがWebLogic Serverによって呼び出される順序と管理コンソールに表示される順序を変更するには、管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」ページの「並替え」ボタンを選択します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダの順番の変更に関する項を参照してください。

WebLogic認証プロバイダの構成

WebLogic認証プロバイダ(DefaultAuthenticatorとも呼ばれます)は、WebLogic Serverの組込みLDAPサーバーを使用してユーザーおよびグループ・メンバーシップ情報(さらに、電話番号、メール・アドレスなどのオプションのユーザー属性)を格納します。このプロバイダを使用すると、WebLogic Server管理コンソールでユーザーとグループ・メンバーシップを作成、変更、表示、および管理できます。WebLogic認証プロバイダのほとんどの構成オプションはデフォルトで定義されています。WebLogic認証プロバイダを構成する必要があるのは、新しいセキュリティ・レルムを作成するときのみです。ただし、次の点に注意してください。

- WebLogic認証プロバイダは、DefaultAuthenticatorという名前でデフォルト・セキュリティ・レルムに構成されています。

- WebLogic認証プロバイダのユーザー名とグループ名では大文字/小文字が区別されません。WebLogic Server管理コンソールでのユーザーとグループの作成および管理の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーおよびグループの管理に関する項を参照してください。

- すべてのユーザー名は一意でなければなりません。

- 組込みLDAPサーバーに格納されるユーザーに定義されるパスワードの最小長を指定します。これは、WebLogic認証プロバイダの「構成」→「プロバイダ固有」ページで使用可能な「最小パスワード長」オプションで指定できます。

- WebLogic認証プロバイダのユーザーは、一連の属性を含めるように変更できます。「ユーザー属性の設定」を参照してください。

- 複数の認証プロバイダを使用する場合、JAAS制御フラグを使用して、認証プロセスでのWebLogic認証プロバイダの使用方法を指定します。「複数の認証プロバイダの使用」を参照してください。

ユーザー属性の設定

WebLogic認証プロバイダでユーザーを定義すると、そのユーザーに関して表5-1に示す属性を設定または変更できます。これらの属性は、RFC 2798に示すinetOrgPerson LDAPオブジェクト・クラスの個々の属性を表すユーザー・スキーマに準拠します。

表5-1 ユーザーに設定可能な属性

属性

説明

c

2文字のISO 3166国コード

departmentnumber

ユーザーが所属する部署のコード

displayname

ユーザーの優先名

employeenumber

ユーザーに割り当てられる、数字またはアルファベットのID

employeetype

雇用主と従業員の関係を表す雇用のタイプ

facsimiletelephonenumber

ファックス番号

givenname

名前(姓やミドル・ネーム以外)

homephone

自宅の電話番号

homepostaladdress

自宅の住所

l

市、郡、その他地域の地域名

mail

ユーザーの電子アドレス(メール)

mobile

携帯電話番号

pager

ページャ電話番号

postaladdress

勤務地の住所

postofficebox

私書箱

preferredlanguage

ユーザーの優先文字言語または会話言語

st

国または州の完全名

street

ユーザーの物理的な場所

telephonenumber

組織内のユーザーの電話番号

title

ユーザーの職務権限を表す職名

属性に値を設定すると、その属性はユーザーに追加されます。同様に、属性の値を後で削除すると、その属性はユーザーから削除されます。使用可能な属性は、前述のリストに限定されます。ただし、属性名はカスタマイズできません。

これらの属性は、UserAttributeEditorMBeanに対する操作で管理され、UserAttributeReaderMBeanに対する操作で表示できます。

WebLogic認証プロバイダで作成されたユーザーの属性の設定、変更、表示については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー属性の値の管理に関する項を参照してください。

LDAP認証プロバイダの構成

この項には次のトピックが含まれます:

- WebLogic Serverに含まれるLDAP認証プロバイダ

- LDAP認証プロバイダを使用するための要件

- LDAP認証プロバイダの構成: 主な手順

- 他のLDAPサーバーへのアクセス

- SSL用のLDAP認証プロバイダの有効化

- 動的グループとWebLogic Server

- WebLogicプリンシパルでのGUIDおよびLDAP DNデータの使用

- Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成

- LDAP認証プロバイダのフェイルオーバーの構成

- Oracle Unified Directory用認証プロバイダの構成

- Active Directory認証プロバイダの参照への遵守

- WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上

- 外部LDAPサーバーからの管理者ユーザーの構成: 例

WebLogic Serverに含まれるLDAP認証プロバイダ

WebLogic Serverには、以下のLDAP認証プロバイダが用意されています。

- Oracle Internet Directory認証プロバイダ

- Oracle Virtual Directory認証プロバイダ

- iPlanet認証プロバイダ

- Active Directory認証プロバイダ

- Open LDAP認証プロバイダ

- Novell認証プロバイダ

- 汎用LDAP認証プロバイダ

各LDAP認証プロバイダが外部LDAPサーバーにユーザーおよびグループの情報を格納します。主な相違点は、それぞれが対応するLDAPサーバー用の一般的なディレクトリ・スキーマに合わせて構成されていることです。Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダを、ユーザーおよびグループ属性のLDAPスキーマに合せるように構成する方法は、「Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成」を参照してください。

WebLogic Serverは、特定のLDAPサーバーをサポートおよび証明しません。LDAP v2またはv3準拠のすべてのLDAPサーバーはWebLogic Serverと正常に連係します。以下のLDAPディレクトリ・サーバーについてはテスト済みです。

- Oracle Internet Directory

- Oracle Virtual Directory

- Oracle Unified Directory

- Sun iPlanetバージョン4.1.3

- Windows 2000の一部として出荷されているActive Directory

- Open LDAPバージョン2.0.7

- Novell NDSバージョン8.5.1

LDAP認証プロバイダを使用して他のLDAPサーバーにアクセスできます。ただし、LDAP認証プロバイダ(LDAPAuthenticator)を使用するか、または定義済みのLDAPプロバイダを選択してカスタマイズする必要があります。「他のLDAPサーバーへのアクセス」を参照してください。

注意:
Active Directory認証プロバイダではMicrosoft Active Directory Application Mode (ADAM)もスタンドアロンのディレクトリ・サーバーとしてサポートしています。

LDAP認証プロバイダを使用するための要件

LDAP認証プロバイダがセキュリティ・レルムに構成されている唯一の認証プロバイダの場合、WebLogic Serverを起動してLDAPディレクトリ内のユーザーまたはグループを使用するには、Adminロールを持つ必要があります。LDAPディレクトリで、次のいずれかを行います。

- WebLogic Serverでは、デフォルトでAdminロールにAdministratorsグループが含まれています。LDAPディレクトリにAdministratorsグループがない場合は作成します。WebLogic Serverを起動するLDAPユーザーがこのグループに含まれていることを確認します。
Active Directory LDAPディレクトリには、Administratorsというデフォルト・グループがあります。WebLogic Serverを起動するユーザーをAdministratorsグループに追加し、「グループ・ベースDN」を定義してAdministratorsグループが見つかるようにします。

- LDAPディレクトリにAdministratorsグループを作成しない場合(LDAPディレクトリが別の目的でAdministratorsグループを使用する場合など)、LDAPディレクトリに新しいグループを作成(または既存のグループを使用)して、WebLogic Serverを起動するユーザーをそのグループに追加します。その後、WebLogic管理コンソールで、そのグループにAdminロールを割り当てます。

注意:
Adminロールが割り当てられているグループにWebLogic Serverを起動するLDAPユーザーが正しく追加されておらず、セキュリティ・レルムが構成されている認証プロバイダがLDAP認証プロバイダのみである場合は、WebLogic Serverを起動することができません。

LDAP認証プロバイダの構成: 主な手順

LDAP認証プロバイダは以下のように構成します。

1. LDAPサーバーに一致するLDAP認証プロバイダを選択し、セキュリティ・レルムのプロバイダ・インスタンスを作成します。詳細は、次のトピックを参照してください。

- WebLogic Server管理コンソールを使用する場合、Oracle WebLogic Server管理コンソール・ヘルプの認証とIDアサーション・プロバイダの構成に関する項を参照してください。

- WebLogic Scripting Tool (WLST)を使用する場合、『Oracle WebLogic Scripting Tool』のセキュリティ・データの管理(WLSTオンライン)に関する項を参照してください。また、この項では、あるLDAP認証プロバイダから別の認証プロバイダに切り替えるためにWLSTを使用する方法も説明します。

2. 管理コンソールを使用して、LDAP認証プロバイダのプロバイダ固有の属性を構成します。LDAP認証プロバイダごとに、次の属性が存在します。

1. LDAPサーバーとLDAP認証プロバイダの間の通信を有効にします。デプロイメントをよりセキュアにするために、SSLプロトコルを使用してLDAPサーバーとWebLogic Server間の通信を保護することをお薦めします。SSLを有効にするには、「SSLを有効化」属性を使用します。

2. LDAP認証プロバイダがLDAPディレクトリを検索する方法を指定するオプションを構成します。

注意:
principal用に入力した値は、対応LDAPサーバーでユーザーやグループを検索できる権限のあるLDAP管理者にする必要があります。LDAP管理者にLDAPサーバーで検索できる権限がないと、エラー・コードが50であるLDAP例外が生成されます。

3. LDAPディレクトリ構造でのユーザーの場所を指定します。

4. LDAPディレクトリ構造でのグループの場所を指定します。

注意:
次のLDAPAuthenticatorMBean属性を使用してユーザーまたはグループのLDAP検索フィルタを指定する際、ワイルドカードを使用できますが、特に次の組合せを使用すると、LDAPサーバーのパフォーマンスに悪影響を及ぼすことがあります。

- AllUsersFilter

- UserFromNameFilter

- AllGroupsFilter

- GroupFromNameFilter

たとえば、次のフィルタ式では5つのワイルドカード条件を組み合せており、条件ごとにワイルドカードでアスタリスク文字を2文字使用しています。

(|(cn=*wall*)(givenname=*wall*)(sn=*wall*)(cn=*wall*)(mail=*wall*))

前述のフィルタ例では相当のオーバーヘッドが対応LDAPサーバーで発生する可能性があります。

5. グループのメンバーの配置方法を定義します。

6. LDAPサーバーで定義されるグローバル・ユニバーサル識別子(GUID)属性の名前を設定します。

注意:
Oracle Internet DirectoryまたはOracle Virtual Directory認証プロバイダを構成する場合は、「Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成」を参照してください。この節では、ユーザーおよびグループの認証プロバイダ属性を、LDAPディレクトリ構造に一致させる方法について説明します。

7. LDAPサーバーとの接続用にタイムアウト値を設定します。接続タイムアウトとソケット・タイムのタイムアウト値を指定できます。
接続タイムアウト(すべてのLDAP認証プロバイダのLDAPServerMBean.ConnectTimeout属性で指定)のデフォルト値はゼロです。このデフォルト設定はタイムアウト制限がないことを示し、LDAP認証プロバイダに構成されているLDAPサーバーが使用できないと、この設定によってWebLogic Serverの実行処理速度が低下する場合があります。さらに、WebLogic Serverに複数のLDAP認証プロバイダが構成されている場合、1つのLDAPサーバーへの接続が失敗すると、それ以外のLDAP認証プロバイダの使用がブロックされます。

LDAP認証プロバイダのLDAPServerMBean.ConnectTimeout属性をゼロでない値(たとえば、60秒)に設定することをお薦めします。この値は、WebLogic Server管理コンソールまたはWLSTで設定できます。また、LDAP認証プロバイダの次の構成パラメータを追加して、config.xmlファイルでこの値を設定することもできます。

<wls:connect-time>60</wls:connect-time>

注意:
config.xmlファイルは直接編集しないことをお薦めします。

-Dweblogic.security.providers.authentication.ldap.socketTimeoutのJVM構成オプションで指定されるソケット・タイムアウトにより、LDAPServerMBean.Host属性で指定されるいずれか1つのLDAPサーバーへの接続のタイムアウトを秒単位で設定します。ソケット・タイムアウトのデフォルト値は0です。その場合、ソケット・タイムアウトは接続で設定されません。

LDAP認証プロバイダの接続タイムアウトとソケット・タイムアウトに設定する適切な値については、「LDAP認証プロバイダのフェイルオーバーの構成」を参照してください。

3. LDAPサーバーのキャッシュを制御するパフォーマンス・オプションを構成します。管理コンソールの「構成」の「プロバイダ固有」および「パフォーマンス」ページでキャッシュを構成します。「WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上」を参照してください。

注意:
LDAP認証プロバイダをLDAPサーバーに接続できない場合や例外がスローされた場合は、LDAP認証プロバイダの構成をチェックし、対応するLDAPサーバーの設定と一致していることを確認してください。

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

- 他のLDAPサーバーへのアクセス

- SSL用のLDAP認証プロバイダの有効化

- 動的グループとWebLogic Server

- WebLogicプリンシパルでのGUIDおよびLDAP DNデータの使用

- Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成

- LDAP認証プロバイダのフェイルオーバーの構成

- Oracle Unified Directory用認証プロバイダの構成

- Active Directory認証プロバイダの参照への遵守

- WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上

他のLDAPサーバーへのアクセス

このリリースのWebLogic ServerのLDAP認証プロバイダは、SunONE (iPlanet)、Oracle Internet Directory、Oracle Virtual Directory、SunONE (iPlanet)、Active Directory、Open LDAP、およびNovell NDSのLDAPサーバーと容易に連携動作します。また、LDAP認証プロバイダを使用すると、他のタイプのLDAPサーバーにアクセスできます。LDAP認証プロバイダ(LDAPAuthenticator)または新しいLDAPサーバーにもっともよく適合する既存のLDAPプロバイダを選択し、そのLDAPサーバーのディレクトリ・スキーマと他の属性に合わせて既存の構成をカスタマイズします。

Oracle Unified Directoryを使用する場合、「Oracle Unified Directory認証プロバイダの構成」を参照してください。

Active Directoryを使用する場合、「Active Directory認証プロバイダの参照への遵守」を参照してください。

SSL用のLDAP認証プロバイダの有効化

WebLogic ServerとLDAPサーバー間の接続を保護する場合(たとえば、LDAPサーバーが要求するため)、次の手順を実行する必要があります。

- LDAPサーバーと併用するためのカスタム信頼キーストアを作成して構成します

- SSLプロトコルがLDAPサーバー接続時にLDAP認証プロバイダによって使用されるように指定します

これを行うには、次の手順を実行します。

1. LDAP認証プロバイダを構成します。「構成」>「プロバイダ固有」ページ上で「SSLEnabled」を選択していることを確認します。

2. LDAPサーバー用のルート認証局(CA)の証明書を取得します。

3. 前述の証明書を使用して信頼キーストアを作成します。たとえば、次の例では、ルートCA証明書rootca.pemを使用してキーストアldapTrustKSを作成するためのkeytoolコマンドの使用を示します。

keytool -import -keystore ./ldapTrustKS -trustcacerts -alias oidtrust -file rootca.pem -storepass TrustKeystorePwd -noprompt

信頼キーストアの作成の詳細は、第11章「IDと信頼の構成」を参照してください。

4. WebLogic Serverのアクセス元の場所にキーストアをコピーします。

5. WebLogic Server管理コンソールを起動し、サーバー名>「構成」>「キーストア」ページに移動します。ここで、サーバー名は、このキーストアを構成する対象のWebLogic Serverインスタンスです。

6. 必要に応じて、「キーストア」フィールドで、「変更」をクリックして「カスタムIDとカスタム信頼」構成ルールを選択します。

7. LDAPサーバーとの通信が双方向SSLを使用する場合、カスタムIDキーストア、キーストア・タイプ、およびパスフレーズを構成します。

8. 「カスタム信頼キーストア」で、手順2で作成した信頼キーストアのパスとファイル名を入力します。

9. 「カスタム信頼キーストアのタイプ」で、jksと入力します。

10. 「カスタム信頼キーストアのパスフレーズ」で、キーストア作成時に使用されたパスワードを入力します。

11. 変更を適用するには、WebLogic Serverインスタンスを再起動します。

詳細は、第12章「SSLの構成」を参照してください。WebLogic Server管理コンソールを使用してキーストアを構成し、SSLを有効化するための詳細は、Oracle WebLogic Server管理コンソール・ヘルプに記載されている次のトピックを参照してください。

- 「IDおよび信頼の構成」

- 「SSLの設定」

- 「双方向SSLの構成」

動的グループとWebLogic Server

多くのLDAPサーバーには、動的グループまたは仮想グループの概念があります。これらは、ユーザーとグループのリストで構成されるグループではなく、グループに属するユーザーの集合を定義するポリシー文、問合せ、またはコードを格納するグループです。あるグループが動的としてマークされる場合、ユーザーはグループ・メンバーシップへの何らかの変更が有効になる前にログアウトし、ログインし直す必要があります。動的という用語は、グループを定義する方法を指します。WebLogic Server内でのグループの実行時セマンティクスを指すものではありません。

WebLogicプリンシパルでのGUIDおよびLDAP DNデータの使用

ユーザーがWebLogic Serverに認証される場合、認証プロバイダはユーザーとグループのプリンシパルでサブジェクトを作成します。プリンシパルには、ユーザーとグループの名前がそれぞれ含まれます。WebLogic Serverに含まれるLDAP認証プロバイダは、これらのプリンシパルの属性として、ユーザーとグループのグローバル・ユニバーサル識別子(GUID)とLDAP識別名(DN)のデータも格納します。デフォルトでは、WebLogicプリンシパルでGUIDやDNのデータは使用されません。ただし、WebLogicドメインがJAAS認可を使用するように構成される場合、Javaポリシー決定で生じるプリンシパルの比較操作でGUIDとDNのデータを使用できます。

LDAP認証プロバイダを構成する場合、LDAPサーバーで定義されるGUID属性の名前をそのプロバイダに対して正しく指定します。WebLogic Serverに含まれる各LDAP認証プロバイダのデフォルトのGUID属性名を表5-2に示します。

表5-2 WebLogic ServerのLDAP認証プロバイダのGUID属性名

プロバイダ

デフォルトのGUID属性名

WebLogic認証プロバイダ

orclguid脚注1

Oracle Internet Directory認証プロバイダ

orclguid

Oracle Virtual Directory認証プロバイダ

orclguid脚注 2

Active Directory認証プロバイダ

objectguid脚注3

iPlanet認証プロバイダ

nsuniqueid

Novell認証プロバイダ

guid

Open LDAP認証プロバイダ

entryuuid

脚注 1 組込みLDAPサーバーのGUID属性名は変更できないため、WebLogic認証プロバイダに、構成可能な対応属性はありません。

脚注 2 Oracle Virtual Directory認証プロバイダに構成するGUID属性名は、Oracle Virtual Directoryにこの属性名のマッピングがあるかどうかによって異なります。マッピングは、Oracle Virtual Directoryと接続するLDAPサーバーで定義される名前から変更されるこの属性の名前を指定します。マッピングが存在する場合、マッピングで定義される名前を指定します。たとえば、マッピングでGUID属性の名前がOVDguidに変更される場合、OVDguidをGUID属性名として使用するようにOracle Virtual Directory認証プロバイダを構成します。マッピングが存在しない場合、LDAPサーバーで定義される名前を指定します。たとえば、LDAPサーバーがSun iPlanet Directoryで、Sun iPlanet DirectoryがGUID属性名をnsuniqueidと定義する場合、nsuniqueidを使用するようにOracle Virtual Directory認証プロバイダを構成します。詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のOracle Virtual Directoryのマッピングの理解に関する項を参照してください。

脚注 3 Active Directory認証プロバイダではMicrosoft Active Directory Application Mode (ADAM)もスタンドアロンのディレクトリ・サーバーとしてサポートしています。

プリンシパル・オブジェクトでのGUIDとDNデータの使用については、「JAAS認可を使用するドメインの構成」を参照してください。

Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでの
ユーザーおよびグループの構成

以下の節では、Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダのデフォルト値を変更して、LDAPサーバー内でユーザーやグループをどのように配置するかを指定する方法について説明します。

- ユーザーおよびグループの名前タイプの構成

- 静的グループの構成

ユーザーおよびグループの名前タイプの構成

Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダは、デフォルトでは表5-3に示すクラス属性タイプを使用してLDAPディレクトリ内のユーザーおよびグループを検索するように構成されています。

表5-3 検索で使用されるクラス属性タイプ

クラス

属性

タイプ

ユーザー・オブジェクト・クラス

ユーザー名

cn

グループ・オブジェクト・クラス

グループ名

cn

LDAPディレクトリ構造内に定義されているユーザー名属性タイプまたはグループ名属性タイプが、使用している認証プロバイダのデフォルト設定と異なる場合は、それらのプロバイダの設定を変更する必要があります。以下の節では、これらの設定を変更する方法について説明します。

注意:
LDAPサーバー内のユーザーまたはグループの名前に無効な文字が含まれている場合、Oracle Internet Directory認証プロバイダおよびOracle Virtual Directory認証プロバイダはそれらの名前を読み取ることができません。無効な文字は以下のとおりです。

- カンマ(,)

- プラス記号(+)

- 引用符(")

- バックスラッシュ(\)

- 山カッコ(<および>)

- セミコロン(;)

無効な文字を含むグループ名やユーザー名は、これらの認証プロバイダでは無視されます。(WebLogic Serverでは、通常、無効な文字を含むグループ名はサポートされません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグループの作成に関する項を参照してください。)

ユーザー名属性タイプを変更する

Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダは、デフォルトではタイプがcnに設定されたユーザー名属性で構成されています。LDAPディレクトリ構造内のユーザー名属性タイプが別のタイプ(たとえばuid)である場合は、以下の認証プロバイダ属性を変更する必要があります。

- AllUsersFilter

- UserFromNameFilter

- UserNameAttribute

たとえば、LDAPディレクトリ構造のユーザー名属性タイプがuidである場合は、上に示した認証プロバイダ属性を表5-4のように変更する必要があります。変更が必要な部分が太字で示されています。

表5-4 ユーザー・オブジェクト・クラスのユーザー名属性タイプの変更

属性名

デフォルト設定

必要な新規の設定

UserNameAttribute

cn

uid

AllUsersFilter脚注1

(&(cn=*)(objectclass=person))

(&(uid=*)(objectclass=person))

UserFromNameFilter脚注1

(&(cn=%u)(objectclass=person))

(&(uid=%u)(objectclass=person))

脚注 1 LDAP検索フィルタをユーザーやグループに対して指定する際、ワイルドカードが受け入れられます。ただし、特にユーザー名またはグループ名属性に対してアスタリスクのワイルドカードを複数使用すると、LDAPサーバーのパフォーマンスに悪影響を及ぼします。

ユーザー名属性タイプの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「Oracle Internet Directory認証プロバイダの構成」

- 「Oracle Virtual Directory認証プロバイダの構成」

グループ名属性タイプを変更する

Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダは、デフォルトではグループ名属性タイプがcnに設定された静的および動的グループ・オブジェクト・クラスで構成されています。LDAPディレクトリ構造内のグループ名属性タイプに別のタイプ(たとえばuid)が使用されている場合は、以下の認証プロバイダ属性を変更する必要があります。

- AllGroupsFilter

- GroupFromNameFilter

- StaticGroupNameAttribute (静的グループ用)

- DynamicGroupNameAttribute (動的グループ用)

たとえば、グループ・オブジェクト・クラスのLDAPディレクトリ構造でグループ名属性タイプとしてuidを使用している場合は、認証プロバイダ属性を表5-5のように変更する必要があります。変更が必要な部分が太字で示されています。

表5-5 グループ名属性タイプの必要な変更

属性名

デフォルト設定

必要な変更

StaticGroupNameAttribute

cn

uid

DynamicGroupNameAttribute

cn

uid

AllGroupsFilter脚注1

(&(cn=*)(|(objectclass=groupofUniqueNames)(objectclass=orcldynamicgroup)))

(&(uid=*)(|(objectclass=groupofUniqueNames)(objectclass=orcldynamicgroup)))

GroupFromNameFilter脚注1

(|(&(cn=%g)(objectclass=groupofUniqueNames))(&(cn=%g)(objectclass=orcldynamicgroup)))

(|(&(uid=%g)(objectclass=groupofUniqueNames))(&(uid=%g)(objectclass=orcldynamicgroup)))

脚注 1 LDAP検索フィルタをユーザーやグループに対して指定する際、ワイルドカードが受け入れられます。ただし、特にユーザー名またはグループ名属性に対してアスタリスクのワイルドカードを複数使用すると、LDAPサーバーのパフォーマンスに悪影響を及ぼします。

グループ名属性の構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「Oracle Internet Directory認証プロバイダの構成」

- 「Oracle Virtual Directory認証プロバイダの構成」

静的グループの構成

Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダは、デフォルトでは以下のように設定された静的グループで構成されています。

- 静的グループ・オブジェクト・クラス名はgroupofuniquenames

- 静的メンバーDN属性のタイプはuniquemember

一方、これらの認証プロバイダのどちらかを構成するOracle Internet DirectoryまたはOracle Virtual DirectoryのLDAPサーバーのディレクトリ構造では、静的グループが次のように定義されているかもしれません。

- 静的グループ・オブジェクト・クラス名はgroupofnames

- 静的メンバーDN属性のタイプはmember

LDAPデータベース・スキーマにgroupofnamesという静的グループ・オブジェクト・クラス名とmemberタイプの静的メンバーDN属性が含まれている場合は、Oracle Internet DirectoryまたはOracle Virtual Directory認証プロバイダの属性設定を表5-6のように変更する必要があります。変更が必要な部分が太字で示されています。

表5-6 Oracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでの静的グループの属性設定

属性

デフォルト設定

必要な変更

StaticGroupObjectClass

groupofuniquenames

groupofnames

StaticMemberDNAttribute

uniquemember

member

AllGroupsFilter脚注1

(&(cn=*)(|(objectclass=groupofUniqueNames)(objectclass=orcldynamicgroup)))

(&(cn=*)(|(objectclass=groupofnames)(objectclass=orcldynamicgroup)))

GroupFromNameFilter脚注1

(|(&(cn=%g)(objectclass=groupofUniqueNames))(&(cn=%g)(objectclass=orcldynamicgroup)))

(|(&(cn=%g)(objectclass=groupofnames))(&(cn=%g)(objectclass=orcldynamicgroup)))

脚注 1 LDAP検索フィルタをユーザーやグループに対して指定する際、ワイルドカードが受け入れられます。ただし、特にユーザー名またはグループ名属性に対してアスタリスクのワイルドカードを複数使用すると、LDAPサーバーのパフォーマンスに悪影響を及ぼします。

静的グループの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「Oracle Internet Directory認証プロバイダの構成」

- 「Oracle Virtual Directory認証プロバイダの構成」

LDAP認証プロバイダのフェイルオーバーの構成

複数のLDAPサーバーと連携するLDAPプロバイダを構成し、1つのLDAPサーバーが利用できない場合のフェイルオーバーを有効にできます。「ホスト」属性(管理コンソールのLDAP認証プロバイダの「構成」→「プロバイダ固有」ページにある)を使用して、別のLDAPサーバーの名前を指定します。各ホスト名は、末尾のスペースやポート番号が入ってもかまいません。また、LDAP認証プロバイダの「パラレル接続遅延」属性および「接続タイムアウト」属性を設定します。

- パラレル接続遅延 - 複数のサーバーに同時に接続を試みるときに遅延する秒数を指定します。接続の試行はリストの最初のサーバーに対して行われます。現在のホストへの接続が失敗した場合にのみ、リスト中の次のエントリが試行されます。この設定では、ホストがダウンしている場合にアプリケーションが許容しがたいほど長い時間ブロックされる場合があります。値が0より大きい場合、指定した遅延秒数が経過すると、別の接続設定スレッドが開始されます。値が0の場合、接続の試行はシリアライズされます。

- 接続タイムアウト - LDAPサーバーへの接続が確立されるまでに待機する最長時間を秒単位で指定します。値が0に設定されている場合(デフォルト)、最大の時間制限はなく、TCP/IPレイヤーがタイム・アウトになって接続の失敗を返すまでWebLogic Serverは待機します。
複数のホストが「ホスト」属性で設定されていると、すべての指定ホストとの接続試行における合計タイムアウト値を接続タイムアウトにより制御します。

TCP/IPの構成に応じて、接続タイムアウトを60秒以上の値に設定することをお薦めします。

- ソケット・タイムアウト -「ホスト」属性で指定される1台のホストとの接続が確立されるまでに待機する最長時間を秒単位で指定します。WebLogic Serverが動作するJVMの-Dweblogic.security.providers.authentication.ldap.socketTimeout=secondsセキュリティ・パラメータを使用することでのみソケット・タイムアウトを指定します。ソケット・タイムアウトのデフォルト値は0です。その場合、ソケット・タイムアウトは設定されません。
ソケット・タイムアウトはWebLogic Server管理コンソールで設定できません。WebLogic Serverセキュリティ・パラメータを構成するためのオプションの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のセキュリティに関する項を参照してください。

以下の例は、LDAP認証プロバイダのLDAPフェイルオーバーが構成されている場合のシナリオを示しています。

LDAPフェイルオーバーの例1

次のシナリオでは、LDAP認証プロバイダの「ホスト」属性に、directory.knowledge.com:1050、people.catalog.com、199.254.1.2という3つのサーバーが構成されています。これらのLDAPサーバーのステータスは次のとおりです。

- directory.knowledge.com:1050はダウンしています

- people.catalog.comはアクティブです

- 199.254.1.2はアクティブです

WebLogic Serverはdirectory.knowledge.comに接続しようとします。3秒後やソケット接続で例外がスローされた場合、接続の試行はタイムアウトになり、WebLogic Serverは指定された次のホスト(people.catalog.com)に接続しようとします。WebLogic Serverは、この接続のLDAPサーバーとしてpeople.catalog.comを使用します。それ以外の場合、さらに3秒後にWebLogic Serverで199.254.1.2との接続を試行します。この処理は続行しますが、全体のLDAPサーバー接続処理が10秒を超過すると失敗します。

表5-7 LDAP構成の例1

LDAPオプション

値

ホスト

directory.knowledge.com:1050 people.catalog.com 199.254.1.2

パラレル接続遅延

0

接続タイムアウト

10

ソケット・タイムアウト

3

LDAPフェイルオーバーの例2

次のシナリオでは、WebLogic Serverはdirectory.knowledge.comに接続しようとします。1秒後(「パラレル接続遅延」属性で指定)、接続の試行はタイムアウトになり、WebLogic Serverは指定された次のホスト(people.catalog.com)とdirectory.knowledge.comに同時に接続しようとします。people.catalog.comとの接続が成功すると、WebLogic Serverは、この接続のLDAPサーバーとしてpeople.catalog.comを使用します。people.catalog.comとの接続が成功すると、WebLogic Serverでdirectory.knowledge.comとの接続を取り消します。

表5-8 LDAP構成の例2

LDAPオプション

値

ホスト

directory.knowledge.com:1050 people.catalog.com 199.254.1.2

パラレル接続遅延

1

接続タイムアウト

10

ソケット・タイムアウト

3

Oracle Unified Directory認証プロバイダの構成

Oracle Unified Directory用の認証プロバイダを構成するには、次の手順を実行します。

1. 管理コンソールで、「セキュリティ・レルム」>「レルム名」>「プロバイダ」>「認証」ページに移動します。

2. 「新規」をクリックして、新しい認証プロバイダを追加します。

3. 認証プロバイダの名前を入力し、「タイプ」はIPlanetAuthenticatorを選択します。

4. 「OK」をクリックします。

5. 「セキュリティ・レルム」>「レルム名」>「プロバイダ」>「認証」ページに移動し、作成したiPlanet認証プロバイダの名前をクリックし、「構成」 > 「プロバイダ固有」ページを選択します。

6. Oracle Unified Directory用の接続属性に加え、必要に応じて他の属性も構成します。

7. ページの下部にある「GUID属性」フィールドにnsuniqueidの値をentryuuidに変更します。

8. 「保存」をクリックします。

Active Directory認証プロバイダの参照への遵守

Active DirectoryがLDAP参照を使用する場合、LDAPServerMBean.FollowReferrals属性が有効化されていることを確認して、LDAP参照に従うようにActive Directory認証プロバイダを構成する必要があります。この属性はデフォルトで有効化されていますが、厳密に有効化されていることを確認することをお薦めします。

WLSTまたはWebLogic Server管理コンソールを使用してこの属性を有効化できます。管理コンソールを使用する場合、この属性はActive Directory認証プロバイダの「構成」>「プロバイダ固有」ページから使用できます。

WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスの向上

WebLogic認証プロバイダとLDAP認証プロバイダのパフォーマンスを向上させるには、以下を行います。

- WebLogic認証プロバイダおよびLDAP認証プロバイダで使用されるグループ・メンバーシップ・キャッシュを最適化します。「グループ・メンバーシップ・キャッシュの最適化」を参照してください。

- 接続プール・サイズとユーザー・キャッシュを最適化します。「接続プール・サイズとユーザー・キャッシュの最適化」を参照してください。

- セキュリティ・レルムのプリンシパル検証プロバイダのキャッシュを公開して、そのしきい値を増加させます。「プリンシパル検証プロバイダ・キャッシュの最適化」を参照してください。

- Active Directory認証プロバイダを使用する場合、このプロバイダがtokenGroupsオプションを使用してグループ・メンバーシップのルックアップを実行するように構成します。tokenGroupsオプションは、完全にフラット化されたユーザーのグループ・メンバーシップをシステムID (SID)値の配列として保持しています。このSID値はActive Directoryにおいて特別な索引付けがされており、これによりルックアップのレスポンスが高速になります。「Active Directory認証プロバイダの構成によるパフォーマンスの向上」を参照してください。

グループ・メンバーシップ・キャッシュの最適化

WebLogic認証プロバイダとLDAP認証プロバイダ用のグループ・メンバーシップ・キャッシュを最適化するには、以下の属性を設定します(管理コンソールのLDAP認証プロバイダの「構成」の「プロバイダ固有」および「パフォーマンス」ページ)。

- グループ・メンバーシップ検索 - 「プロバイダ固有」ページから使用できます。この属性はグループ検索が深さにおいて制限されるかどうかを制御します。このオプションによって、ネストされたグループへの検索の深さの程度が制御されます。ネストされたグループ階層の最初のレベルのみを使用する構成の場合、このオプションによって検索がグループの最初のレベルに制限されるのでユーザー検索時のパフォーマンスが向上します。

- 制限された検索を定義した場合は、「グループ・メンバーシップ検索の最大レベル」も定義する必要があります。

- 制限されない検索を定義した場合、「グループ・メンバーシップ検索の最大レベル」は無視されます。

- グループ・メンバーシップ検索の最大レベル - 「プロバイダ固有」ページから使用できます。この属性は、「グループ・メンバーシップ検索」が定義されている場合にグループ・メンバーシップ検索の深さを制御します。指定可能な値を次に示します。

- 0 - 直接のグループのみが検索されることを示します。つまり、グループAのメンバーシップを検索する場合、グループAの直接のメンバーのみが検出されます。グループBがグループAのメンバーである場合、そのメンバーはこの検索では検出されません。

- 任意の正の数字 - 検索するレベル数を示します。たとえば、このオプションを1に設定した場合、グループAのメンバーシップの検索ではグループAの直接のメンバーが返されます。グループBがグループAのメンバーである場合、この検索ではグループBのメンバーも検出されます。ただし、グループCがグループBのメンバーである場合、この検索ではグループCのメンバーは検出されません。

- グループ・メンバーシップ・ルックアップの階層キャッシングを有効化 - 「パフォーマンス」ページから使用できます。この属性は、再帰的なメンバーシップ・ルックアップ中に見つかったグループ・メンバーシップ階層がキャッシュされるかどうかを示します。見つかった各サブツリーがキャッシュされます。キャッシュは、あるグループがメンバーになっているグループを保持します。この設定は、「グループ・メンバーシップ検索」属性が有効になっている場合にのみ適用されます。このオプションはデフォルトによって無効にされています。

- キャッシュ内の最大グループ階層数 - 「パフォーマンス」ページから使用できます。この属性は、グループ・メンバーシップ階層を保持する最長時間未使用(LRU)キャッシュの最大サイズを指定します。値を1024に設定することをお薦めします。この設定は、「グループ・メンバーシップ・ルックアップの階層キャッシングの有効化」が有効になっている場合にのみ適用されます。

- グループ階層キャッシュTTL - 「パフォーマンス」ページから使用できます。この属性は、キャッシュされたエントリがキャッシュ内に何秒間留まるかを指定します。デフォルトでは60秒です。値を6000に設定することをお薦めします。

キャッシュを設定する場合は、以下の点に留意する必要があります。

- キャッシュの有効化には、パフォーマンスと正確性のトレードオフが伴います。キャッシュを使用することでデータの取得は高速化されますが、そのデータは使用可能な最新のものではないおそれがあります。

- 存続時間(TTL)には、古くなっているおそれがあるデータを受け入れる時間の程度を設定します。この値はビジネス上のニーズによって大きく異なります。ユーザーに対してグループ・メンバーシップを頻繁に変更する場合は、長時間のTTLではグループ関連の変更がしばらくの間反映されないことがあります。この場合は短時間のTTLを使用します。ユーザーの追加後、グループ・メンバーシップがほとんど変更されない場合は、TTLが多少長くてもかまいません。

- キャッシュ・サイズは、キャッシュTTL同様、使用可能なメモリー量と関連します。TTLの間にロードされるエントリ数を考慮し、その数を基準にキャッシュのサイズを設定してください。TTLが長時間になるほど、大きいキャッシュ・サイズが必要になる傾向があります。

接続プール・サイズとユーザー・キャッシュの最適化

任意のLDAP認証プロバイダを構成するとき、LDAP接続プールとユーザー・キャッシュのサイズを最適化することによって、WebLogic ServerとLDAPサーバー間の接続パフォーマンスを向上できます。これらの最適化を行うには、次の手順を実行します。

1. 次の方法のいずれかを使用して、LDAP接続プール・サイズを100に設定します。

- WebLogicドメインのbinディレクトリにあるsetDomainEnvスクリプトの次のシステム・プロパティを定義します。

-Dweblogic.security.providers.authentication.LDAPDelegatePoolSize=100

- WebLogic Server管理コンソールで、構成するLDAP認証プロバイダの「プロバイダ固有」ページ(「セキュリティ・レルム」>myrealm>「プロバイダ」>「認証」>使用するLDAP認証プロバイダ>「プロバイダ固有」)を選択し、「接続プール・サイズ」というラベルのフィールドで100を指定します。

2. WebLogic Server管理コンソールで次の手順を完了させ、LDAPサーバーで使用するキャッシュを有効化して拡大します。

1. LDAP認証プロバイダの「プロバイダ固有」ページ(「セキュリティ・レルム」>myrealm>「プロバイダ」>「認証」>使用するLDAP認証プロバイダ>「プロバイダ固有」)を選択します。

2. 最下部までスクロールし、「キャッシュの有効化」がチェックされていることを確認します。

3. 「キャッシュ・サイズ」というラベルのフィールドで、値を3200 KBに指定します。

4. 「キャッシュTTL」というラベルのフィールドで、「グループ階層キャッシュTTL」値に一致するTTL値を指定します(「グループ・メンバーシップ・キャッシュの最適化」を参照)。値を6000に設定することをお薦めします。

5. LDAPサーバーに結果のタイムアウト値を設定します。現在の「プロバイダ固有」構成ページで、「結果タイム・リミット」というラベルのフィールドで値を1000 msに指定します。

3. WebLogic Serverを再起動して、変更を有効にします。

iPlanet認証プロバイダでの動的グループの構成によるパフォーマンスの向上

動的グループでは、メンバー名のリストは表示されません。かわりに、動的グループのメンバーシップは、ユーザー属性の一致によって作成されます。動的グループのグループ・メンバーシップは動的に計算される必要があるため、大規模なグループではパフォーマンスの問題が発生するおそれがあります。iPlanet認証プロバイダを適切に構成することで、動的グループが関係する個所のパフォーマンスを向上できます。

iPlanet認証プロバイダの「ユーザー動的グループDN属性」属性には、ユーザーが所属する動的グループの識別名(DN)を指定するLDAPユーザー・オブジェクトの属性を指定します。この属性が指定されていない場合、WebLogic Serverは、動的グループのURLを評価することでユーザーがグループのメンバーかどうかを判定します。デフォルトでは「ユーザー動的グループDN属性」はnullです。「ユーザー動的グループDN属性」に他の何らかの値を設定してパフォーマンスを向上させる場合は、iPlanet認証プロバイダに以下の属性を設定します。

UserDynamicGroupDNAttribute="wlsMemberOf"
DynamicGroupNameAttribute="cn"
DynamicGroupObjectClass=""
DynamicMemberURLAttribute=""

これらの属性を管理コンソールで設定するには:

1. 「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」を展開します。

2. iPlanet認証プロバイダの「プロバイダ固有」タブで「ユーザー動的グループDN属性」を設定します。「動的グループ・オブジェクト・クラス」および「動的メンバーURL属性」をnullに設定(フィールド内の値を削除)し、「動的グループ名属性」の設定はcnのままにしておきます。

プリンシパル検証プロバイダ・キャッシュの最適化

WebLogic認証プロバイダまたはLDAP認証プロバイダのパフォーマンスを向上させるために、必要に応じて、WebLogicプリンシパル検証プロバイダによって使用されるキャッシュの設定を大きくすることができます。WebLogicプリンシパル検証プロバイダによって使用されるプリンシパル検証プロバイダ・キャッシュは、署名されたWLSAbstractPrincipalをキャッシュします。プリンシパル検証プロバイダ・キャッシュを最適化するには、使用しているセキュリティ・レルム用のこれらの属性を設定します(管理コンソールの該当セキュリティ・レルムの「構成」>「パフォーマンス」ページ)。

- 「WebLogicプリンシパル検証プロバイダ・キャッシュを有効化」 - WebLogicプリンシパル検証プロバイダがキャッシュを使用するかどうかを示します。この設定は、セキュリティ・レルム内の認証プロバイダがWebLogicプリンシパル検証プロバイダとWLSAbstractPrincipalを使用する場合にのみ適用されます。このオプションはデフォルトでは有効になっています。

- 「キャッシュ内の最大WebLogicプリンシパル数」 - 有効性が検証されたWLSAbstractPrincipalに対して使用される最長時間未使用(LRU)キャッシュの最大サイズです。デフォルトの設定は500です。この設定は「WebLogicプリンシパル検証プロバイダ・キャッシュを有効化」が有効な場合にのみ適用されます。

Active Directory認証プロバイダの構成によるパフォーマンスの向上

Active Directory認証プロバイダでtokenGroupsオプションを使用するように構成するには、以下の属性を設定します(管理コンソールのActive Directory認証プロバイダの「構成|プロバイダ固有」ページ)。

- 「グループ・メンバーシップ・ルックアップでトークン・グループを使用する」 - 標準の再帰的なグループ・メンバーシップ・ルックアップ・アルゴリズムではなく、Active DirectoryのtokenGroupsルックアップ・アルゴリズムを使用するかどうかを指定します。デフォルトでは、このオプションは有効ではありません。

注意:
tokenGroupsオプションへのアクセスが必要になります(つまり、LDAPディレクトリにアクセスするユーザーにはtokenGroupsオプションの読込み権限が必要になり、tokenGroupsオプションはユーザー・オブジェクトのスキーマになければなりません)。

- 「SIDによるグループ・ルックアップのキャッシングの有効化」 - SIDによるグループ名のルックアップ結果がキャッシュされるかどうかを指定します。この設定は、「グループ・メンバーシップ・ルックアップでトークン・グループを使用する」オプションが有効になっている場合にのみ適用されます。

- 「キャッシュ内のSIDによるグループ・ルックアップ最大数」 - グループ・ルックアップにSIDを保持するための最長時間未使用(LRU)キャッシュの最大サイズです。この設定は、「グループ・メンバーシップ・ルックアップでトークン・グループを使用する」属性および「SIDによるグループ・ルックアップのキャッシングの有効化」属性の両方が有効になっている場合にのみ適用されます。

外部LDAPサーバーからの管理者ユーザーの構成: 例

この項では、外部LDAPサーバーから管理ユーザーを構成するプロセスを説明し、構成を検証する簡潔な方法を説明します。

この例では、Oracle Unified Directory認証プロバイダに、ユーザーorcladminが構成されます。目標は、orcladminが管理者としてWebLogic管理コンソールにログインできるようにWebLogic Serverを構成することです。

次のタスクを実行して、外部LDAPサーバーからユーザーorcladminを構成します:

1. LDAP認証プロバイダを作成および構成します。

1. LDAP認証プロバイダを構成する前に、ユーザー・ベースDNおよびグループ・ベースDNの詳細を入手する必要があります。LDAPサーバーからこれらの詳細を取得するには、サードパーティ・ブラウザ・ツールをダウンロードおよびインストールする必要があります。オープンソースのブラウザ・ツールJXplorerは、次の場所にあります。
http://jxplorer.org/downloads/users.html

この例では、JXplorer LDAPブラウザ・ツールを想定していますが、他のLDAPブラウザ・ツールでは細部が異なる場合があります。

2. LDAPブラウザ・ツールで、新しい接続を構成して、ホストおよびポートの詳細とLDAPサーバーのベースDNを入力します。

3. 「セキュリティ」セクションで、ドロップダウン・リストからユーザーとパスワードのレベルを選択し、ユーザー資格証明を入力します。別の方法として、権限があれば、匿名ユーザーとしてログインすることもできます。

4. 「OK」をクリックして接続を構成します。LDAPツリーは、左側のペインの「検索」タブに表示されるはずです。

5. ユーザーが作成される階層に移動し、ユーザーを右クリックして、そのDNをテキスト・ファイルにコピーします(たとえば、ou=people, o=example.com)。このDNは、LDAP認証プロバイダを構成するためのユーザー・ベースDNとして使用されます。
ユーザーが作成される階層に移動し、ユーザーを右クリックして、そのDNをテキスト・ファイルにコピーします(たとえば、ou=people, o=example.com)。このDNは、LDAP認証プロバイダを構成するためのユーザー・ベースDNとして使用されます。

6. LDAPホスト、ポート、プリンシパル資格証明と、ユーザーおよびグループ・ベースDNの詳細を使用して、WebLogic Server管理コンソールで新しいLDAP認証プロバイダを構成します。管理コンソールで、「セキュリティ・レルム」→「レルム名」→「プロバイダ」ページに移動し、「新規」をクリックして新しい「認証」プロバイダを追加します。

7. 認証プロバイダの名前を入力し、「タイプ」はOracleUnifiedDirectoryAuthenticatorを選択します。「OK」をクリックします。

8. 作成したOracle Unified Directory認証プロバイダの名前をクリックし、「構成」→「プロバイダ固有」ページを選択します。

9. ユーザーに関する必須の接続属性(ホスト、ポート、プリンシパル、資格証明など)を構成します。前の手順でサードパーティのLDAPブラウズ・ツールから入手したユーザー・ベースDNおよびグループ・ベースDNを入力します。

10. 「保存」をクリックします。レルムの自動再起動が有効になっている場合、変更をアクティブ化した後でドメインを再起動する必要はありません。

2. デフォルトのWebLogic認証プロバイダを構成します。

1. 「セキュリティ・レルム」→「RealmName」→「プロバイダ」→「DefaultAuthenticator」と移動します。

2. 「共通構成」ページで、「制御フラグ」を「SUFFICIENT」に設定します。

3. レルムの自動再起動が有効になっている場合、変更をアクティブ化した後でドメインを再起動する必要はありません。

3. グローバル・セキュリティ・ロールを作成および構成します。

1. LDAPユーザーやグループが正常に構成されたかどうかを検証します。「セキュリティ・レルム」→「RealmName」→「ユーザーとグループ」に移動し、作成したユーザーまたはグループの名前が表示されることを確認します。

2. 「ロールとポリシー」タブをクリックして、「グローバル・ロール」→「ロール」を展開します。「管理」ロール行で、「ロール条件の表示」リンクをクリックし、「条件の追加」をクリックします。

3. 「グローバル・ロールの編集」ページで、「述部リスト」ドロップダウン・メニューから「グループ」または「ユーザー」を選択し、「次」をクリックします。

4. 「ユーザー引数名」フィールドで、以前の手順で作成したLDAPユーザー/グループ名を入力して、「追加」→「終了」とクリックします。

5. 「保存」をクリックします。

注意:
グローバル・セキュリティ・ロールの作成と構成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグローバル・セキュリティ・ロールの作成に関する項を参照してください。

4. 構成を確認します。
WebLogic管理コンソールからログアウトし、作成したLDAPユーザー資格証明を使用して再ログインします。新しいLDAPユーザーとしてログインできるはずです。

RDBMS認証プロバイダの構成

WebLogic Serverでは、RDBMS認証プロバイダはユーザー名/パスワード・ベースの認証プロバイダであり、ユーザー、パスワード、およびグループ情報のデータ・ストアとして(LDAPディレクトリではなく)リレーショナル・データベースを使用します。WebLogic Serverには、以下のRDBMS認証プロバイダが用意されています。

- SQL認証プロバイダ: SQLデータベースを使用し、データベースへの読み書きアクセスを許可します。この認証プロバイダは、デフォルトによって一般的なSQLデータベース・スキーマを使用するように構成されていますが、使用するデータベースのスキーマに合わせて構成できます。「SQL認証プロバイダの構成」を参照してください。

- 読取り専用SQL認証プロバイダ: SQLデータベースを使用し、データベースへの読取り専用アクセスを許可します。書込みアクセスの場合、WebLogicセキュリティ・プロバイダではなくSQLデータベース独自のインタフェースを使用します。「読取り専用SQLオーセンティケータの構成」を参照してください。

- カスタムRDBMS認証プロバイダ: プラグイン・クラスを書き込む必要があります。このプロバイダは、認証データ・ストアとしてリレーショナル・データベースを使用するが、SQL認証プロバイダのスキーマ構成が既存のデータベース・スキーマとうまく一致しない場合に使用します。「カスタムDBMSオーセンティケータの構成」を参照してください。

RDBMS認証プロバイダのセキュリティ・レルムへの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。RDBMS認証プロバイダのインスタンスを作成したら、管理コンソールのRDBMS認証プロバイダの「構成」→「プロバイダ固有」ページでそのインスタンスを構成します。

一般的なRDBMS認証プロバイダ属性

3種類のRDBMS認証プロバイダのすべてに以下の構成オプションがあります。

データ・ソース属性

「データ・ソース名」では、データベースに接続するためのWebLogic Serverデータ・ソースを指定します。

グループ検索属性

「グループ・メンバーシップ検索」および「グループ・メンバーシップ検索の最大レベル」属性では、再帰的なグループ・メンバーシップ検索を制限付きか無制限のどちらにするか、および制限付きにした場合、検索するグループ・メンバーシップ・レベルの数を指定します。たとえば、「グループ・メンバーシップ検索」をlimitedに、「グループ・メンバーシップ検索の最大レベル」を0に設定した場合、RDBMS認証プロバイダはユーザーが直接メンバーであるグループだけを検索します。グループ・メンバーシップ検索の最大レベルを指定すると、認証中に実行されるDBMS問合せの数が減少する場合があるので、特定のシナリオで認証のパフォーマンスが大幅に向上します。しかし、グループ・メンバーシップ検索レベルを制限するのは、必要なグループ・メンバーシップがその検索レベル制限の範囲内にあることが確認できている場合のみにしてください。

注意:
RDBMSに循環グループが含まれる場合や、それ自身を含むように定義されているグループが含まれる場合、RDBMS認証プロバイダは認証プロセスを完了できないことがあります。「グループ・メンバーシップ検索」と「グループ・メンバーシップ検索の最大レベル」の属性を設定すると、グループ名の再帰ルックアップを制限できます。ただし、RDBMS認証プロバイダを循環グループで使用することはサポートされていないので、避ける必要があります。

グループ・キャッシング属性

グループ階層ルックアップの結果をキャッシュすることによって、RDBMS認証プロバイダのパフォーマンスを向上できます。このキャッシュを使用すると、RDBMS認証プロバイダがデータベースにアクセスする頻度を下げることができます。このキャッシュの使い方、サイズ、および期間を構成するには、認証プロバイダの「パフォーマンス」ページを使用します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・レルム: セキュリティ・プロバイダ: SQL認証: パフォーマンスに関する項を参照してください。

SQL認証プロバイダの構成

SQL認証プロバイダの構成の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「セキュリティ・レルム: セキュリティ・プロバイダ: SQLオーセンティケータ: プロバイダ固有」を参照してください。「一般的なRDBMS認証プロバイダ属性」で説明した属性の他にも、SQL認証プロバイダには次の構成可能な属性があります。

パスワード属性

以下の属性によって、RDBMS認証プロバイダとその基底データベースがパスワードを処理する方法を指定します。

- プレーン・テキスト・パスワードを有効化

- パスワードのスタイルを保持

- パスワードのスタイル

- パスワード・アルゴリズム

SQL文属性

SQL文属性では、プロバイダがデータベース内のユーザー名、パスワード、およびグループ情報にアクセスして編集するために使用するSQL文を指定します。SQL文属性のデフォルト値は、データベース・スキーマに次の表が含まれていることを前提としたものです。

- ユーザー(ユーザー名、パスワード、「説明」)

- グループ・メンバー(グループ名、グループ・メンバー)

- グループ(グループ名、グループの説明)

注意:
SQL文によって参照される表は、データベースに存在しなければなりません。プロバイダによって表は作成されません。これらの属性は、使用するデータベースのスキーマに合せて適宜変更できます。しかし、データベース・スキーマがこのデフォルト・スキーマと根本的に異なる場合、代わりにカスタムDBMS認証プロバイダを使用できます。

読取り専用SQLオーセンティケータの構成

読取り専用SQL認証プロバイダの構成の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「セキュリティ・レルム: セキュリティ・プロバイダ: 読取り専用SQLオーセンティケータ: プロバイダ固有」を参照してください。「一般的なRDBMS認証プロバイダ属性」で説明した属性の他にも、読取り専用SQL認証プロバイダの構成可能な属性には、データベースのユーザー名、パスワードおよびグループ情報をリストするためにプロバイダで使用するSQL文を指定する属性があります。これらの属性は、使用するデータベースのスキーマに合わせて変更できます。

カスタムDBMSオーセンティケータの構成

カスタムDBMS認証プロバイダは、他のRDBMS認証プロバイダと同様、ユーザー、パスワード、およびグループ情報のデータ・ストアとしてリレーショナル・データベースを使用します。このプロバイダは、使用するデータベース・スキーマがSQL認証プロバイダで必要なSQLスキーマと一致しない場合に使用します。「一般的なRDBMS認証プロバイダ属性」で説明した属性の他にも、カスタムDBMS認証プロバイダには以下の構成可能な属性があります。

プラグイン・クラス属性

カスタムDBMS認証プロバイダでは、weblogic.security.providers.authentication.CustomDBMSAuthenticatorPluginインタフェースを実装するプラグイン・クラスを作成する必要があります。このクラスはシステム・クラスパスに存在しなくてはならず、カスタムDBMS認証プロバイダの「プラグイン・クラス名」属性に指定する必要があります。必要な場合、「プラグインのプロパティ」属性を使用して、プラグイン・クラスによって定義されるプロパティ値を指定します。

Windows NT認証プロバイダの構成

Windows NT認証プロバイダは、Windows NTドメイン用に定義されたアカウント情報を使用してユーザーとグループを認証し、Windows NTのユーザーとグループをWebLogic Server管理コンソールに表示します。

Windows NT認証プロバイダを使用するには、管理コンソールでWindows NT認証プロバイダを作成します。ほとんどの場合、この認証プロバイダの構成では何も行う必要はありません。ただし、Windows NTドメインの構成によっては、Windows NT認証プロバイダとWindows NTドメインの対話方法を制御する属性である「ドメイン・コントローラ」および「ドメイン・コントローラ・リスト」を設定します。

注意:
Windows NT認証プロバイダは、WebLogic Server 10.0から非推奨になりました。かわりに、1つまたは複数のサポートされている別の認証プロバイダを使用してください。

ドメイン・コントローラの設定

Windows NTドメインのユーザー名には、いくつかの形式があります。サインオンするときに使用するユーザー名の形式に合わせて、Windows NT認証プロバイダを構成する必要があります。単純なユーザー名には、ドメイン名は入りません(smithなど)。複合ユーザー名は、ユーザー名とドメイン名の組合せです(domain\smithやsmith@domainなど)。

ローカル・マシンがMicrosoftドメインの一部でない場合、「ドメイン・コントローラ」および「ドメイン・コントローラ・リスト」属性の変更は必要ありません。スタンドアロン・マシンでは、認証を受けるユーザーとグループはそのマシンのみで定義されます。

ローカル・マシンがMicrosoftドメインの一部であり、ローカル・ドメインのドメイン・コントローラである場合、「ドメイン・コントローラ・リスト」属性の変更は必要ありません。この場合、ローカル・マシンとローカル・ドメインで定義されているユーザーは同じなので、「ドメイン・コントローラ」のデフォルトの設定を使用できます。

ローカル・マシンがMicrosoftドメインの一部であるが、ローカル・ドメインのドメイン・コントローラではない場合、単純ユーザー名はローカル・マシンまたはドメインのいずれかで発見されます。この場合は、以下のことを考慮します。

- ローカル・マシンがMicrosoftドメインの一部の場合に、そのユーザーとグループが管理コンソールに表示されないようにする必要がありますか?

- 単純ユーザー名が入力されたときにローカル・マシンのユーザーが検索および認証されるようにする必要がありますか?

いずれかの質問の答えが「はい」の場合、「ドメイン・コントローラ」属性をDOMAINに設定します。

信頼性のあるドメインが複数ある場合、「ドメイン・コントローラ」属性をLISTに設定し、「ドメイン・コントローラ・リスト」を指定する必要が生じる場合があります。これは、次の場合に行います:

- 他の信頼性のあるドメインのユーザーとグループを管理コンソールに表示する必要があるか、または

- ユーザーが単純なユーザー名を入力し、これらのユーザーが信頼性のあるドメインに配置される(つまり、ユーザーがsmith@domainやdomain\Smithではなくsmithのような単純なユーザー名でサインオンする)ことが予想されます。

このいずれかの場合、「ドメイン・コントローラ」属性をLISTに設定し、使用する信頼性のあるドメインの「ドメイン・コントローラ・リスト」属性にドメイン・コントローラの名前を指定します。また、ローカル・マシンとローカル・ドメイン・コントローラの明示的な名前を使用するかどうか、またはそれらのリストでプレースホルダーを使用するかどうかも検討します。「ドメイン・コントローラ・リスト」属性には以下のプレースホルダーを使用できます。

- [Local]

- [LocalAndDomain]

- [Domain]

LogonTypeの設定

Windows NT認証プロバイダのLogonType属性の適切な値は、認証できるようにするユーザーのWindows NTログオン権限によって異なります。

- WebLogic Serverが動作するマシン上でユーザーに割り当てられているログオン権限が「ローカルにログオン」の場合、デフォルト値のinteractiveを使用します。

- ユーザーに割り当てられている権限が「ネットワークからこのコンピュータにアクセスする」の場合、LogonType属性をnetworkに変更します。

Windows NTドメインのユーザーには、上記の権限のいずれかを割り当てる必要があります。このようにしない場合、Windows NT認証プロバイダはユーザーを認証できません。

UPN名の設定

UPN型のユーザー名の形式は、user@domainです。@記号を含むがUPN名ではないユーザー名をWindows NT認証プロバイダがどのように扱うかは、Windows NT認証プロバイダのmapUPNNames属性で設定します。

UPNユーザー名以外に、@記号を含むユーザー名がWindows NTドメインとローカル・マシンに存在しない場合、mapUPNNames属性のデフォルト値であるFIRSTを使用できます。しかし、この値をALWAYSに変更することによって、認証の失敗の検出時間を短縮できる場合があります。これは特に、長いドメイン・コントローラ・リストを指定した場合に効果的です。

Windows NTドメインで、@記号を含むUPN以外のユーザー名が存在する場合、次のように設定します。

- @記号を含むユーザー名が単純ユーザー名ではなくUPNユーザー名である可能性が高い場合、mapUPNNames属性をFIRSTに設定します。

- @記号を含むユーザー名がUPNユーザー名ではなく単純ユーザー名である可能性が高い場合、mapUPNNames属性をLASTに設定します。

- ユーザー名がUPN形式ではない場合、mapUPNNames属性をNEVERに設定します。

SAML認証プロバイダの構成

SAML認証プロバイダは、SAML 1.1またはSAML 2.0のIDアサーション・プロバイダと組み合せることで、以下の用途に使用できます。

- 仮想ユーザーがSAMLでログインできるようにします。
条件が満たされると、SAML IDアサーション・プロバイダによってユーザーまたはグループのプリンシパルが作成され、仮想ユーザー(ローカルに実在するどのユーザーにも対応しないユーザー)としてログインすることが可能になります。

- SAML認証プロバイダを他の認証プロバイダよりも前に実行されるように構成し、JAAS制御フラグをSUFFICIENTに設定することで、SAML認証プロバイダによって認証済みのサブジェクトが作成されるようにします。作成時には、SAML IDアサーション・プロバイダV2またはSAML 2.0 IDアサーション・プロバイダによるSAMLアサーションから取得したユーザー名とグループが使用されます。

SAML認証プロバイダが構成されていないか、SAML認証プロバイダより前に別の認証プロバイダ(たとえばデフォルトのLDAP認証プロバイダ)が構成されており、そのJAAS制御フラグがSUFFICIENTに設定されている場合は、その別の認証プロバイダがSAML IDアサーション・プロバイダから返されるユーザー名を検証します。デフォルトのLDAP認証プロバイダの場合は、ユーザーがIDディレクトリ内に存在していないと認証が失敗します。

グループをSAMLアサーションから取得する必要がある場合は、ユーザーの存在をLDAP認証プロバイダで検証する場合であっても、SAML認証プロバイダを構成する必要があります。そうしないと、アサーション内のグループではなく、LDAPディレクトリから派生したグループにユーザーが関連付けられます。

SAML認証プロバイダは、SAML IDアサーション・プロバイダV2またはSAML 2.0 IDアサーション・プロバイダによってアサートされたIDを持つユーザーのサブジェクトのみを作成します。それ以外の認証リクエストやIDアサーション・リクエストはすべて無視されます。

パスワード検証プロバイダの構成

WebLogic Serverには、各セキュリティ・レルムでデフォルトで構成されるパスワード検証プロバイダがあります。この検証プロバイダは、構成可能なパスワード構成ルールを管理および適用でき、そのレルム内のユーザーのパスワードが作成または更新されると、サポートされている認証プロバイダによって自動的に呼び出されます。呼び出されると、「パスワード検証」プロバイダは、当該パスワードが構成ルールに基づく条件を満たすかどうかを判定するためのチェックを実行します。その後、パスワードは適切に受け入れられるか拒否されます。

パスワード検証プロバイダと併用できる認証プロバイダは以下のとおりです。

- WebLogic認証プロバイダ

- SQL認証プロバイダ

- LDAP認証プロバイダ

- Oracle Internet Directory認証プロバイダ

- Oracle Virtual Directory認証プロバイダ

- Active Directory認証プロバイダ

- iPlanet認証プロバイダ

- Novell認証プロバイダ

- Open LDAP認証プロバイダ

次の項では、構成可能な構成ルールと、セキュリティ・レルムでパスワード検証プロバイダのインスタンスを作成および構成する方法について説明します。

- パスワード検証プロバイダのパスワード構成ルール

- パスワード検証プロバイダとWebLogic認証プロバイダの併用

- LDAP認証プロバイダでのパスワード検証プロバイダの使用

- WLSTを使用したパスワード検証プロバイダの作成と構成

WebLogic Server管理コンソールでのパスワード検証プロバイダの構成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのパスワード検証プロバイダの構成に関する項を参照してください。

パスワード検証プロバイダのパスワード構成ルール

デフォルトでは、パスワード検証プロバイダは、8文字以上のパスワードを必要とするように構成されています。前述の項でリストされたサポート対象のLDAP認証プロバイダのいずれかと併用するとき、パスワード検証プロバイダは、表5-9でリストされている追加基準を満たすパスワードも必要とします。

表5-9 LDAP認証プロバイダとの併用時にパスワード検証プロバイダに要求される追加パスワード作成ルール

LDAP認証プロバイダ

追加パスワード作成要件

- Oracle Internet Directory認証プロバイダ

- Oracle Virtual Directory認証プロバイダ

パスワード内の文字のうち、1文字以上は数字にする必要があります。

- WebLogic認証プロバイダ

- LDAP認証プロバイダ

- Active Directory認証プロバイダ

- iPlanet認証プロバイダ

- Novell認証プロバイダ

- Open LDAP認証プロバイダ

パスワード内の文字のうち、1文字以上はアルファベット以外の文字にする必要があります。たとえば、数字、アスタリスク(*)、またはシャープ記号(#)など。

パスワード検証プロバイダでは、次のようなパスワード構成ルールをオプションで構成できます。

- ユーザー名のポリシー - ユーザー名で構成されるパスワードやユーザー名を含むパスワード、あるいはユーザー名を逆にしたパスワードかどうかを判断するルール

- パスワード文字長のポリシー — パスワードの最小文字数または最大文字数(構成ルールで最小長と最大長の両方を指定可能)のルール

- 文字のポリシー - パスワードに次の文字が含まれているかどうかを判断するポリシー

- 数字

- 小文字のアルファベット

- 大文字のアルファベット

- アルファベット以外の文字

パスワード検証プロバイダに構成可能な特定の構成ルールの詳細(本番環境にお薦めするルールの設定を含む)は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「システム・パスワード検証プロバイダ: プロバイダ固有」を参照してください。

警告:
パスワード構成ルールの設定は、総当たりのパスワード攻撃からWebLogic Serverを保護する手段の1つに過ぎません。ユーザー・アカウントを保護するためには、ユーザー・ロックアウトも構成する必要があります。ユーザー・ロックアウトでは、特定の時間内に間違ったパスワードを入力した回数が上限値を超えると、そのユーザーのアカウントがロックアウトされます。詳細は、「ユーザー・アカウントの保護」を参照してください。

パスワード検証プロバイダとWebLogic認証プロバイダの併用

デフォルトでは、WebLogic認証プロバイダには8文字以上のパスワード(少なくとも1つはアルファベット以外)が必要になります。しかし、この最小パスワード文字数はカスタマイズできます。WebLogic認証プロバイダとパスワード検証プロバイダが同じセキュリティ・レルム内に構成されている場合は、WebLogic認証プロバイダの最小パスワード文字数に満たないパスワードを作成しようとするとエラーが生成されます。たとえば、管理コンソールに次のようなメッセージが表示されます。

Error [Security:090285]password must be at least 8 characters long
Error Errors must be corrected before proceeding.

最小パスワード文字数が満たされなかったためにWebLogic認証プロバイダによってパスワードが拒否された場合、パスワード検証プロバイダは呼び出されません。パスワード検証プロバイダとWebLogic認証プロバイダが常に併用されるようにするには、必ず両方のプロバイダに同じ最小パスワード文字数を設定する必要があります。

WebLogic認証プロバイダの最小パスワード文字数は、管理コンソールを使用して次の手順で設定できます。

1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 左ペインで「セキュリティ・レルム」を選択し、構成するレルムの名前(たとえばmyrealm)をクリックしします。

3. 「プロバイダ」>「認証」を選択し、「DefaultAuthenticator」をクリックします。

4. 「構成」>「プロバイダ固有」を選択し、「最小パスワード文字数」フィールドに値を入力します。

5. 「保存」をクリックして変更を保存します。

6. チェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

パスワード検証プロバイダで最小パスワード文字数を設定する方法については、「WLSTを使用したパスワード検証プロバイダの作成と構成」を参照してください。

LDAP認証プロバイダでのパスワード検証プロバイダの使用

パスワード検証プロバイダとLDAP認証プロバイダ(Oracle Internet Directory認証プロバイダなど)がセキュリティ・レルムで構成される場合、パスワードは2つの個別ポリシー・チェックで検証されます。1つは、パスワード検証プロバイダのチェック、もう1つはLDAPサーバーのチェックで、それぞれに独自のパスワード・ポリシー・チェックがあります。たとえば、Oracle Internet Directoryには独自のパスワード検証メカニズムがあり、これは、LDAPサーバー管理者によって制御されます。この2つのパスワード検証メカニズムは個別のもので、それぞれに独自のパスワード構成ルールがあります。構成ルールが一貫していないと、パスワード検証プロバイダのルールが実行される場合でも、パスワードを作成またはリセットしようとするときにWebLogic Server管理コンソールで障害が発生することがあります。したがって、パスワード検証プロバイダのパスワード構成ルールがLDAPサーバーのルールと競合しないようにしてください。

WLSTを使用したパスワード検証プロバイダの作成と構成

セキュリティ・レルム内でパスワード検証プロバイダを管理するには、WLSTスクリプトを使用できます。このスクリプトは、Oracle WebLogic Server MBeanリファレンスで説明するように、SystemPasswordValidatorMBeanに対する操作を実行します。パスワード検証プロバイダは、1つのWLSTスクリプトで作成および構成できますが、これを複数のスクリプトに分けて別々に実行することも可能です。次のトピックでは、WLSTのサンプル・コードに基づいてこれらの方法を説明します。

- パスワード検証プロバイダのインスタンスの作成

- パスワード構成ルールの指定

パスワード検証プロバイダのインスタンスの作成

パスワード検証プロバイダは、新しいドメインを作成するとセキュリティ・レルムに自動的に作成されます。ただし、例5-1に示すように、WLSTを使用して作成することもできます。このコードによって、次の操作が実行されます。

1. 現在のレルムとパスワード検証プロバイダを取得します。

2. パスワード検証プロバイダのインスタンス(名前はSystemPasswordValidator)がすでに作成されているかどうかを識別します。

- プロバイダがすでに作成されている場合は、それが存在することを示すメッセージを表示します。

- プロバイダがまだ作成されていない場合は、セキュリティ・レルム内にプロバイダを作成し、それが作成されたことを示すメッセージを表示します。

例5-1 システム・パスワード検証プロバイダの作成

edit()
startEdit()

realm = cmo.getSecurityConfiguration().getDefaultRealm()
pwdvalidator = realm.lookupPasswordValidator('SystemPasswordValidator')

if pwdvalidator:
print 'Password Validator provider is already created'

else:
# Create SystemPasswordValidator
syspwdValidator = realm.createPasswordValidator('SystemPasswordValidator',
'com.bea.security.providers.authentication.passwordvalidator.SystemPasswordValidator')
print "---  Creation of System Password Validator succeeded!"

save()
activate()

パスワード構成ルールの指定

例5-2に、パスワード検証プロバイダの構成ルールを設定するWLSTコード例を示します。このスクリプトによって設定されるルール属性の詳細は、Oracle WebLogic Server MBeanリファレンスのSystemPasswordValidatorMBeanに関する説明を参照してください。

例5-2 パスワード構成ルールの構成

edit()
startEdit()

# Configure SystemPasswordValidator
try:
pwdvalidator.setMinPasswordLength(8)
pwdvalidator.setMaxPasswordLength(12)
pwdvalidator.setMaxConsecutiveCharacters(3)
pwdvalidator.setMaxInstancesOfAnyCharacter(4)
pwdvalidator.setMinAlphabeticCharacters(1)
pwdvalidator.setMinNumericCharacters(1)
pwdvalidator.setMinLowercaseCharacters(1)
pwdvalidator.setMinUppercaseCharacters(1)
pwdvalidator.setMinNonAlphanumericCharacters(1)
pwdvalidator.setMinNumericOrSpecialCharacters(1)
pwdvalidator.setRejectEqualOrContainUsername(true)
pwdvalidator.setRejectEqualOrContainReverseUsername(true)
print " --- Configuration of SystemPasswordValidator complete  ---"
except Exception,e:
print e

save()
activate()

IDアサーション・プロバイダの構成

境界認証を使用する場合、IDアサーション・プロバイダを使用する必要があります。境界認証では、WebLogic Serverの外部にあるシステムがトークンを通じて信頼を確立します(これは単純認証とは対照的です。単純認証では、WebLogic Serverがユーザー名とパスワードを通じて信頼を確立します)。IDアサーション・プロバイダは、トークンを検証し、そのトークンの妥当性と信頼性を確立するために必要なアクションを実行します。各IDアサーション・プロバイダは、1つまたは複数のトークン・フォーマットをサポートします。

WebLogic Serverには、以下の新しいIDアサーション・プロバイダが組み込まれています。

- WebLogic IDアサーション・プロバイダ

- LDAP X509 IDアサーション・プロバイダ

- ネゴシエーションIDアサーション・プロバイダ

- SAML IDアサーション・プロバイダ(SAML 1.1用)

- SAML 2.0 IDアサーション・プロバイダ

セキュリティ・レルムでは複数のIDアサーション・プロバイダを構成できますが、必須ではありません。IDアサーション・プロバイダでは複数のトークン・タイプをサポートできますが、一度にアクティブになるのはIDアサーション・プロバイダごとに1つのトークン・タイプだけです。管理コンソールの「プロバイダ固有」構成ページの「アクティブな種類」フィールドで、アクティブなトークン・タイプを定義します。WebLogic IDアサーション・プロバイダは、X509証明書とCORBA Common Secure Interoperabilityバージョン2 (CSI v2)を使用するIDアサーションをサポートしています。CSI v2 IDアサーションを使用する場合、「信頼性のあるクライアントのプリンシパル」フィールドでクライアント・プリンシパルのリストを定義します。

セキュリティ・レルムに複数のIDアサーション・プロバイダを構成した場合、すべてのIDアサーション・プロバイダで同じトークン・タイプをサポートできます。ただし、トークンは一度に1つのプロバイダのみに対してアクティブにできます。

WebLogic IDアサーション・プロバイダでは、ユーザー名マッパーを使用して、IDアサーション・プロバイダで認証されるトークンをセキュリティ・レルム内のユーザーにマップすることもできます。ユーザー名マッパーの構成の詳細は、「WebLogic資格証明マッピング・プロバイダの構成」を参照してください。

Webアプリケーションの認証タイプがCLIENT-CERTに設定されている場合、WebLogic ServerのWebアプリケーション・コンテナは、リクエスト・ヘッダーおよびCookieからの値に対してIDアサーションを実行します。ヘッダー名またはCookie名が、構成されているIDアサーション・プロバイダのアクティブなトークン・タイプに一致していれば、値はプロバイダに渡されます。

「プロバイダ固有」ページの「Base64でのデコーディングが必要」の値は、リクエスト・ヘッダー値またはCookie値をIDアサーション・プロバイダへ送信する前に、Base64でデコードする必要があるかどうかを決定します。この設定はデフォルトでは後方互換性のために有効になっていますが、ほとんどのIDアサーション・プロバイダでは、このオプションは無効化されます。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。また、次の項を参照してください。

- LDAP X509 IDアサーション・プロバイダの仕組み

- LDAP X509 IDアサーション・プロバイダの構成: 主な手順

- ネゴシエーションIDアサーション・プロバイダの構成

- SAML 1.1用のSAML IDアサーション・プロバイダの構成

- SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成

- サーブレットに対するIDアサーションの順序付け

- サーバー・キャッシュのIDアサーション・パフォーマンスの構成

- ユーザー名マッパーの構成

- カスタム・ユーザー名マッパーの構成

LDAP X509 IDアサーション・プロバイダの仕組み

LDAP X509 IDアサーション・プロバイダは、X509証明書を受け取り、その証明書に関連付けられたユーザーのLDAPオブジェクトをルックアップして、LDAPオブジェクトの証明書が提示された証明書と一致することを確認し、LDAPオブジェクトからユーザーの名前を取得します。

LDAP X509 IDアサーション・プロバイダは、以下のように機能します。

1. 境界認証(つまり、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する)を使用するようにアプリケーションがセット・アップされます。

2. SSLハンドシェーク機能の一部として、アプリケーションは証明書を提示します。証明書のサブジェクトDNを使用して、LDAPサーバー内のそのユーザーを表すオブジェクトを特定できます。オブジェクトには、ユーザーの証明書と名前が含まれています。

3. LDAP X509 IDアサーション・プロバイダは、サブジェクトDNの証明書を使用して、LDAP検索を構築し、LDAPサーバー内のユーザーのLDAPオブジェクトを見つけます。そのオブジェクトから証明書を取得し、それが自らの保持する証明書と一致していることを確認し、ユーザーの名前を取得します。

4. ユーザー名は、セキュリティ・レルムで構成されている認証プロバイダに渡されます。認証プロバイダは、ユーザーが存在していることを確認し、そのユーザーが属するグループを特定します。

LDAP X509 IDアサーション・プロバイダの構成: 主な手順

通常、LDAP X509 IDアサーション・プロバイダを使用する場合は、LDAPサーバーを使用するLDAP認証プロバイダも構成する必要があります。認証プロバイダは、ユーザーが存在していることを確認し、そのユーザーが属するグループを特定します。両方のプロバイダが、同じLDAPサーバーと通信できるように適切に構成されていることを確認してください。

LDAP X509 IDアサーション・プロバイダを使用するには:

1. ユーザーの証明書を取得し、それらをLDAPサーバーに置きます。第11章「IDと信頼の構成」を参照してください。
証明書のサブジェクトDNと、LDAPサーバー内におけるそのユーザーのオブジェクトの場所の間には、相関性が必要です。ユーザーのLDAPオブジェクトには、サブジェクトで使用される証明書およびユーザー名の構成情報も含まれている必要があります。

2. セキュリティ・レルムで、LDAP X509 IDアサーション・プロバイダを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。

3. WebLogic Server管理コンソールで、証明書のサブジェクトDNに指定されたLDAPディレクトリ内でユーザーのLDAPオブジェクトを見つけるようにLDAP X509 IDアサーション・プロバイダを構成します。

4. LDAPサーバーを検索して、ユーザーのLDAPオブジェクトを特定するようにLDAP X509 IDアサーション・プロバイダを構成します。これには、以下のデータが必要になります。

- 検索を開始するベースLDAP DN。LDAP X509 IDアサーション・プロバイダの「証明書マッピング」オプションは、そのIDアサーション・プロバイダが証明書のサブジェクトDNからベースLDAP DNを構築する方法を示します。LDAPオブジェクトには、証明書を保持する属性が含まれている必要があります。

- 定義されたオプションのセットに一致するLDAPオブジェクトのみを返す検索フィルタ。フィルタによってLDAP検索が制限されます。証明書のサブジェクトDNから検索フィルタを構築するように、ユーザー・フィルタ検索を構成します。

- ベースLDAP DNを検索するLDAPディレクトリ内の場所。LDAP X509 IDアサーション・プロバイダは、再帰的に検索します(1レベル下)。この値は、証明書のサブジェクトDN内の値と一致する必要があります。

5. LDAP X509 IDアサーション・プロバイダの「証明書属性」属性を構成して、ユーザーのLDAPオブジェクトがどのように証明書を保持するかを指定します。LDAPオブジェクトには、証明書を保持する属性が含まれている必要があります。

6. LDAP X509 IDアサーション・プロバイダの「ユーザー名属性」属性を構成して、サブジェクトDNに表示されるユーザー名を保持するLDAPオブジェクトの属性を指定します。

7. LDAP X509 IDアサーション・プロバイダのLDAPサーバー接続を構成します。LDAPサーバーの情報は、このセキュリティ・レルムで構成されているLDAP認証プロバイダに対して定義されている情報と同じでなければなりません。

8. LDAP X509 IDアサーション・プロバイダと共に使用するLDAP認証プロバイダを構成します。LDAPサーバーの情報は、ステップ7で構成されたLDAP X509 IDアサーション・プロバイダに対して定義されている情報と同じにします。「LDAP認証プロバイダの構成」を参照してください。

ネゴシエーションIDアサーション・プロバイダの構成

ネゴシエーションIDアサーション・プロバイダを使用すると、Microsoft社製のクライアントでシングル・サインオン(SSO)を利用できます。このIDアサーション・プロバイダでは、Simple and Protected Negotiate (SPNEGO)のトークンをデコードしてKerberosのトークンを取得し、そのKerberosトークンを検証した後でWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。

ネゴシエーションIDアサーション・プロバイダは、WebLogicセキュリティ・フレームワークに定義されているようにセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の実装であり、クライアントをそのSPNEGOトークンに基づいて認証するのに必要なロジックを提供します。

ネゴシエーションIDアサーション・プロバイダのセキュリティ・レルムへの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。ネゴシエーションIDアサーション・プロバイダをMicrosoftクライアントSSOと一緒に使用する方法については、第6章「Microsoftのクライアントに対するシングル・サインオンの構成」を参照してください。

表5-10 ネゴシエーションIDアサーション・プロバイダの属性

属性

説明

フォームベースのネゴシエーションを有効化

WebアプリケーションがFORM認証を行うように構成されている場合にネゴシエーションIDアサーション・プロバイダとサーブレット・フィルタでネゴシエーションを行うかどうかを指定します。

アクティブな種類

このネゴシエーションIDアサーション・プロバイダが認証に使用するトークン・タイプ。使用可能なトークン・タイプは、Authorization.NegotiateとWWW-Authenticate.Negotiateです。

同じセキュリティ・レルム内に構成されている他のIDアサーション・プロバイダでこの属性がX509に設定されていないことを確認してください。

SAML 1.1用のSAML IDアサーション・プロバイダの構成

SAML IDアサーション・プロバイダは、SAML 1.1セキュリティ・アサーションのコンシューマとして機能します。WebLogic Serverは、このプロバイダを使用することで、シングル・サインオンにSAML 1.1を使用するための宛先サイトとして機能します。SAML IDアサーション・プロバイダは、署名をチェックし、保持する証明書レジストリ内の証明書の信頼性を検証することによって、SAML 1.1アサーションを検証します。信頼されていれば、アサーションに含まれるAuthenticationStatementに基づいてIDがアサートされます。また、SAML IDアサーション・プロバイダは、アサーションが以前に使用されていないことを確認します。SAMLアサーション・コンシューマ・サービスをサーバー・インスタンスにデプロイする場合は、SAML IDアサーション・プロバイダが構成されていなければなりません。

このリリースのWebLogic Serverには、SAML 1.1用のSAML IDアサーション・プロバイダが2つ含まれています。SAML IDアサーション・プロバイダ・バージョン2では構成オプションが大幅に拡張されていますので、新たなデプロイメントではこのバージョンを使用することをお薦めします。SAML IDアサーション・プロバイダ・バージョン1はWebLogic Server 9.1で非推奨になりました。セキュリティ・レルムには複数のSAML IDアサーション・プロバイダを含むことはできません。また、セキュリティ・レルムにSAML IDアサーション・プロバイダとSAML資格証明マッピング・プロバイダの両方が含まれる場合は、両方のバージョンが同じでなければなりません。バージョン2のSAMLプロバイダと同じセキュリティ・レルム内でバージョン1のSAMLプロバイダを使用しないでください。SAML IDアサーション・プロバイダ・バージョン1の構成については、WebLogic Server 9.0ドキュメントの『WebLogic Serverの保護』のSAML IDアサーション・プロバイダの構成に関する項を参照してください。

SAML IDアサーション・プロバイダをSAMLシングル・サインオン構成で使用する方法については、第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。WebLogic ServerでのSAMLのサポートの概要については、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項を参照してください。

アサーティング・パーティ・レジストリ

WebLogic ServerをSAMLセキュリティ・アサーションのコンシューマとして機能するように構成する場合には、SAMLアサーションが受け付けられるパーティを登録する必要があります。各SAMLアサーティング・パーティに対して、使用するSAMLプロファイル、そのアサーティング・パーティの詳細、そのアサーティング・パーティで受信されるアサーションで予想される属性を指定できます。詳細は、以下を参照してください。

- アサーティング・パーティの構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1アサーティング・パーティの構成に関する項。

証明書レジストリ

SAML IDアサーション・プロバイダは、信頼性のある証明書のレジストリを保持します。証明書を受け取ると、このレジストリ内の証明書と照らし合わせて検証します。各アサーティング・パーティでは、そのパートナから受け取る以下の証明書がこのレジストリに格納されます。

- このアサーティング・パーティから受け取ったアサーションの署名を検証するために使用する証明書。

- このアサーティング・パーティからのSAMLプロトコル要素の署名を検証するために使用する証明書。この証明書は、ブラウザ/POSTプロファイル用に設定する必要があります。

- アサーティング・パーティの信頼性を検証するために使用するTLS/SSL証明書。そのパートナが、SSL接続を使用してアサーション検索サービス(ARS)からアーティファクトを取得する際に使用します。

管理コンソールを使用して、信頼性のある証明書を証明書レジストリに追加できます。

1. 管理コンソールで、「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」ページに移動します。

2. SAML IDアサーション・プロバイダの名前をクリックし、「管理」>「証明書」ページを開きます。

「管理」>「証明書」ページで、レジストリの証明書を追加、削除、および表示します。

SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成

SAML 2.0 IDアサーション・プロバイダは、SAML 2.0セキュリティ・アサーションのコンシューマとして機能します。WebLogic Serverは、このプロバイダを使用することで、以下を実現するためのサービス・プロバイダとして機能します。

- Webシングル・サインオン。

- WebLogic Webサービス・セキュリティ。適切なWS-SecurityPolicyアサーションを使用して、IDのSAMLトークンを受け付けます。

SAML 2.0 IDアサーション・プロバイダは、以下の役割を果たします。

- 署名をチェックし、パートナ用に構成されたデータに基づいて信頼性を検証することによって、SAML 2.0アサーションを検証します。次に、SAML 2.0 IDアサーション・プロバイダはアサーションに含まれているID情報を抽出し、それをセキュリティ・レルム内のローカル・サブジェクトにマップします。

- 必要に応じて、アサーションに含まれている属性情報を抽出します。SAML認証プロバイダがセキュリティ・レルム内に構成されている場合は、この属性情報を使用して、マップしたサブジェクトが属すローカル・グループを特定することも可能です。(詳細は、「SAML認証プロバイダの構成」を参照してください。)

- 必要に応じて、アサーションに指定された有効期間や再利用の設定が有効かどうかを検証し、期限が切れている場合や再利用が不可能な場合はアサーションを拒否します。

SAML 2.0 IDアサーション・プロバイダの構成は、SAML2IdentityAsserterMBeanの属性を設定することで制御できます。SAML2IdentityAsserterMBeanにアクセスするには、WebLogic Scripting Tool (WLST)を使用するか、管理コンソールの「セキュリティ・レルム」>「レルム名」>「プロバイダ」>「認証」ページを使用して、SAML2IdentityAsserterを作成または選択します。これらの属性の詳細は、Oracle WebLogic Server MBeanリファレンスのSAML2IdentityAsserterMBeanに関する項を参照してください。

SAML 2.0 IDアサーション・プロバイダをSAMLシングル・サインオン構成で使用する方法については、第7章「WebブラウザとHTTPクライアントによるシングル・サインオンの構成」を参照してください。WebLogic ServerでのSAMLのサポートの概要については、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項を参照してください。Webサービス・セキュリティでのSAML 2.0 IDアサーション・プロバイダの使用については、『Oracle WebLogic Server WebLogic Webサービスの保護』のSecurity Assertion Markup Language (SAML)トークンのIDとしての使用に関する項を参照してください。

IDプロバイダ・パートナ

WebLogic Serverをサービス・プロバイダとして機能するように構成する場合は、SAML 2.0アサーションの送信と検証を行うIDプロバイダ・パートナを作成して構成します。IDプロバイダ・パートナを構成するには、パートナに関する以下のような基本情報を指定する必要があります。

- パートナ名と一般的な説明

- このパートナで使用する名前マッパー・クラス

- このパートナから受け取るアサーションに含まれている属性文を消費するかどうか

- このパートナから受け取るアサーションに含まれているIDを仮想ユーザーにマップするかどうか

- このパートナから受け取った署名付きアサーションを検証するために使用する証明書

ここで指定する情報は、パートナをWebシングル・サインオン用に構成するかWebサービス用に構成するかによって変わってきます。Webシングル・サインオンIDプロバイダ・パートナの場合も、パートナのメタデータ・ファイルをインポートし、そのパートナに関する以下のような基本情報を追加で指定する必要があります。

- リダイレクトURI。未認証のユーザーによって呼び出された場合に、そのIDプロバイダ・パートナで認証するためにユーザー・リクエストをリダイレクトするURLです。

- このパートナから受け取るSAMLアーティファクト・リクエストに署名が必要かどうか。

- このパートナにSAMLアーティファクトを配信する方法。

Webシングル・サインオンIDプロバイダ・パートナの構成については、以下を参照してください。

- Webシングル・サインオンIDプロバイダ・パートナの作成と構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオンIDプロバイダ・パートナの作成に関する項

WebサービスIDプロバイダ・パートナの構成ではメタデータ・ファイルは使用しませんが、そのパートナに関する以下の情報を指定する必要があります。

- 発行者URI。SAMLフェデレーション内で、このIDプロバイダ・パートナを一意に識別するための文字列です。

- オーディエンスURI。このパートナから受け取るアサーションに含めるオーディエンス制約を指定します。
WebLogic Serverでは、Webサービス・ランタイムがパートナの検索に使用するパートナ検索文字列を保持する必要もあるため、オーディエンスURI属性がオーバーロードされています。「Webサービス・パートナに必要なパートナ検索文字列」を参照してください。

- デフォルトの名前マッパーをオーバーライドするカスタム名前マッパー・クラス。このマッパー・クラスは、このパートナでのみ使用します。

Webサービス用のサービス・プロバイダ・パートナの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 WebサービスIDプロバイダ・パートナの作成に関する項を参照してください。

Webサービス・パートナに必要なパートナ・ルックアップ文字列

WebサービスIDプロバイダ・パートナの場合は、オーディエンスURIも構成します。WebLogic Serverでは、以下のまったく異なる2つの用途に使用できるよう、オーディエンスURI属性がオーバーロードされています。

- OASIS SAML 2.0仕様に従って、ターゲットURLからなるオーディエンス制約を指定します。

- パートナ・ルックアップ文字列を保持します。WebLogic Serverでは、実行時にこのルックアップ文字列を使用して、SAML 2.0アサーションの検証に使用するIDプロバイダ・パートナを見つけます。

パートナ・ルックアップ文字列には、パートナ・ルックアップに使用するエンドポイントURLを指定します。必要に応じて、このIDプロバイダ・パートナから受け取るアサーションに含める必要のあるオーディエンスURI制約として使用することもできます。

注意:
パートナ・ルックアップ文字列は、Webサービス・ランタイムが実行時にIDプロバイダ・パートナを見つけられるように構成する必要があります。

ルックアップ文字列の構文

パートナ・ルックアップ文字列の構文は次のとおりです。

[target:char:]<endpoint-url>

この構文で、target:char:はパートナ検索文字列を指定する接頭辞、charはハイフン(-)、プラス記号(+)、またはアスタリスク(*)のいずれか1つの特殊文字を表します。表5-11に示すように、この接頭辞によってパートナ・ルックアップの実行方法が決まります。

注意:
サービス・プロバイダとして機能するように構成されたWebLogic Serverインスタンスでは常に、SAML 2.0 IDアサーション・プロバイダに渡すエンドポイントURLからtransport、host、portの部分が除去されます。したがって、IDプロバイダ・パートナ用のルックアップ文字列として指定するすべてのエンドポイントURLには、hostとportより後ろの部分のみを含める必要があります。たとえば、target:*:/myserver/xxxのようにします。
これにより、サービス・プロバイダ・サイトを構成する際に、あるWebサービスをホストするドメイン内の複数のマシンで使用するトランスポート・プロトコル(たとえばHTTPかHTTPSか)、ホスト名、IPアドレス、ポート情報が違っていても、そのWebサービスのすべてのアサーションを単一のIDプロバイダ・パートナで検証することが可能になります。

表5-11 IDプロバイダ・パートナ・ルックアップ文字列の構文

ルックアップ文字列

説明

target:-:<endpoint-url>

URL <endpoint-url>に完全に一致するパートナを検索します。たとえば、target:-:/myserver/myservicecontext/my-endpointの場合は、アサーションの検証に使用するIDプロバイダ・パートナに一致する可能性のあるエンドポイントを直接指定しています。

この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、このIDプロバイダ・パートナのオーディエンスURIとしては追加されません。

target:+:<endpoint-url>

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

注意: プラス記号(+)をルックアップ文字列で使用すると、このIDプロバイダ・パートナから受け取るアサーション内のオーディエンスURIとして、エンドポイントURLが追加されます。この形式のルックアップ文字列では、IDプロバイダ・パートナが検出されにくいため、検出されない状況を回避する必要があります。

target:*:<endpoint-url>

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

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

この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、このIDプロバイダ・パートナのオーディエンスURIとしては追加されません。

注意:
実行時にIDプロバイダ・パートナが見つかるようにするため、1つのパートナに1つ以上のパートナ・ルックアップ文字列を構成する必要があります。パートナが見つからない場合、そのパートナのアサーションは検証できません。
target検索接頭辞を使用せずにエンドポイントURLを構成すると、従来のオーディエンスURIとして扱われるため、IDプロバイダ・パートナから受け取るアサーションに必ずオーディエンスURIを含める必要があります(これにより、このパートナに構成されている既存のオーディエンスURIとの後方互換性も確保できます。)

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

デフォルトのIDプロバイダ・パートナ・エントリを指定したい場合は、1つまたは複数のデフォルト・パートナのオーディエンスURIエントリに、すべてのターゲットに有効なワイルドカード一致を含めることができます。たとえば、target:*:/のようにします。

パートナ証明書の管理

SAML 2.0 IDアサーション・プロバイダは、構成されているパートナの信頼性のある証明書を管理します。パートナ・メッセージの交換中に受け取った証明書は、そのパートナ用に保持している証明書と照合されます。パートナの証明書は、以下の用途に使用します。

- サービス・プロバイダ・サイトで署名付きアサーションまたはSAMLアーティファクト・リクエストを受け取ったときに信頼性を検証するため

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

構成されている各IDプロバイダ・パートナから取得する証明書としては、以下が必要になります。

- パートナから受け取った署名付きSAMLドキュメント(アサーション、アーティファクト・リクエストなど)を検証するための証明書
Webシングル・サインオンで署名付きSAMLドキュメントを検証するために使用する証明書は、IDプロバイダ・パートナから受け取るメタデータ・ファイルに含まれています。WebサービスIDプロバイダ・パートナを構成する場合は、この証明書をパートナから取得し、このパートナの構成にインポートします。この操作は、管理コンソールのパートナ管理ページにある「アサーション署名用証明書エリアス」タブで行います。

- SAMLアーティファクトを取得するために、ローカル・サイトのSSLバインディングに対してパートナが確立した接続を検証するためのトランスポート層セキュリティ(TLS)クライアント証明書(Webシングル・サインオンでのみ使用)
Webシングル・サインオンIDプロバイダ・パートナを構成する場合は、TLSクライアント証明書をパートナから直接取得する必要があります。この証明書は、自動的にメタデータ・ファイルに含まれるものではありません。この証明書をパートナの構成データにインポートするには、管理コンソールのパートナ管理ページにある「トランスポート層クライアント証明書」タブを使用します。

IDプロバイダ・パートナの属性を構成するためのJavaインタフェース

Webサービス・パートナの属性は、com.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して操作できます。

サーブレットに対するIDアサーションの順序付け

HTTPリクエストが送信されたときに、IDアサーションに使用できる一致が複数存在する場合があります。一方、IDアサーション・プロバイダが一度に消費できるのは1つのアクティブなトークン・タイプだけです。つまり、一度の呼出しで一連のトークンを消費できる方法は提供されていません。したがってWebLogic Serverに含まれるサーブレットでは、IDアサーションを実行するために複数のトークンから1つを選択する必要があります。選択は次の順序で行われます。

1. X.509がデフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つである場合は、X.509デジタル証明書(クライアントとWebサーバーの間での双方向SSLを備えた、クライアントまたはプロキシ・プラグインへの双方向SSLを示します)。

2. WL-Proxy-Client-<TOKEN>という形式の名前を持つヘッダー。<TOKEN>は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。

注意:
この方法は非推奨で、後方互換性のためだけに使用する必要があります。

3. <TOKEN>という形式の名前を持つヘッダー。<TOKEN>は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。

4. <TOKEN>という形式の名前を持つCookie。<TOKEN>は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。

たとえば、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダがアクティブなトークン・タイプとしてFOOおよびBARというトークンを持つように構成されている場合(次の例では、HTTPリクエストにはIDアサーションに関連するものはアクティブなトークン・タイプ以外、何も含まれていないものとします)、IDアサーションは次のように実行されます。

- FOOヘッダーを持つリクエストが双方向SSL接続を使用して受信される場合、X.509がIDアサーションに使用されます。

- FOOヘッダーを持ち、WL-Proxy-Client-BARヘッダーを持つリクエストが受信される場合、BARトークンがIDアサーションに使用されます。

- FOOヘッダーを持ち、BARCookieを持つリクエストが受信される場合、FOOトークンがIDアサーションに使用されます。

同じレベルの複数のトークン間の順序付けは定義されていません。そのため、次のようになります。

- FOOヘッダーを持ち、BARヘッダーを持つリクエストが受信される場合、FOOトークンまたはBARトークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。

- FOOCookieを持ち、BARCookieを持つリクエストが受信される場合、FOOトークンまたはBARトークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。

サーバー・キャッシュのIDアサーション・パフォーマンスの構成

IDアサーション・プロバイダ(X.509証明書またはその他のトークン)を使用する場合、サブジェクトはサーバーにキャッシュされます(サブジェクトとは、単一のエンティティ(個人など)に関連する情報のグループで、IDやそのセキュリティ関連の構成オプションなどが含まれます)。サーバー内にサブジェクトをキャッシュすると、<run-as>タグのあるサーブレットおよびEJBメソッドや、HTTPSessionでIDアサーションが使用されるがキャッシュはされないような他の状況(XMLドキュメントの署名や暗号化など)におけるパフォーマンスが大幅に向上します。

注意:
キャッシングは、セマンティクスに違反することがあります。

このキャッシュ内の項目の存続期間を変更するには、-Dweblogic.security.identityAssertionTTLコマンド・ライン引数を使用してサブジェクトがキャッシュに存在できる最大秒数を設定します。このコマンド・ライン引数のデフォルトは300秒(5分)です。コマンド・ライン引数に指定できる値は次のとおりです。

- 0より小さい値 - キャッシュを無効化します。

- 0 - キャッシュは有効であり、キャッシュ内のIDはサーバーが実行中である限り、タイムアウトになりません。キャッシュされたエントリのユーザー・データベースが変更された場合は、サーバーがエントリを取得するために必ずサーバーの再起動が必要になります。

- 0より大きい値 - キャッシュは有効であり、キャッシュは指定された秒数でリセットされます。

IDアサーションのパフォーマンスを向上させるには、このコマンド・ライン引数により大きな値を指定します。

注意:
IDアサーションのパフォーマンスが上がるにつれて、IDアサーション・プロバイダは構成されている認証プロバイダの変化に反応しなくなります。たとえば、ユーザーのグループの変更は、サブジェクトがキャッシュからフラッシュされて再作成されるまで反映されなくなります。このコマンド・ライン引数でより小さい値を指定すると、認証変更の反応は良くなりますが、パフォーマンスは低下します。

ユーザー名マッパーの構成

WebLogic Serverは、双方向SSL接続を確立するときにWebブラウザまたはJavaクライアントのデジタル証明書を確認します。ただし、デジタル証明書はWebブラウザまたはJavaクライアントをWebLogic Serverセキュリティ・レルムのユーザーとしては認識しません。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストすると、WebLogic ServerはWebブラウザまたはJavaクライアントにIDを持つように要求します。WebLogic IDアサーション・プロバイダは、WebブラウザまたはJavaクライアントのデジタル証明書をWebLogic Serverセキュリティ・レルムのユーザーにマッピングするユーザー名マッパーを有効にできるようにします。

ユーザー名マッパーは、weblogic.security.providers.authentication.UserNameMapperインタフェースの実装でなければなりません。このインタフェースは、必要に応じた方式に従って、トークンをWebLogic Serverのユーザー名にマップします。デフォルトでは、WebLogic Serverはweblogic.security.providers.authentication.UserNameMapperインタフェースのデフォルトの実装が提供されます。また、独自の実装を記述することもできます。

WebLogic IDアサーション・プロバイダは、以下のIDアサーション・トークン・タイプについて、ユーザー名マッパーを呼び出します。

- SSLハンドシェークを通じて渡されたX.509デジタル証明書

- CSIv2を通じて渡されたX.509デジタル証明書

- CSIv2を通じて渡されたX.501識別名

デフォルトのユーザー名マッパーは、デジタル証明書または識別名のサブジェクトDNを使用して、WebLogic Serverセキュリティ・レルムの適切なユーザーにマッピングします。たとえば、サブジェクトDNの電子メール属性(smith@example.com)にあるユーザーを、WebLogic Serverセキュリティ・レルムのユーザー(smith)にマッピングするように、ユーザー名マッパーを構成できます。この情報を定義するには、WebLogic IDアサーション・プロバイダの「デフォルト・ユーザー名マッパーの属性の種類」と「デフォルト・ユーザー名マッパーの属性のデリミタ」を使用します。

- 「デフォルト・ユーザー名マッパーの属性の種類」 - ユーザー名の算出に使用されるデジタル証明書のサブジェクト識別名(DN)。有効な値は、C、CN、E、L、O、OU、S、およびSTREETです。

- デフォルト・ユーザー名マッパーの属性のデリミタ - ユーザー名を終了させる記号。ユーザー名マッパーは、この値の左側のすべてを使用してユーザー名を算出します。デフォルトの区切り記号は@です。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー名マッパーの構成に関する項を参照してください。

カスタム・ユーザー名マッパーの構成

カスタム・ユーザー名マッパーを記述して、必要に応じた方式に従ってトークンをWebLogic Serverのユーザー名にマップすることもできます。カスタム・ユーザー名マッパーは、weblogic.security.providers.authentication.UserNameMapperインタフェースの実装でなければなりません。次に、WebLogic IDアサーション・プロバイダの「ユーザー名マッパーのクラス名」属性を使用して、カスタム・ユーザー名マッパーをアクティブなセキュリティ・レルムで構成します。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。

6 Microsoftのクライアントに対するシングル・サインオンの構成

この章では、SPNEGO (Simple and Protected Negotiate)メカニズムとKerberosプロトコルに基づく統合Windows認証とWebLogicネゴシエートIDアサーション・プロバイダを使用して、Microsoftクライアントでのシングル・サインオン(SSO)を設定する方法について説明します。WebLogic Server 10.3.6ではSAMLに基づくシングル・サインオン(SSO)がサポートされています。

この章の内容は以下のとおりです。

- Microsoftのクライアントに対するシングル・サインオンの概要

- Microsoftのクライアントを含むSSOに必要なシステム要件

- Microsoftのクライアントに対するシングル・サインオン: 主な手順

- Kerberosを使用するためのネットワーク・ドメインの構成

- WebLogic Server用のKerberos識別情報の作成

- Microsoftのクライアントで統合Windows認証を使用するための構成

- JAASログイン・ファイルの作成

- IDアサーション・プロバイダの構成

- WebLogic ServerでのKerberos認証における起動引数の使用

- Microsoftのクライアントに対するSSOの構成の検証

Microsoftのクライアントに対するシングル・サインオンの概要

Microsoftクライアントでシングル・サインオン(Single sign-on: SSO)を利用すると、WebLogicドメインで動作するWebアプリケーションまたはWebサービスと、Microsoftドメイン内の.NET Webサービス・クライアントまたはブラウザ・クライアント(Internet Explorerなど)の間でクロス・プラットフォーム認証を実行できます。Microsoftのクライアントでは、SPNEGO (Simple and Protected Negotiate)メカニズムに基づいた統合Windows認証を使用する必要があります。

プラットフォームを越えた認証は、元々Windowsシステム間で行われているKerberosプロトコルを使用した認証サービスをエミュレートすることで実現されます。クロス・プラットフォーム認証を適切に実行するには、非Windowsのサーバー(ここではWebLogic Server)側でSPNEGOトークンを解析し、認証に使用されるKerberosトークンを展開する必要があります。

WindowsおよびKerberosの詳細は、http://technet.microsoft.com/en-us/library/bb742431.aspxを参照してください。

注意:
WebLogic ServerでのMicrosoftクライアントのシングル・サインオン(SSO)サポートは、Webアプリケーションでのみ利用でき、EJBなど、他のアプリケーション・タイプでは利用できません。

Microsoftのクライアントを含むSSOに必要なシステム要件

MicrosoftのクライアントでSSOを使用するには、次の各項で説明している要件を満たす必要があります。

- MicrosoftクライアントでSSOをサポートするためのホスト・コンピュータの要件

- SSOを使用するMicrosoftクライアントをサポートするためのクライアント・コンピュータの要件

MicrosoftクライアントでSSOをサポートするためのホスト・コンピュータ要件

MicrosoftクライアントのSSOをサポートするホスト・コンピュータは、次のシステム要件を満たす必要があります。

- Windows Server 2000、2003または2008 R2がインストールされています。

- Active Directoryによる認証サービスが完全に構成されています。Active Directoryの要件は以下のとおりです。

- Kerberosサービスをマッピングするためのユーザー・アカウント群。

- それらのアカウント用のサービス・プリンシパル名(SPN)。

- キータブ・ファイルが作成され、WebLogicドメインの起動ディレクトリにコピーされています。

- WebLogic Serverがインストールされ、JDK 1.6.0_24以降で、この章の説明のとおりKerberosを使った認証を行うように適切に構成されています。

WebLogic ServerホストでKerberosサービスにマップされるユーザー・アカウントを暗号化することをお薦めします。ただし、これらのアカウントを暗号化できるようにするには、さらに要件を満たす必要があります。この特定の要件は、表6-1に示すとおり、使用する暗号化アルゴリズムに依存します。

表6-1 暗号化されたユーザー・アカウントを使用するためのクライアント・タイプの要件

暗号化

サポートされるクライアント・タイプ

Active Directoryプラットフォーム

DES

- Internet Explorer 6.01以上

- Mozilla FireFox

- .NET Webサービス

- Java SEクライアント

Windows 2003以降

AES-128、AES-256およびRC4

- Internet Explorer 8.0

- Mozilla FireFox 7.0.1

- Java SEクライアント脚注 1

Windows 2008-R2以降

脚注 1 Java SEクライアントでアクセスされるユーザー・アカウントは、DES、AES-128、AES-256およびRC4で暗号化し、Windows 2003プラットフォームで実行されるActive Directoryで定義することもできます。

SSOを使用するMicrosoftクライアントをサポートするためのクライアント・コンピュータの要件

SSOを使用するMicrosoftクライアントをホストするコンピュータは、次の要件を満たす必要があります。

- Windows 2000 Professional SP2以降がインストールされています。

注意:
Active Directoryで定義され、AES-128、AES-256またはRC4で暗号化されたユーザー・アカウントにアクセスするInternet Explorer 8.0クライアントおよびFireFox 7.0.1クライアントがWindows 7 Enterpriseプラットフォームで動作することが保証されています。

- 次のいずれかのタイプのクライアントがホストされています。

- 適切に構成されたInternet Explorerブラウザ。Internet Explorer 6.01以降がサポートされています(「Internet Explorerブラウザの構成」を参照)。

- 適切に構成されたMozilla Firefoxブラウザ(「Mozilla Firefoxブラウザの構成」を参照)

- .NETフレームワーク1.1および適切に構成されたWebサービス・クライアント(「.NET Webサービスの構成」を参照)。

- スタンドアロンのJava SEクライアント・アプリケーション(「Java SEクライアント・アプリケーションの構成」を参照)

クライアントはWindows 2000のドメインにログオンしていて、そのドメイン内のActive Directoryサーバーから取得したKerberosの資格証明を保持している必要があります。ローカル・ログインは機能しません。

Microsoftのクライアントに対するシングル・サインオン: 主な手順

MicrosoftのクライアントにSSOを構成するには、Microsoft Active Directory、クライアント、およびWebLogicドメインでの設定手続きが必要です。この手順についてこれ以降の項で説明します。

- WebLogic Serverを表すプリンシパルをActive Directoryで定義します。Kerberosプロトコルでは、必要なセキュリティ情報の格納にMicrosoftドメインのActive Directoryサーバーを使用します。

- Microsoftドメイン内にあるアクセス対象のMicrosoftクライアントでは、統合Windows認証を使用し、使用可能な場合にはKerberosチケットを送信するように設定されている必要があります。

- WebLogicドメインのセキュリティ・レルムに、ネゴシエーションIDアサーション・プロバイダを構成します。SSOで使用されるWebアプリケーションまたはWebサービスでは、特定の方式による認証セットが保持されていることが必要です。さらに、WebLogic ServerのKerberos識別情報の場所を定義するJAASログイン・ファイルも作成する必要があります。

Microsoftのクライアントに対するSSOは次のように構成します。

1. Kerberosを使用するようにネットワーク・ドメインを構成します。「Kerberosを使用するためのネットワーク・ドメインの構成」を参照してください。

2. WebLogic Server用にKerberos識別情報を作成します。

1. WebLogic Serverの動作するホスト用にActive Directoryのユーザー・アカウントを作成します。

2. 作成したアカウント用にサービス・プリンシパル名(SPN)を作成します。

3. 作成したアカウント用にユーザー・マッピングとキータブ・ファイルを作成します。

「WebLogic Server用のKerberos識別情報の作成」を参照してください。

3. Microsoftのクライアント(Webサービスまたはブラウザ)またはJava SEクライアントを選択し、統合Windows認証を使用するように構成します。「Microsoftのクライアントで統合Windows認証を使用するための構成」を参照してください。

4. WebLogicドメインでKerberos認証を使用するように設定します。

1. MicrosoftドメインのActive Directoryサーバーおよびステップ1で作成したキータブ・ファイルを指し示すJAASログイン・ファイルを作成します。「JAASログイン・ファイルの作成」を参照してください。

2. WebLogic Serverのセキュリティ・レルムにネゴシエートIDアサーション・プロバイダを構成します。「ネゴシエートIDアサーション・プロバイダの構成」を参照してください。

5. WebLogic Serverを特定の起動引数を使用して起動します。「WebLogic ServerでのKerberos認証における起動引数の使用」を参照してください。

これらの手順について以下の節で詳細に説明します。

Kerberosを使用するためのネットワーク・ドメインの構成

Windowsドメイン・コントローラは、Kerberosベース・クライアントおよびホスト・システムのKerberosキー配布センター(KDC)・サーバーとして機能します。どのドメイン・コントローラでも、Active DirectoryサービスおよびKerberosサービスは自動的に実行されます。

Java GSSでは、Kerberos構成ファイルが必要になります。Kerberos構成ファイルのデフォルトのファイル名と格納場所は、使用しているオペレーティング・システムによって異なります。Java GSSでは、次の順序でデフォルトの構成ファイルが検索されます。

1. Javaプロパティjava.security.krb5.confで参照されているファイル

2. ${java.home}/lib/security/krb5.conf.

3. Microsoft Windowsプラットフォームの場合は%windir%\krb5.ini

4. Solarisプラットフォームの場合は/etc/krb5/krb5.conf

5. 他のUNIXプラットフォームの場合は/etc/krb5.conf

Windowsドメイン・コントローラでKerberosを構成するには、Kerberosレルムと使用可能なKDCサーバーを特定するように、KDCにアクセスする各マシンを構成する必要があります。例:

例6-1 サンプルkrb5.iniファイル

[libdefaults]
default_realm = MYDOM.COM (Identifies the default realm. Set its value to your Kerberos realm)
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600

[realms]

MYDOM.COM = {
kdc = <IP address for MachineA> (host running the KDC)
(For UNIX systems, you need to specify port 88, as in <IP-address>:88)
admin_server = MachineA
default_domain = MYDOM.COM
}

[domain_realm]
.mydom.com = MYDOM.COM

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

WebLogic Server用のKerberos識別情報の作成

Active Directoryでは、Kerberos認証の主要なコンポーネントであるサービス・プリンシパル名(SPN)がサポートされています。SPNは、サーバー上で動作しているサービスに対する一意のIDです。Kerberos認証を使用するすべてのサービスは各自のSPNのセットを保持する必要があり、それによってクライアント側でのネットワーク上のサービスの識別が可能になります。SPNは通常、name@YOUR.REALMのようになっています。KerberosレルムのWebLogic Serverを表すSPNを定義する必要があります。サービスにSPNが設定されていないと、クライアントではそのサービスの場所を特定できません。つまり、SPNが正しく設定されていなければKerberos認証は不可能だということになります。一連のSPNを格納するメカニズムとしてキータブ・ファイルがあります。キータブ・ファイルはWebLogicドメインにコピーして、ログイン・プロセスで使用します。この構成手順では、WebLogic Server用のSPN、ユーザー・マッピング、およびキータブ・ファイルの作成方法について説明します。

この構成手順では、次のActive Directoryユーティリティを使用します。

- setspn - Windows 2000リソース・キット

- ktpass - Program Files\Support Tools内のWindows 2000配布用CD

注意:
setspnおよびktpass Active DirectoryユーティリティはMicrosoftの製品です。そのため、Oracleではこのユーティリティに関する詳細なドキュメントを提供していません。詳細は、Microsoftの適切なドキュメントを参照してください。

Kerberos識別情報の作成プロセスは、次の手順で構成されます。

- ステップ1: ホスト・コンピュータのユーザー・アカウントの作成

- ステップ2: Kerberosに準拠するユーザー・アカウントの構成

- ステップ3: サービス・プリンシパル名の定義とサービスのキータブの作成

- ステップ4: 正しい設定の検証

- ステップ5: デフォルトのJDKセキュリティ・ポリシー・ファイルの更新

ステップ1: ホスト・コンピュータのユーザー・アカウントの作成

Active DirectoryサーバーにWebLogic Serverが動作するホスト・コンピュータのユーザー・アカウントを作成します(「新規作成」>「コンピュータ」ではなく、「新規作成」>「ユーザー」を選択します)。

ユーザー・アカウントを作成する際には、シンプルなコンピュータ名を使用してください。たとえば、ホスト名がmyhost.example.comの場合、Active Directoryのユーザーはmyhostのような名前にします。

ユーザー・アカウントの作成時に定義したパスワードを書き留めておいてください。「ステップ3: サービス・プリンシパル名の定義とサービスのキータブの作成」で説明する手順にこのパスワードが必要になります。「ユーザーは次回ログオン時にパスワードの変更が必要」オプションやその他のパスワード・オプションを選択しないでください。

ステップ2: Kerberosに準拠するユーザー・アカウントの構成

Kerberosプロトコルに準拠するように新しく作成したユーザー・アカウントを構成します。ユーザー・アカウントの暗号タイプは少なくともDESにする必要があり、アカウントはKerberos事前認証を必要とします。AES-128、AES-256、RC4など、より強力な暗号タイプがサポートされます。

1. 左ペインの「ユーザー」ツリーでユーザー・アカウント名を右クリックして、「プロパティ」を選択します。

2. 「アカウント」タブを選択してから、次のチェック・ボックスを選択します。

- DES暗号化を使用する場合、このアカウントにDES暗号化を使用するチェック・ボックスを選択します。

注意:
DES暗号化ではActive DirectoryがWindows Server 2003以降で動作している必要があります。

- AES暗号化を使用する場合、「このアカウントでKerberos AES 128ビット暗号化をサポートする」および「このアカウントでKerberos AES 256ビット暗号化をサポートする」のチェック・ボックスを選択し、「Kerberos DES暗号化を使用する」のチェックを解除します。

注意:
AES-128およびAES-256の暗号化ではActive DirectoryがWindows Server 2008-R2以降で動作している必要があります。

その他のボックス(特に「Kerberos事前認証を必要としない」ボックス)が選択されていないことを確認します。

3. 「OK」をクリックします。

警告:
暗号タイプを設定すると、パスワードが破損するおそれがあります。そのため、ユーザー・パスワードをリセットする必要があります。ユーザー・アカウントの名前を右クリックして「パスワードのリセット」を選択し、「ステップ1: ホスト・コンピュータのユーザー・アカウントの作成」で作成したパスワードと同じパスワードを再入力してください。

ステップ3: サービス・プリンシパル名の定義とサービスのキータブの作成

「WebLogic ServerのKerberos識別情報の作成」で示すように、SPNは、サービスのインスタンスを識別する一意の名前で、サービス・インスタンスが実行するログオン・アカウントに関連付けられます。SPNは、特定のサービスをホストするクライアントとサーバー間の相互認証のプロセスで使用されます。接続しようとするサービスのSPNに基づきクライアントがコンピュータ・アカウントを検出します。そのため、特定のプロジェクトでは、WebLogicクライアントから呼び出されるサービスと、WebLogic Serverに定義したアカウントを結び付ける必要があります。たとえば、WebLogicブラウザ・クライアントで呼び出されるサービスHTTP/myhost.example.comは、myhostアカウントと結び付ける必要があります。

Windowsアカウント名はKerberosプリンシパル名としてのマルチパートではありません。このため、名前HTTP/hostname.dns.comを使用してアカウントを直接作成することはできません。このようなプリンシパル・インスタンスは、SPNマッピングによって作成されます。この場合、アカウントは意味のある名前hostnameで作成され、SPNマッピングはHTTP/hostname.dns.comに対して追加されます。

SPNを定義してサービスのキータブを作成する固有の手順は、WebLogic Serverが実行している基盤のプラットフォームによって異なります。これらについては次の項で説明します。

- WindowsシステムでのSPNの定義とキータブの作成

- UNIXシステムでのSPNの定義とキータブの作成

WindowsシステムでのSPNの定義とキータブの作成

WebLogic ServerがWindowsシステムで実行する場合、次の手順を実行します。

1. setspnユーティリティを使用して、ステップ1で作成されたWebLogic ServerアカウントのHTTPサービスのSPNを作成します。例:

setspn -A HTTP/myhost.example.com myhost

2. setspn -Lコマンドを入力して、ユーザー・アカウントに関連付けられるSPNを特定します。例:

setspn -L myhost

ヒント:
前述の手順は重要です。同じサービスがActive Directoryサーバーの異なるアカウントに結び付けられている場合、クライアントはサーバーにKerberosチケットを送信しません。

3. ktabユーティリティを使用して、WebLogic Serverマシンにエクスポートされるキータブを作成します。ktabユーティリティを実行するコマンドの構文は次のとおりです(Kerberosレルム名はすべて大文字で入力してください)。

ktab -k keytab-file-name -a account-name@REALM.NAME

例:

ktab -k mykeytab -a myhost@MYDOM.COM

パスワードが求められた場合、ステップ1で作成したパスワードを入力します。

4. キータブ・ファイルを安全な場所に保存し、そのファイルをWebLogic Serverインスタンスのドメイン・ディレクトリ(myhostなど)にエクスポートします。

UNIXシステムでのSPNの定義とキータブの作成

WebLogic ServerがUNIXシステムで実行する場合、ktpassコマンドライン・ツールを使用して、WebLogic ServerアカウントのHTTPサービスのサービス・プリンシパル名(SPN)とキータブ・ファイルを作成します。このツールを使用すると、管理者はWindows Server Active Directoryのセキュリティ・プリンシパルとしてWindows Server以外のKerberosサービスを構成できます。

ktpassコマンドは、Active DirectoryでサービスのSPNを構成し、サービスの共有秘密鍵を含むKerberosキータブ・ファイルを生成します。ツールを使用すると、Kerberos認証をサポートするUNIXベースのサービスでは、Windows Server Kerberos KDCサービスで提供される相互運用機能を使用できます。

ktpassコマンドの構文は次のようになります。

ktpass -princ HTTP/hostname@REALM-NAME -mapuser account-name -pass password -out keytab-file-name -crypto algorithm -ptype KRB5_NT_PRINCIPAL

前述の構文で、algorithmは使用する暗号化アルゴリズムを示します。AESを使用する場合、AES128-SHA1またはAES256-SHA1を指定します。例:

ktpass -princ HTTP/myhost.example.com@MYDOM.COM -mapuser myhost -pass welcome1 -out mykeytab -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL

注意:
UNIXシステムでは、DESまたはAESの暗号化アルゴリズムを使用するSPNの作成は、JDK 1.6.0_24以降でサポートされます。

SPNおよびキータブ・ファイルが正しく設定されていることを確認するには、次の操作を行います。

- setspn -lコマンドを使用して、SPNが正常にマップされていることを確認します。

- klistコマンドを使用して、AES-128の場合Key type: 17、AES-256の場合Key type: 18を表示します。例:

-klist -e -k keytab-file-name

- kinitコマンドを使用して、Kerberos設定およびキータブが有効であることを確認します。

注意:
ktpassコマンドは、Active Directoryサーバーでプリンシパル名を、account-nameからHTTP/account-nameに変更します。その結果、HTTP/account-nameというプリンシパルに対してキータブ・ファイルが生成されます。ただし、名前が変更されない場合があります。変更されない場合、Active Directoryサーバーで名前を手動で変更する必要があります。変更を行わない場合、生成したキータブは適切に機能しません。
ユーザー・ログオン名を手動で変更するには、次の操作を行います。

1. ユーザー・ノードを右クリックして 「プロパティ」を選択し、「アカウント」タブをクリックします。

2. WebLogicドメイン・ディレクトリのWebLogic ServerをホストするUNIXマシンに、生成されたキータブ・ファイルをエクスポートします。

ステップ4: 正しい設定の検証

次のユーティリティを使用して、SPNとキータブ・ファイルが正常に設定されていることを確認します。

- setspn -lコマンドを使用して、SPNが正常にマップされていることを確認します。

- klistコマンドを使用して、キー・タイプを確認します。例:

-klist -e -k keytab-file-name

AES 128の場合、このコマンドによりKey type: 17と表示されます。AES 256の場合、Key type: 18と表示されます。

- kinitユーティリティを使用して、Kerberosが正しく設定されていることと、プリンシパルおよびキータブが有効であることを検証します。
JREで提供されるkinitユーティリティを使用して、Kerberosチケット許可チケットを取得およびキャッシュできます。kinitユーティリティを実行するには、次のコマンドを入力します。

kinit -k -t keytab-file account-name

出力は次のようになります。

New ticket is stored in cache file C:\Documents and Settings\Username\krb5cc_myhost

ステップ5: デフォルトのJDKセキュリティ・ポリシー・ファイルの更新

AES-256では、Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6が必要です。これは次のURLで入手できます。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

AES暗号化を使用する場合、次の手順を実行します。

1. 前述のURLからJCE Unlimited Strength Jurisdiction Policy Filesをダウンロードします。

2. 管轄ポリシー・ファイルを圧縮解除し、抽出します。

3. 含まれているREADME.txtファイルで説明されているインストール手順を完了させます。

Microsoftのクライアントで統合Windows認証を使用するための構成

シングル・サインオンを利用するMicrosoftのクライアントでは、必ず統合Windows認証を使用するように構成します。次の各項では、.NET Webサーバー、Internet Explorerブラウザ・クライアント、Mozilla FirefoxクライアントおよびJava SEクライアントで、統合Windows認証を使用するように構成する方法を説明します。

- .NET Webサービスの構成

- Internet Explorerブラウザの構成

- Mozilla Firefoxブラウザの構成

- Java SEクライアント・アプリケーションの構成

注意:
KerberosチケットがマップされているWebLogic Serverホストでユーザー・アカウントのSPNがDESやAES-256の暗号化を使用するように構成されている場合(「ステップ2: Kerberosに準拠するユーザー・アカウントの構成」を参照)、クライアントはJDK 1.6.0_24以降で実行される必要があります。

.NET Webサービスの構成

.NET Webサービスで統合Windows認証を使用するようにするには、次のように構成します。

1. Webサービスのweb.configファイルで、IISおよびASP.NETの認証モードを次のようにWindowsに設定します。

<authentication mode="Windows" />

通常、これはデフォルトの設定です。

2. Webサービス・クライアントがプロキシWebサービス・オブジェクトに渡されるために必要な文を追加して、SOAPを介して資格証明が送られるようにします。
たとえば、プロキシ・オブジェクトconvで表されるWebサービスに対するWebサービス・クライアントの場合、次のような構文になります。

/*
* Explicitly pass credentials to the Web Service
*/
conv.Credentials =
System.Net.CredentialCache.DefaultCredentials;

Internet Explorerブラウザの構成

Internet Explorerブラウザが統合Windows認証を使用するように構成するには、次の項で説明する手順を完了します。

- ローカル・イントラネット・ドメインの構成

- イントラネット認証の構成

- プロキシ設定の検証

- Internet Explorer 6.0用の統合認証の設定

ローカル・イントラネット・ドメインの構成

Internet Explorerで:

1. 「ツール」>「インターネット・オプション」を選択します。

2. 「セキュリティ」タブを選択します。

3. 「イントラネット」を選択し、「サイト」をクリックします。

4. 「イントラネット」ポップアップ・ウィンドウで「プロキシ サーバーを使用しないサイトをすべて含める」オプションおよび「ほかのゾーンにないローカル (イントラネット) のサイトをすべて含める」オプションが選択されていることを確認します。

5. 「詳細設定」をクリックします。

6. 「イントラネット」ダイアログ・ボックスで、SSO構成に参加するWebLogic Serverインスタンスに対して使用されるすべての関連ドメインの名前(例: myhost.example.com)を追加し、「OK」をクリックします。

イントラネット認証の構成

Internet Explorerで:

1. 「ツール」>「インターネット・オプション」を選択します。

2. 「セキュリティ」タブを選択します。

3. 「イントラネット」を選択し、「レベルのカスタマイズ...」をクリックします。

4. 「セキュリティの設定」ダイアログ・ボックスでスクロールして「ユーザー認証」セクションを見つけます。

5. 「イントラネット・ゾーンでのみ自動的にログインする」オプションを選択します。このオプションを選択すると、ログオン用の資格証明を再入力する必要がなくなります。これがこのソリューションの重要な部分です。

6. 「OK」をクリックします。

プロキシ設定の検証

プロキシ・サーバーを有効にしている場合:

1. Internet Explorerで、「ツール」>「インターネット・オプション」の順に選択します。

2. 「接続」タブを選択し、「LANの設定」をクリックします。

3. プロキシ・サーバーのアドレスとポート番号が正しいかどうかを検証します。

4. 「詳細設定」をクリックします。

5. 「プロキシの設定」ダイアログ・ボックスで、「例外」フィールドに目的とするドメイン名がすべて入力されていることを確認します。

6. 「OK」をクリックして「プロキシの設定」ダイアログ・ボックスを閉じます。

Internet Explorer 6.0用の統合認証の設定

構成するInternet Explorerのバージョンが6.0の場合、次の手順も実行する必要があります。

1. Internet Explorerで、「ツール」>「インターネット・オプション」の順に選択します。

2. 「詳細設定」タブを選択します。

3. スクロールして「セキュリティ」セクションを見つけます。

4. 「統合Windows認証を使用する」オプションがチェックされていることを確認し、「OK」をクリックします。
このオプションにチェックマークが入っていない場合、チェックマークを入れ、「OK」をクリックしてコンピュータを再起動します。

Mozilla Firefoxブラウザの構成

Windows統合認証を使用するようにFirefoxブラウザを構成するには、次の手順を実行します。

1. Firefoxを起動します。

2. ロケーション・バーでabout:configを入力します。

3. フィルタ文字列としてnetwork.negotiateと入力します。

4. 各プリファレンスを表6-2のように設定します。

表6-2 FirefoxでWindows統合認証を使用するために必要なプリファレンス

プリファレンス名

ステータス

タイプ

値

network.negotiate-auth.allow-proxies

default

boolean

true

network.negotiate-auth.delegation-uris

user set

string

http://,https://

network.negotiate-auth.gsslib

default

string

<blank>脚注 1

network.negotiate-auth.trusted-uris

user set

string

http://,https://

network.negotiate-auth.using-native-gsslib

default

boolean

true

脚注 1 network.negotiate-auth.gsslibプリファレンスの値は空白にしてください。

Java SEクライアント・アプリケーションの構成

統合Windows認証を使用するようにJava SEクライアント・アプリケーションを構成するには、次の手順を実行します。

1. Java SEクライアントがJDK 1.6.0_24以降で動作していることを確認します。

2. Kerberosログイン・モジュール(com.sun.security.auth.module.Krb5LoginModule)を示すJAAS構成ファイルを作成します。この構成ファイルには、次の2つのログイン・エントリを定義します。

- com.sun.security.jgss.krb5.initiate - Javaクライアントに対して呼び出されます。

- com.sun.security.jgss.krb5.accept - KerberosのIDで表され、クライアントがアクセスするWebアプリケーションをホストするWebLogic Serverインスタンスに対して呼び出されます。

各ログイン・エントリに対し、次のようなオプションが含まれます。

- プリンシパルの認証が成功する必要があります(つまり、クライアント・アプリケーションのユーザーがMicrosoftドメインで定義されていること)。

- useKeyTabをtrueに設定します。これにより、プリンシパルのキーがキータブから取得されます。

- キータブの名前を識別します。

- storeKeyをtrueに設定します。これにより、プリンシパルのキーがサブジェクトに格納されます。

- 必要に応じて、debugオプションをtrueに設定します。

次のサンプルは、Active Directoryサーバーが実行されるMicrosoftドメインSECURITYQA.COMで定義されたnegotiatetesterプリンシパルで使用されるKerberosログイン・モジュールのJAAS構成ファイルを示しています。

com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule
required principal="negotiatetester@SECURITYQA.COM"
useKeyTab=true
keyTab=negotiatetester_keytab storeKey=true debug=true; };

com.sun.security.jgss.krb5.accept {
com.sun.security.auth.module.Krb5LoginModule
required principal="negotiatetester@SECURITYQA.COM"
useKeyTab=true keyTab=negotiatetester_keytab storeKey=true debug=true; };

3. クライアント・アプリケーションを起動するJavaコマンドで、次の値を引数として渡します。

- Active Directoryサーバーが実行されるMicrosoftドメイン

- Kerberos Key Distribution Center (KDC)サーバーを実行するコンピュータのホスト名

- Kerberosログイン・モジュールを識別するJAAS構成ファイル

- javax.security.auth.useSubjectCredsOnly=falseプロパティ。これは、サブジェクトの資格証明ではない認証メカニズムの使用を認めることを指定します。

- Java SEクライアント・クラスの名前

- アクセスが要求されるWebアプリケーション・リソース

例:

java -Djava.security.krb5.realm = SECURITYQA.COM\
-Djava.security.krb5.kdc = rno05089.example.com\
-Djava.security.auth.login.config = negotiatetester_krb5Login.conf\
-Djavax.security.auth.useSubjectCredsOnly = false\
RunHttpSpnego http://myhost.example.com:7001/AuthenticatedServlet.jsp

JAASログイン・ファイルの作成

WindowsまたはUNIXのプラットフォームでWebLogic Serverを実行している場合、JAASログイン・ファイルが必要です。また、JAASログイン・ファイルにはWebLogic ServerのKerberos ID情報の格納されたキータブ・ファイルの場所も定義します。このファイルの場所は、WebLogic Serverのjava.security.auth.login.config起動引数で指定します。「WebLogic ServerでのKerberos認証における起動引数の使用」を参照してください。

注意:
JDK 6.0の場合、JAASログイン・エントリ名は、com.sun.security.jgss.krb5.initiateおよびcom.sun.security.jgss.krb5.acceptに変更されました。

例6-2に、Kerberos認証用のJAASログイン・ファイルのサンプルを示します。重要な箇所は太字で示しています。

例6-2 Kerberos認証用のJAASログイン・ファイルのサンプル

com.sun.security.jgss.krb5.initiate {

com.sun.security.auth.module.Krb5LoginModule required
principal="myhost@Example.CORP" useKeyTab="true"
keyTab="mykeytab" storeKey="true";
};

com.sun.security.jgss.krb5.accept {

com.sun.security.auth.module.Krb5LoginModule required
principal="myhost@Example.CORP" useKeyTab="true"
keyTab="mykeytab" storeKey="true";

};

プリンシパル・オプションには、サービスを実行しているアカウントのuserPrincipalName属性の値を指定します(間違ったユーザー・プリンシパル名を指定すると、「Unable to obtain password from user」などのエラーが発生します)。

keytabオプションに指定するキータブ・ファイルは、WebLogic Serverプロセスからアクセスできるファイルでなければなりません。適切な権限が設定されていることを確認してください。WebLogic Serverで使用されている検索パスが不明な場合は、ファイルへの絶対パスを指定します。パスは二重引用符で囲み、パス内のバックスラッシュ(\)は二重バックスラッシュ(\\)またはフォワード・スラッシュ(/)で置き換えてください。

IDアサーション・プロバイダの構成

WebLogic Serverには、Microsoftクライアントを使用したシングル・サインオン(SSO)をサポートするセキュリティ・プロバイダ、ネゴシエートIDアサーション・プロバイダがあります。このIDアサーション・プロバイダでは、SPNEGO (Simple and Protected Negotiate)のトークンをデコードしてKerberosのトークンを取得し、そのKerberosトークンを検証した後でWebLogicユーザーにマップします。Microsoftクライアントを使用したSSOを有効にするには、WebLogicセキュリティ・レルムでネゴシエートIDアサーション・プロバイダを構成する必要があります。「ネゴシエートIDアサーション・プロバイダの構成」、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダおよびIDアサーション・プロバイダの構成に関する項を参照してください。

WebLogic ServerでのKerberos認証における起動引数の使用

WebLogic ServerでKerberos認証を使用するには、WebLogic Serverの起動時に以下の起動引数を使用します。

-Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.auth.login.config=krb5Login.conf
-Djava.security.krb5.realm=Example.CORP
-Djava.security.krb5.kdc=ADhostname

説明:

- javax.security.auth.useSubjectCredsOnlyには、サブジェクトの資格証明ではない認証メカニズムの使用を認めることを指定します。

- java.security.auth.login.configには、JAASログイン・ファイルkrb5Login.confを指定します(「JAASログイン・ファイルの作成」を参照)。

- java.security.krb5.realmには、Active Directoryサーバーが動作するMicrosoftドメインを定義します。

- java.security.krb5.kdcには、Active Directoryサーバーが動作するホストの名前を定義します。

Java GSSメッセージはトラブルシューティングで非常に役立つことが多いため、初期設定の段階で- Dsun.security.krb5.debug=trueを追加しておくとよいでしょう。

Microsoftのクライアントに対するSSOの構成の検証

Microsoftのクライアントを含むSSOが適切に構成されているかどうかを検証するには、使用するMicrosoftのWebアプリケーションまたはWebサービスをブラウザ(「Internet Explorerブラウザの構成」の説明に従って構成したもの)で指定します。Windowsドメインにログオンし、そのドメインのActive DirectoryサーバーからKerberos資格証明を取得している場合、ユーザー名とパスワードを指定せずにWebアプリケーションまたはWebサービスにアクセスできるはずです。

7 WebブラウザとHTTPクライアントによるシングル・サインオンの構成

この章では、Security Assertion Markup Language (SAML)バージョン1.1および2.0に基づく認証を使用して、Webブラウザまたはその他のHTTPクライアントによるシングル・サインオン(SSO)を設定する方法について説明します。Security Assertion Markup Language (SAML)を使用すると、WebLogicドメインで実行されているWebアプリケーションまたはWebサービスと、Webブラウザまたはその他のHTTPクライアントの間でクロス・プラットフォーム認証を実行できます。WebLogic Server 10.3.6ではSAMLに基づくシングル・サインオン(SSO)がサポートされています。シングル・サインオン(SSO)構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証されるので、別個にログインする必要がありません。

この章の内容は以下のとおりです。

- SAMLホワイト・ペーパーを使用したシングル・サインオンの構成

- Webシングル・サインオン・シナリオ用SAMLのAPIサンプル

- SAML 1.1サービスの構成

- SAML 2.0サービスの構成

- SAML 1.1および2.0のデバッグの有効化

注意:
次の点に注意してください。

- SAML 2.0 SSO用に構成されたWebLogic Serverインスタンスと、SAML 1.1用に構成されたインスタンスの間で、リクエストを送受信することはできません。

- WebLogic Serverでは、SAMLで暗号化されたアサーションはサポートされていません。

SAMLベースのシングル・サインオンの概要については、『Oracle WebLogic Serverセキュリティの理解』の次のトピックを参照してください。

- 「SAML (Security Assertion Markup Language)」

- 「SAMLの使用によるWebブラウザとHTTPクライアント」

- 「WebLogicセキュリティ・フレームワークによるシングル・サインオン」

SAMLホワイト・ペーパーを使用したシングル・サインオンの構成

ホワイト・ペーパー「WebLogic Server 9.2におけるSAMLを使用したシングル・サインオンの構成」(http://www.oracle.com/technetwork/articles/idm/sso-with-saml-099684.html)は、2種類のWebLogicドメインで稼働している2つの単純なJava EE Webアプリケーション間のシングル・サインオン機能の構成に関するステップ・バイ・ステップの手順を提供します。シングル・サインオン用のSAML構成は、WebLogic Server 9.2管理コンソールを使用してプログラミングを組み込まずに実行されます。また、このチュートリアルでは、シングル・サインオン処理中のWebLogicコンテナ、セキュリティ・プロバイダ、およびセキュリティ・フレームワーク間の基本的な相互作用を簡単に紹介します。

以前のバージョンのWebLogic Serverに基づいていますが、このチュートリアルは独自のSAML実装を開発する際に有用なリソースとなります。

Webシングル・サインオン・シナリオ用SAMLのAPIサンプル

WebLogic ServerのServer Examplesコンポーネント(カスタム・インストールを実行すると利用可能)をインストールすると、WebLogic Serverでは数個のAPIサンプル・コードもインストールされます。Server Examplesによりサンプル・コードおよびサンプル・アプリケーションにアクセスでき、様々な方法でWebLogic Serverについて学習したり操作ができます。

Web SSOシナリオのSAMLがセキュリティAPI例において含められています。このサンプルのビルド、実行およびデプロイを行うと、WebLogic ServerとSAMLを使用して、アプリケーションの様々なシングル・サインオン(SSO)構成が表示されます。次の3つのシナリオがあります。

- SAML 2.0 POSTバインディング

- SAML 1.1

- カスタム属性のあるSAML 2.0アーティファクト・バインディング

サンプルのビルド、デプロイおよび実行に必要なすべてのファイルは、使用されるWebLogicドメインを構成するスクリプトとして含まれています。インストールされるディレクトリを含め、サンプルの詳細は、『Oracle WebLogic Serverインフォメーション・ロードマップ』のサンプル・アプリケーションとコード・サンプルに関する項を参照してください。

SAML 1.1サービスの構成

このトピックには次のセクションが含まれます:

- SAML 1.1でのシングル・サインオンの有効化: 主な手順

- シングル・サインオン用のSAML 1.1ソース・サイトの構成

- シングル・サインオン用のSAML 1.1宛先サイトの構成

- WLSTを使用したリライイング・パーティとアサーティング・パーティの構成

サードパーティのSAMLリライイング・パーティによって要求される固有のSAML 1.1アサーション属性に件名をマッピングするカスタムSAML名前マッパーを作成する方法に関する詳細は、前述の項で説明されるトピックに加え、『Oracle WebLogic Serverセキュリティのプログラミング』の非WebLogic SAML 1.1リライイング・パーティ用アサーションの作成に関する項を参照してください。

SAML 1.1でのシングル・サインオンの有効化: 主な手順

SAMLによるシングル・サインオンを有効にするには、以下の手順に従って、WebLogic Serverをソース・サイトまたは宛先サイトとして構成します。

ソース・サイトの構成: 主な手順

WebLogic Serverインスタンスをソース・サイトとして構成するには、次の主な手順を実行します:

1. 使用するセキュリティ・レルムで、SAML資格証明マッピング・プロバイダV2を作成して構成します。

2. レルム内でソース・サイトとして機能するサーバー・インスタンスのフェデレーション・サービスを構成します。

3. 生成されるSAMLアサーションのリライイング・パーティを作成し、構成します。

4. ソース・サイトへの接続にSSL証明書を使用するようにリライイング・パーティを設定する場合は、SAML資格証明マッピング・プロバイダの証明書レジストリにそれらの証明書を追加します。

宛先サイトの構成: 主な手順

WebLogic Serverインスタンスを宛先サイトとして構成するには、次の主な手順を実行します:

1. 使用するセキュリティ・レルムで、SAML IDアサーション・プロバイダV2を作成して構成します。

2. レルム内で宛先サイトとして機能するサーバー・インスタンスのフェデレーション・サービスを構成します。

3. 消費されるSAMLアサーションのアサーティング・パーティを作成し、構成します。

4. 宛先サイトのSSL証明書を、SAML IDアサーション・プロバイダが保持する証明書レジストリに登録することによって、信頼を確立します。

シングル・サインオン用のSAML 1.1ソース・サイトの構成

以下の節では、WebLogic ServerインスタンスをSAML 1.1ソース・サイトとして構成する方法について説明します。

- SAML 1.1資格証明マッピング・プロバイダの構成

- ソース・サイト・フェデレーション・サービスの構成

- リライイング・パーティの構成

- デフォルトのアサーション・ストアの置換え

SAML 1.1資格証明マッピング・プロバイダの構成

使用するセキュリティ・レルムで、SAML資格証明マッピング・プロバイダV2のインスタンスを作成します。SAML資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 1.1用のSAML資格証明マッピング・プロバイダの構成」を参照してください。

SAML資格証明マッピング・プロバイダをSAML認証局として構成するには、「発行者URI」、「名前修飾子」などの属性を設定します。

ソース・サイト・フェデレーション・サービスの構成

SAML 1.1ソース・サイトとしてのWebLogic Serverインスタンスの構成は、FederationServicesMBeanによって制御されます。FederationServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」→「サーバー」→「サーバー名」→「構成」→「フェデレーション・サービス」→「SAML 1.1ソース・サイト」ページ)を使用してアクセスします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1ソース・サービスの構成に関する項を参照してください。

SAMLソース・サイトの属性は以下のように構成します。

- SAMLソース・サイトを有効にします。Source Site Enabled (「ソース・サイトを有効化」)をtrueに設定して、WebLogic ServerインスタンスがSAMLソース・サイトとして動作するようにします。

- ソース・サイトのURLとサービスURIを設定します。SAMLソース・サイトのURLを設定します。これは、サイト間転送サービスおよびアサーション検索サービスをホストするURLです。ソース・サイトURLは、ソースIDとして16進数およびBase64でエンコードされます。ブラウザ/アーティファクト・プロファイルのSAMLアサーティング・パーティを構成するときに、このエンコードされたソースIDを指定します。
サイト間転送サービスおよび(ブラウザ/アーティファクト・プロファイルをサポートするために)アサーション検索サービスのURIを指定します。(また、リライイング・パーティを構成するときには、サイト間転送サービスURIも指定します。)

デフォルトURIのFederationServicesMBean.IntersiteTransferURIsの値は、表7-1に示されています。

表7-1 サイト間転送URI

デフォルトURI値

説明

/samlits_ba/its

BASIC認証、POSTまたはアーティファクト・プロファイル

/samlits_ba/its/post

BASIC認証、POSTプロファイル

/samlits_ba/its/artifact

BASIC認証、アーティファクト・プロファイル

/samlits_cc/its

クライアント証明書認証、POSTまたはアーティファクト・プロファイル

/samlits_cc/its/post

クライアント証明書認証、POSTプロファイル

/samlits_cc/its/artifact

クライアント証明書認証、アーティファクト・プロファイル

サイト間転送URIテキスト・ボックスを使用すると、デフォルト値をそのまま使用するか、または選択内容に応じて値を変更できます。各URIにはアプリケーション・コンテキストが含まれ、後には/its、/its/post、または/its/artifactが続きます。提供されるアプリケーション・コンテキストは、/samlits_ba (BASIC認証)または/samlits_cc (クライアント証明書認証)です。必要に応じて、/yourapplication/itsなどのアプリケーション固有のコンテキストも指定できますが、たいていの場合はデフォルトが最も使いやすい構成オプションです。

これらのURIを/samlits_ba/itsに指定し、リダイレクトが発生してソース・サイト上のユーザー・セッションがタイムアウトした場合、BASIC認証ダイアログが表示されます。かわりにFORMダイアログを使用する場合、URIは、ユーザーを認証して実際のITS URIに転送するカスタムWebアプリケーションを示します。

- 署名用の証明書を追加します。SAMLソース・サイトでは、アサーションの署名に使用する信頼性のある証明書が必要になります。キーストアにこの証明書を追加して、この証明書へのアクセスに使用される資格証明(別名とパスワード)を入力します。署名用の別名とパスワードが指定されていない場合、デフォルトではサーバーのSSL IDキー/証明書が使用されます。

- アサーション検索サービス用のSSLを構成します。FederationServicesMBean.arsRequiresSSLをtrueに設定することで、アサーション検索サービスへのすべてのアクセスでSSLを使用するようにできます。arsRequiresSSLとARSRequiresTwoWaySSLの両方をtrueに設定することで、アサーション検索サービスに対する双方向SSL認証を要求できます。

リライイング・パーティの構成

SAMLリライイング・パーティは、SAMLソース・サイトによって生成されるSAMLアサーションの情報によって変わるエンティティです。WebLogic Serverで各リライイング・パーティに対し別個にSAMLアサーションを生成する方法を構成するか、フェデレーション・サービス・ソース・サイトの構成で設定されたデフォルトを使用してアサーションを生成します。

リライイング・パーティは、管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→資格証明マッパー→「SAMLCredentialMapperName」→「管理」→「リライイング・パーティ」ページで構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1リライイング・パーティの作成に関する項とSAML 1.1リライイング・パーティの構成に関する項を参照してください。

WebLogic Scripting Toolを使用してリライイング・パーティを構成することもできます。「WLSTを使用したリライイング・パーティとアサーティング・パーティの構成」を参照してください。

サポートされるプロファイルの構成

SAMLリライイング・パーティを構成するときに、SAML SSO用としてアーティファクト・プロファイルまたはPOSTプロファイルのサポートを指定できます。かわりに、Webサービス・セキュリティ用としてWSS/Holder-of-KeyプロファイルまたはWSS/Sender-Vouchesプロファイルをサポートするリライイング・パーティを構成することもできます。SAML宛先サイトがサポートするプロファイルのサポートを構成してください。

POSTプロファイルをサポートする場合は、必要に応じて、リライイング・パーティのPOSTプロファイル・アサーションで使用するフォームを作成し、そのパス名を「POSTフォーム」属性に設定します。

アサーション・コンシューマ・パラメータ

各SAMLリライイング・パーティに対して、宛先サイトへのリダイレクト時にACS URLに付加される1つまたは複数の問合せパラメータを任意で構成できます。POSTプロファイルの場合、用時にこデフォルトのPOSTフォームの使れらのパラメータがフォーム変数として組み込まれます。カスタムPOSTフォームの使用中は、パラメータは名前と値のマップとして使用可能になりますが、フォームがPOSTされるデータにパラメータが含まれるように作成される場合と、そうでない場合があります。

別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、リライイング・パーティACSパラメータのSAMLアサーティング・パーティのID (APID)を設定します。

ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。つまり、ACSはアサーティング・パーティID (APID)をリクエスト受信時のパラメータとして検索し、これを使用して他の処理を実行する前に構成を参照します。

また、APIDパラメータを使用すると、ブラウザSSOのターゲットURLパラメータを指定する必要がなくなります。ターゲットURLはWebサービスの構成に使用されます。

デフォルトのアサーション・ストアの置換え

WebLogic Serverでは、単純なアサーション・ストアを使用して、生成されるアサーションの永続性を保持します。このアサーション・ストアを、weblogic.security.providers.saml.AssertionStoreV2を実装するカスタム・アサーション・ストア・クラスに置き換えることができます。FederationServicesMBean.AssertionStoreClassName属性を使用して、デフォルトのクラスではなく、カスタム・アサーション・ストア・クラスを使用するようにWebLogic Serverを構成します。FederationServicesMBean.AssertionStoreProperties属性を使用して、カスタム・アサーション・ストア・クラスのinitStore()メソッドに渡されるプロパティを構成できます。これらの属性は、管理コンソールの「環境: サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1ソース・サイト」ページで構成します。

シングル・サインオン用のSAML 1.1宛先サイトの構成

以下の節では、WebLogic ServerをSAML宛先サイトとして構成する方法について説明します。

- SAML IDアサーション・プロバイダの構成

- 宛先サイト・フェデレーション・サービスの構成

- アサーティング・パーティの構成

SAML IDアサーション・プロバイダの構成

使用するセキュリティ・レルムで、SAML IDアサーション・プロバイダV2のインスタンスを作成し、構成します。SAML IDアサーション・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 1.1用のSAML IDアサーション・プロバイダの構成」を参照してください。

宛先サイト・フェデレーション・サービスの構成

WebLogicをSAML宛先サイトとして構成する前に、まず使用するセキュリティ・レルムで、SAML IDアサーション・プロバイダV2のインスタンスを作成する必要があります。SAML宛先サイトとしてのWebLogic Serverインスタンスの構成はFederationServicesMBeanによって制御されます。FederationServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境: サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1宛先サイト」ページ)を使用してアクセスします。

SAML宛先サイトの属性は以下のように構成します。

SAML宛先サイトの有効化

「宛先サイトを有効化」をtrueに設定して、WebLogic ServerインスタンスがSAML宛先サイトとして動作するようにします。

アサーション・コンシューマURIの設定

SAMLアサーション・コンシューマ・サービスのURIを設定します。ソース・サイトからアサーションを受信するURLです。これにより、宛先サイトはアサーションを使用してユーザーを認証できます。アサーション・コンシューマURIは、リライイング・パーティの構成でも指定されます。

アサーション・コンシューマ・サービス用のSSLの構成

FederationServicesMBean.acsRequiresSSLをtrueに設定することで、アサーション・コンシューマ・サービスへのすべてのアクセスでSSLを使用するように設定できます。

SSLクライアントID証明書の追加

SSLクライアントIDは、アーティファクト・プロファイルのソース・サイトでARSにアクセスするために使用します。キーストアにこの証明書を追加して、この証明書へのアクセスに使用される資格証明(別名とパスワード)を入力します。

使い捨てポリシーと使用済アサーション・キャッシュまたは
カスタム・アサーション・キャッシュの構成

必要に応じて、各POSTプロファイル・アサーションの使用を1回のみに設定できます。アサーションの使い捨てポリシーをサポートできるように、WebLogic Serverには使用済みのアサーションのキャッシュが保持されています。このアサーション・キャッシュを、weblogic.security.providers.saml.SAMLUsedAssertionCacheを実装するカスタム・アサーション・キャッシュ・クラスに置き換えられます。FederationServicesMBean.SAMLUsedAssertionCache属性を使用して、デフォルトのクラスではなく、カスタム・アサーション・キャッシュ・クラスを使用するようにWebLogic Serverを構成します。FederationServicesMBean.UsedAssertionCacheProperties属性を使用して、カスタム・アサーション・キャッシュ・クラスのinitCache()メソッドに渡されるプロパティを構成できます。これらの属性は、管理コンソールの「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1宛先サイト」ページで構成できます。

POSTプロファイルに対する受信者チェックの構成

必要に応じて、SAMLレスポンスの受信者はHTTPリクエスト内のURLに一致しなければならないように設定できます。これを行うには、「POST受信者チェックを有効化」属性を設定します。

アサーティング・パーティの構成

SAMLアサーティング・パーティとは、信頼できるSAMLオーソリティです(SAMLアサーションの形式でセキュリティ情報を厳格にアサートできるエンティティ)。

アサーティング・パーティは、管理コンソールの「セキュリティ・レルム」>RealmName>「プロバイダ」>「認証」>SAMLIdentityAsserterV2>「管理: アサーティング・パーティ」ページで構成します。Oracle WebLogic Server管理コンソール・ヘルプのSAML 1.1アサーティング・パーティの作成に関する項およびSAML 1.1アサーティング・パーティの構成に関する項を参照してください。

WebLogic Scripting Toolを使用してアサーティング・パーティを構成することもできます。「WLSTを使用したリライイング・パーティとアサーティング・パーティの構成」を参照してください。

サポートされるプロファイルの構成

SAMLアサーティング・パーティを構成するときに、SAML SSO用としてアーティファクト・プロファイルまたはPOSTプロファイルのサポートを指定できます。かわりに、Webサービス・セキュリティ用としてWSS/Holder-of-KeyプロファイルまたはWSS/Sender-Vouchesプロファイルをサポートするアサーティング・パーティを構成することもできます。

ソース・サイトITSパラメータの構成

各SAMLアサーティング・パーティでは、ソース・サイトにリダイレクトするときに追加されるゼロ以上のオプション問合せパラメータを構成します。

別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、アサーティング・パーティITSパラメータのSAMLリライイング・パーティのID (RPID)を設定する必要があります。

ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。つまり、ITSはRPIDをリクエスト受信時のパラメータとして検索し、これを使用して他の処理を実行する前に構成を参照します。

また、RPIDパラメータを使用すると、WebLogic Server対WebLogic ServerブラウザSSO構成専用にターゲットURLパラメータを指定する必要がなくなります。ターゲットURLはWebサービスの構成に使用されます。

WLSTを使用したリライイング・パーティとアサーティング・パーティの構成

SAMLパートナ(リライイング・パーティとアサーティング・パーティ)はレジストリに保持されます。WebLogic管理コンソールまたはWebLogic Scripting Toolを使用してSAMLパートナを構成できます。次の例では、WLSTをオンライン・モードで使用して2つのリライイング・パーティを構成する方法を示します。

この例では、リライイング・パーティのアサーション・コンシューマ・サービスのパラメータにSAMLアサーティング・パーティのID (APID)を設定しています。別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、リライイング・パーティACSパラメータのSAMLアサーティング・パーティのID (APID)を設定する必要があります。(アサーティング・パーティITSパラメータにSAMLリライイング・パーティのID (RPID)も設定します。)

APIDは、WebLogic Server対WebLogic ServerブラウザSSO構成にのみ必要になります。ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。

例7-1 WLSTを使用したリライイング・パーティの作成

connect('weblogic','weblogic','t3://localhost:7001')
rlm=cmo.getSecurityConfiguration().getDefaultRealm()
cm=rlm.lookupCredentialMapper('samlv2cm')

rp=cm.newRelyingParty()
rp.setDescription('test post profile')
rp.setProfile('Browser/POST')
rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')
rp.setAssertionConsumerParams(array(['APID=ap_00001'],String))
rp.setSignedAssertions(true)
rp.setEnabled(true)
cm.addRelyingParty(rp)

rp=cm.newRelyingParty()
rp.setDescription('test artifact profile')
rp.setProfile('Browser/Artifact')
rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')
rp.setAssertionConsumerParams(array(['APID=ap_00002'],String))
rp.setARSUsername('foo')
rp.setARSPassword('bar')
rp.setSSLClientCertAlias('demoidentity')
rp.setEnabled(true)
cm.addRelyingParty(rp)

disconnect()
exit()

次の例では、既存のアサーティング・パーティを編集する方法を示します。この例では、アサーティング・パーティIDを使用してアサーティング・パーティを取得し、アサーション検索URLを設定しています。

例7-2 WLSTを使用したアサーティング・パーティの編集

connect('weblogic','weblogic','t3://localhost:7001')
rlm=cmo.getSecurityConfiguration().getDefaultRealm()
ia=rlm.lookupAuthenticationProvider('samlv2ia')
ap=ia.getAssertingParty('ap_00002')
ap.setAssertionRetrievalURL('https://hostname:7002/samlars/ars')
ia.updateAssertingParty(ap)
disconnect()
exit()

SAML 2.0サービスの構成

このトピックには次のセクションが含まれます:

- SAML 2.0サービスの構成: 主な手順

- SAML 2.0全般サービスの構成

- SAML 2.0シングル・サインオン用のIDプロバイダ・サイトの構成

- SAML 2.0シングル・サインオン用のサービス・プロバイダ・サイトの構成

- パートナ・サイト、証明書、サービス・エンドポイント情報の表示

- SAML 2.0におけるWebアプリケーション・デプロイメントの考慮事項

SAML 2.0サービスの構成: 主な手順

ここでは、SAML 2.0サービスを構成する主な手順を示します。

1. SAML 2.0サービスを、ドメイン内の複数のWebLogic Serverインスタンスで実行する可能性があるかどうかを検討します。その可能性がある場合は、次の手順に従います。

1. RDBMSセキュリティ・ストアを構成するドメインを作成します。
本番環境のSAML 2.0セキュリティ・プロバイダは、RDBMSセキュリティ・ストアを必要とします。これは、それらが管理するデータを、データを共有するすべてのWebLogic Serverインスタンスの間で同期できるようにするためです。

なお、RDBMSセキュリティ・ストアを使用するドメインを作成するかわりに、既存のドメインをアップグレードすることはお薦めできません。RDBMSセキュリティ・ストアを使用する場合は、ドメインの作成時にRDBMSセキュリティ・ストアを構成する必要があります。RDBMSセキュリティ・ストアを使用したいドメインが作成済みである場合は、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。

詳細は、第10章「RDBMSセキュリティ・ストアの管理」を参照してください。

2. すべてのSAML 2.0サービスが、各WebLogic Serverインスタンスでまったく同じように構成されていることを確認します。SAML 2.0サービスをクラスタ内で構成する場合は、クラスタ内の各管理対象サーバーを個別に構成する必要があります。

3. 「SAML 2.0におけるWebアプリケーション・デプロイメントの考慮事項」に説明されている内容を確認してください。

2. SAML 2.0 IDプロバイダ・サイトを構成する場合は、次の手順に従います。

1. セキュリティ・レルムで、SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成して構成します。

2. SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0全般サービスをまったく同じように構成します。

3. SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0 IDプロバイダ・サービスをまったく同じように構成します。

4. サイトについて記述したメタデータ・ファイルを公開し、サービス・プロバイダ・パートナに手動で配布します。

5. サービス・プロバイダ・パートナを作成して構成します。

3. SAML 2.0サービス・プロバイダ・サイトを構成する場合は、次の手順に従います。

1. セキュリティ・レルムで、SAML 2.0 IDアサーション・プロバイダのインスタンスを作成して構成します。
仮想ユーザーがSAMLでログインすることを許可している場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。詳細は、「SAML認証プロバイダの構成」を参照してください。

2. SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0全般サービスをまったく同じように構成します。

3. SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0サービス・プロバイダ・サービスをまったく同じように構成します。

4. サイトについて記述したメタデータ・ファイルを公開し、IDプロバイダ・パートナに手動で配布します。

5. IDプロバイダ・パートナを作成して構成します。

これ以降の節では、これらの手順について詳しく説明します。

SAML 2.0全般サービスの構成

SAML 2.0全般サービスは、WebLogic Serverインスタンスに構成するSAML 2.0の用途に関わらず(つまり、サービス・プロバイダまたはIDプロバイダのどちらとして使用する場合でも)構成する必要があります。WebLogic ServerインスタンスのSAML 2.0全般サービスの構成は、SingleSignOnServicesMBeanで制御します。SingleSignOnServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 2.0全般」ページ)を使用してアクセスします。

注意:
SAML 2.0全般サービスを構成するには、その前にSAML 2.0 IDアサーション・プロバイダまたはSAML 2.0資格証明マッピング・プロバイダを構成し、サーバー・インスタンスを再起動する必要があります。

以下の節では、SAML 2.0全般サービスについて説明します。

- SAML 2.0全般サービスについて

- メタデータ・ファイルの公開と配布

SAML 2.0全般サービスについて

SAML 2.0全般サービスとしては、以下のような項目を構成します。

- レプリケーションされたキャッシュを有効にするかどうか。
クラスタを構成する場合のように、ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを構成する場合には、レプリケーションされたキャッシュを有効にする必要があります。レプリケーションされたキャッシュを使用すると、SAML 2.0セキュリティ・プロバイダ(SAML 2.0 IDアサーション・プロバイダとSAML 2.0資格証明マッピング・プロバイダのどちらか、または両方)で管理しているデータを、サーバー・インスタンス間で共有して同期させることができます。

本番環境のSAML 2.0セキュリティ・プロバイダは、RDBMSセキュリティ・ストアを必要とします。これは、それらが管理するデータを、データを共有するすべてのWebLogic Serverインスタンスの間で同期できるようにするためです。(開発環境のみの場合は、SAML 2.0セキュリティ・プロバイダでセキュリティ・ストアとしてLDAPを使用します)。

その場合は、SAML 2.0サービスを構成する前に、RDBMSセキュリティ・ストアを使用するように構成されたドメインを作成する必要があります。詳細は、第10章「RDBMSセキュリティ・ストアの管理」を参照してください。

- ローカル・サイトに関する情報。
サイト情報は、主にSAMLフェデレーション内のビジネス・パートナに提供して共有するためのものです。サイト情報には、ローカル・サイトの担当者の連絡先、組織名、組織のURLなどが含まれます。

- 公開サイトのURL。
公開サイトのURLには、様々なSAML 2.0サービスのエンドポイントURLを構築するために使用するベースURLを指定します。このURLにはサーバーを外部から認識できるホスト名とポートを指定する必要がありますが、これらはローカルでサーバーにアクセスする場合に使用するホスト名やポートとは異なる可能性があります。たとえば、SAML 2.0サービスをクラスタ内で構成する場合のホスト名とポートは、クラスタ内の管理対象サーバーにクライアント・リクエストを配信するロード・バランサまたはプロキシ・サーバーに相当します。

公開サイトのURLには、/saml2を付加する必要があります。例:

https://www.avitek.com:7001/avitek-domain/aviserver/saml2

- エンティティID。
エンティティIDは人間が読取れる形式の文字列で、サイトをフェデレーション内の他のパートナ・サイトと区別するために使用します。SAML 2.0サービスでは、パートナがアサーションを生成または消費する必要がある場合に、そのアサーションに対応するパートナを特定するプロセスにおいてこのエンティティIDを使用します。

- 受信者チェックを有効にするかどうか。
有効にした場合、認証のリクエストやレスポンスの受信者は、HTTPリクエスト内のURLに一致しなければなりません。

- アーティファクト解決サービスでの呼出しにTLS/SSLクライアント認証を必要とするかどうか。有効にした場合、パートナへの送信時にSAMLアーティファクトが暗号化されます。

- トランスポート層セキュリティ・キーストアの別名とパスワード。これらの値は、パートナに対する送信の保護に使用します。

- パートナがローカル・サイトのHTTPSバインディングを呼び出す際に、基本認証クライアントの認証を必要とするかどうか。
この設定を有効にした場合、クライアントのユーザー名とパスワードも指定する必要があります。これらの資格証明は、公開するメタデータ・ファイルに格納され、これをフェデレーション・パートナと共有することになります。

- パートナから受け取るSAMLアーティファクトのリクエストに署名を必要とするかどうか。

- SAMLアーティファクト・キャッシュの構成設定。

- フェデレーション・パートナに送信するドキュメント(認証のリクエストやレスポンス)に署名する際のキーが格納されているキーストアの別名とパスワード。

SAML 2.0全般サービスの構成の手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0の全般サービスの構成に関する項を参照してください。

メタデータ・ファイルの公開と配布

フェデレーション・パートナが必要とするローカル・サイト情報(ローカル・サイトの連絡先情報、エンティティID、公開サイトのURL、TLS/SSLクライアント認証が必要かどうかなど)は、管理コンソールの「SAML 2.0全般」ページで「メタデータの公開」をクリックすることでメタデータ・ファイルとして公開できます。

メタデータ・ファイルを公開する際には、ローカル・マシンの既存のディレクトリ(ファイルの作成が可能なディレクトリ)を指定します。WebLogic Serverには、メタデータ・ファイルをフェデレーション・パートナに配布する手段は実装されていません。ただし、暗号化された電子メール、セキュアFTPなど、電子的なドキュメントを安全に転送できる一般的な方法で配布して構いません。

メタデータ・ファイルに関しては、以下の点に留意してください。

- メタデータ・ファイルを公開する前に、ドメイン内のWebLogic Serverインスタンスが果たすSAML 2.0機能として、IDプロバイダ・サービスやサービス・プロバイダ・サービスを構成する必要があります。
メタデータ・ファイルには、フェデレーション・パートナが必要とするこれらのSAML 2.0サービスの構成データが含まれています。パートナはこれらのデータを使用することで、署名用証明書のインポート、サイトのSAML 2.0サービス・エンドポイントの特定、サイトのサービスに接続するための適切なバインディング・タイプの選択など、様々な処理にかかる手間を大幅に省くことができます。

- サイトが一部のパートナに対してサービス・プロバイダとして機能し、残りのパートナに対してはIDプロバイダとして機能する場合も、フェデレーション・パートナと共有しているメタデータ・ファイルのバージョンを1つに限定する必要があります。メタデータ・ファイルのバージョンを1つに限定することで、パートナの構成設定との互換性がなくなる事態を避けることができます。

- ローカル・サイトのSAML 2.0構成を変更する場合は、メタデータ・ファイルを更新する必要があります。メタデータ・ファイルはパートナと共有しているため、SAML 2.0構成を変更する頻度を最小限に抑えることで、変更に伴いパートナがレジストリを更新する頻度も抑えることができます。

- フェデレーション・パートナからメタデータ・ファイルを受け取った場合は、SAML 2.0サービスが構成されているドメイン内のすべてのノードからアクセスできる場所に格納します。パートナの作成時には、パートナのメタデータ・ファイルの内容をパートナ・レジストリに反映します。

メタデータ・ファイルは、com.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して操作できます。

SAML 2.0シングル・サインオン用のIDプロバイダ・サイトの構成

この節では、以下の内容について説明します。

- SAML 2.0資格証明マッピング・プロバイダの構成

- SAML 2.0 IDプロバイダ・サービスの構成

- Webシングル・サインオン・サービス・プロバイダ・パートナの作成と構成

SAML 2.0資格証明マッピング・プロバイダの構成

使用するセキュリティ・レルムで、SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成します。SAML 2.0資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 2.0用のSAML 2.0資格証明マッピング・プロバイダの構成」を参照してください。

SAML 2.0資格証明マッピング・プロバイダは、SAML認証局として構成します。以下のような属性を指定します。

- 発行者URI

- 名前修飾子

- 生成するSAML 2.0アサーションの有効期間属性

- 名前マッパー・クラス名

- アサーションに格納するIDが属すグループを特定するための属性情報をアサーションに含めるかどうか

SAML 2.0資格証明マッピング・プロバイダを構成したら、「SAML 2.0全般サービスの構成」に従ってSAML 2.0全般サービスを構成します。

SAML 2.0 IDプロバイダ・サービスの構成

SAML 2.0 IDプロバイダ・サイトとしてのWebLogic Serverインスタンスの構成は、SingleSignOnServicesMBeanによって制御されます。SingleSignOnServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 2.0 IDプロバイダ」ページ)を使用してアクセスします。

次の項では、この構成タスクについて簡単に説明します。構成の詳しい手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 IDプロバイダ・サービスの構成に関する項を参照してください。

SAML 2.0 IDプロバイダ・サイトの有効化

管理コンソールの「SAML 2.0 IDプロバイダ」ページで「有効」属性をtrueに設定すると、WebLogic ServerインスタンスをIDプロバイダ・サイトとして機能させることができます。

カスタム・ログインWebアプリケーションの指定

必要に応じ、カスタム・ログインWebアプリケーションを使用してIDプロバイダ・サイトのユーザーを認証できます。カスタム・ログインWebアプリケーションを構成するには、「ログインのカスタマイズ」属性を有効にし、WebアプリケーションのURLを指定します。

バインディング・タイプの有効化

IDプロバイダ・サービスのエンドポイントで使用できるすべてのバインディング・タイプ(POST、リダイレクト、およびアーティファクト)を有効にすることをお薦めします。必要に応じて、優先するバインディング・タイプを選択することもできます。

サイトのメタデータ・ファイルの公開

SAML 2.0全般サービスとIDプロバイダ・サービスを構成したら、サイトのメタデータ・ファイルを公開してフェデレーション・パートナに配布します。詳細は、「メタデータ・ファイルの公開と配布」を参照してください。

Webシングル・サインオン・サービス・プロバイダ・パートナの作成と構成

SAML 2.0サービス・プロバイダ・パートナは、IDプロバイダ・サイトによって生成されたSAML 2.0アサーションを消費するエンティティです。サービス・プロバイダ・パートナは、管理コンソールの「セキュリティ・レルム」>「RealmName」>「プロバイダ」>「資格証明マッパー」>「SAML2CredentialMapperName」>「管理」ページで構成します。

このコンソール・ページで設定できる属性には、以降の各節で示すJavaインタフェースを使用してプログラム的にアクセスできます。

サービス・プロバイダ・パートナを構成する詳しい手順については、Oracle WebLogic Server管理コンソール・ヘルプのSAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成に関する項を参照してください。Webシングル・サインオン・パートナを構成する際に利用できるサイト情報、署名用証明書、サービス・エンドポイント情報については、「パートナ・サイト、証明書、サービス・エンドポイント情報の表示」を参照してください。

サービス・プロバイダ・パートナのメタデータ・ファイルの取得

Webシングル・サインオン用のサービス・プロバイダ・パートナを構成する前に、暗号化された電子メール、セキュアFTPなど、信頼性の高い安全な方法で、パートナのSAML 2.0メタデータ・ファイルを取得する必要があります。パートナのSAML 2.0メタデータ・ファイルには、パートナ・サイトおよびバインディング・サポートについて記述されており、パートナの証明書やキー、SAML 2.0サービス・エンドポイントなど、様々な情報が含まれています。パートナのメタデータ・ファイルは、SAML 2.0用に構成されているドメイン内の各ノードからアクセスできる場所に格納します。

SAML 2.0メタデータ・ファイルの詳細は、「メタデータ・ファイルの公開と配布」を参照してください。

パートナの作成と対話の有効化

Webシングル・サインオン用のサービス・プロバイダ・パートナを作成して構成するには:

1. 「SAML 2.0資格証明マッピング・プロバイダ」ページの「管理」タブで、パートナの名前とメタデータ・ファイルを指定します。

2. パートナ構成ページの「全般」タブで、パートナとWebLogic Serverインスタンスの間の対話を有効にします。

WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して構成できます。

アサーションの生成方法の構成

パートナ構成ページの「全般」タブでは、このサービス・プロバイダ・パートナのためだけに生成するSAML 2.0アサーションの以下の属性も、必要に応じて構成できます。

- サービス・プロバイダの名前マッパー・クラス名
このセキュリティ・レルム内に構成されているSAML 2.0資格証明マッピング・プロバイダのデフォルトのユーザー名マッパー・クラスをオーバーライドするJavaクラスです。

- 存続時間属性
存続時間属性には、このパートナ用に生成されたアサーションが有効な期間を指定します。これらの属性を指定することで、期限切れのアサーションが使用されるのを防ぐことができます。

- アサーションに含める属性情報を生成するかどうか
有効にすると、対応するユーザーが属すグループが、SAML 2.0資格証明マッピング・プロバイダによってアサーションの属性として追加されます。

- このパートナに送信するアサーションを使用後直ちに破棄する必要があるかどうか

- このパートナ用に生成するアサーションにこのサーバーの署名用証明書を含めるかどうか

WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.SPPartner Javaインタフェースを使用して構成できます。

ドキュメントの署名方法の構成

サービス・プロバイダ・パートナの構成ページの「全般」タブでは、このパートナと交換する以下のドキュメントの署名方法を指定できます。

- アサーション
この属性は、com.bea.security.saml2.providers.registry.SPPartnerインタフェースを使用して操作できます。

- 認証リクエスト
この属性は、com.bea.security.saml2.providers.registry.WebSSOSPPartnerインタフェースを使用して操作できます。

- アーティファクト・リクエスト
この属性は、com.bea.security.saml2.providers.registry.WebSSOPartnerインタフェースを使用して操作できます。

このパートナが署名付きアサーションしか受け付けないかどうかを指定する属性と、認証リクエストに署名する必要があるかどうかを指定する属性は読取り専用で、パートナのメタデータ・ファイルから抽出されます。

アーティファクトのバインディングおよびトランスポート設定の構成

サービス・プロバイダ・パートナの構成ページの「全般」タブでは、必要に応じて以下を構成することもできます。

- SAMLアーティファクトをこのサービス・プロバイダ・パートナにHTTP POSTバインディングで配信するかどうか。配信する場合は、SAMLアーティファクトを送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURIも指定します。

- リクエストやレスポンス・メッセージをPOSTバインディングで送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURI。

これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。

このパートナとのドキュメントの交換をより安全に行うため、サービス・プロバイダ・パートナがローカル・サイトのバインディングに接続する際の基本認証で使用するクライアントのユーザー名とパスワードを指定することもできます。この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースで利用できます。

SAML 2.0シングル・サインオン用のサービス・プロバイダ・サイトの構成

この節では、以下の内容について説明します。

- SAML 2.0 IDアサーション・プロバイダの構成

- SAML認証プロバイダの構成

- SAML 2.0全般サービスの構成

- SAML 2.0サービス・プロバイダ・サービスの構成

- Webシングル・サインオンIDプロバイダ・パートナの作成と構成

注意:
Cookieパスを使用します。
「session-descriptor」で説明しているように、Cookieパス要素によりセッション追跡Cookieパスが定義されます。この要素を設定しない場合、デフォルトは「/」(スラッシュ)です。デフォルト値では、WebLogic Serverで指定されているすべてのURLにブラウザがCookieを送信します。

WebLogic ServerのSAML 2.0サービス・プロバイダではCookieパスは「/」(スラッシュ)にする必要があります。Cookieパスでこれ以外の値を設定すると、SSOではSAML 2.0サービス・プロバイダで失敗します。

SAML 2.0 IDアサーション・プロバイダの構成

セキュリティ・レルムで、SAML 2.0 IDアサーション・プロバイダのインスタンスを作成します。SAML 2.0 IDアサーション・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。SAML 2.0 IDアサーション・プロバイダでは、以下のような属性を指定します。

- レプリケーションされたキャッシュを有効にするかどうか
SAML 2.0 IDプロバイダ・サービスをドメイン内の複数のサーバー・インスタンスに構成する場合は、この属性を有効にする必要があります。

- SAML 2.0アサーションのデフォルトの名前マッパー・クラスをオーバーライドするカスタム名前マッパー

このセキュリティ・プロバイダの詳細は、「SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成」を参照してください。

SAML認証プロバイダの構成

仮想ユーザーを有効にする予定がある場合や、IDプロバイダ・パートナから受け取るアサーションに含まれる属性文を消費する予定がある場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。詳細は、「SAML認証プロバイダの構成」を参照してください。

SAML 2.0全般サービスの構成

SAML 2.0 IDアサーション・プロバイダを構成し、必要に応じてSAML認証プロバイダを構成したら、「SAML 2.0全般サービスの構成」に従ってSAML 2.0全般サービスを構成します。

SAML 2.0サービス・プロバイダ・サービスの構成

SAML 2.0サービス・プロバイダ・サイトとしてのWebLogic Serverインスタンスの構成は、SingleSignOnServicesMBeanによって制御されます。SingleSignOnServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 2.0サービス・プロバイダ」ページ)を使用してアクセスします。

次の項では、SAML 2.0サービス・プロバイダ・サイトの属性の構成について簡単に説明します。これらの構成の詳しい手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0サービス・プロバイダ・サービスの構成に関する項を参照してください。

SAML 2.0サービス・プロバイダ・サイトの有効化

管理コンソールの「フェデレーション・サービス: SAML 2.0サービス・プロバイダ」ページで「有効」属性をtrueに設定すると、WebLogic Serverインスタンスをサービス・プロバイダ・サイトとして機能させることができます。

ドキュメントの署名方法の指定

ドキュメントに署名が必要かどうか設定するため、必要に応じて以下の属性を有効にします。

- IDプロバイダ・パートナに送る認証リクエストに署名が必要かどうか

- IDプロバイダ・パートナから受け取るアサーションに署名が必要かどうか

認証リクエストの管理方法の指定

必要に応じて、認証リクエスト・キャッシュの以下の属性を有効にします。

- 最大キャッシュ・サイズ。

- 認証リクエストのタイムアウト値。この値を指定することで、格納された認証リクエストが期限切れになるまでの期間を設定できます。

バインディング・タイプの有効化

サービス・プロバイダ・サービスのエンドポイントで使用できるすべてのバインディング・タイプ(POSTおよびアーティファクト)を有効にすることをお薦めします。必要に応じて、優先するバインディング・タイプを指定することもできます。

デフォルトURLの設定

必要に応じて、要求していない認証レスポンスにターゲットURLが含まれていなかった場合に、その認証レスポンスを送信するデフォルトのURLを指定します。

Webシングル・サインオンIDプロバイダ・パートナの作成と構成

SAML 2.0 IDプロバイダ・パートナは、サービス・プロバイダ・サイトによって消費されるSAML 2.0アサーションを生成するエンティティです。IDプロバイダ・パートナは、管理コンソールの「セキュリティ・レルム」>「RealmName」>「プロバイダ」>「認証」>「SAML2IdentityAsserterName」>「管理」ページで構成します。

このコンソール・ページで設定できる属性には、以降の各節で示すJavaインタフェースを使用してプログラム的にアクセスできます。

サービス・プロバイダ・パートナを構成する詳しい手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオンIDプロバイダ・パートナの作成に関する項を参照してください。

Webシングル・サインオン・パートナを構成する際に利用できるサイト情報、署名用証明書、サービス・エンドポイント情報については、「パートナ・サイト、証明書、サービス・エンドポイント情報の表示」を参照してください。

以降の節では、IDプロバイダ・パートナの構成タスクについて簡単に説明します。

IDプロバイダ・パートナのメタデータ・ファイルの取得

Webシングル・サインオン用のIDプロバイダ・パートナを構成する前に、暗号化された電子メール、セキュアFTPなど、信頼性の高い安全な方法で、パートナのSAML 2.0メタデータ・ファイルを取得する必要があります。パートナのメタデータ・ファイルには、パートナ・サイトおよびバインディング・サポートについて記述されており、パートナの証明書やキーをはじめ、様々な情報が含まれています。パートナのメタデータ・ファイルは、SAML 2.0用に構成されているドメイン内の各ノードからアクセスできる場所に格納します。

SAML 2.0メタデータ・ファイルの詳細は、「メタデータ・ファイルの公開と配布」を参照してください。

パートナの作成と対話の有効化

IDプロバイダ・パートナを作成し、Webシングル・サインオンのための対話を有効にするには:

- 「SAML 2.0 IDアサーション・プロバイダ」ページの「管理」タブで、パートナの名前とメタデータ・ファイルを指定します。

- パートナ構成ページの「全般」タブで、パートナとWebLogic Serverインスタンスの間の対話を有効にします。

WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して構成できます。

認証リクエストおよびアサーションの構成

必要に応じて、このIDプロバイダ・パートナの以下の属性を構成します。このパートナ用に生成される認証リクエストの属性と、このパートナから受け取るアサーションの属性があります。

- IDプロバイダの名前マッパー・クラス名。
このセキュリティ・レルム内に構成されているSAML 2.0 IDアサーション・プロバイダのデフォルトのユーザー名マッパー・クラスをオーバーライドするカスタムJavaクラスです。指定したカスタム・クラスは、このパートナから受け取るアサーションに含まれるIDにのみ使用されます。

この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。

- このパートナから受け取るアサーションに含まれているIDを、セキュリティ・レルム内の仮想ユーザーにマップするかどうか。

注意:
この属性を使用するには、レルムにSAML認証プロバイダを構成する必要があります。

この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。

- このパートナから受け取るアサーションに含まれている属性情報を消費するかどうか。
この属性を有効にすると、SAML 2.0 IDアサーション・プロバイダによってアサーションから属性情報が抽出されます。この情報は、SAML認証プロバイダ(セキュリティ・レルムに構成されていなければなりません)との連携によって、対応するユーザーが属すセキュリティ・レルム内のグループを特定するために使用します。

この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。

- このIDプロバイダ・パートナに送る認証リクエストに署名が必要かどうか。これは、パートナのメタデータ・ファイルから抽出される読取り専用の属性です。
この属性は、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して操作できます。

- このIDプロバイダ・パートナから受け取るSAMLアーティファクト・リクエストに署名が必要かどうか。
この属性は、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して操作できます。

リダイレクトURIの構成

未認証のユーザーによって呼び出された場合に、そのユーザーを認証できるIDプロバイダ・パートナにユーザー・リクエストをリダイレクトするURIのセットを指定できます。

注意:
1つまたは複数のリダイレクトURIを構成する場合は、それらにもセキュリティ・ポリシーを設定するようにしてください。設定しないとWebコンテナによるユーザーの認証が行われないため、ユーザーのリクエストがIDプロバイダ・パートナにリダイレクトされません。

WebLogic Serverでは、この属性をcom.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して構成できます。

バインディングおよびトランスポート設定の構成

サービス・プロバイダ・パートナの構成ページの「全般」タブでは、必要に応じて以下を構成することもできます。

- SAMLアーティファクトをこのサービス・プロバイダ・パートナにHTTP POSTメソッドで配信するかどうか。配信する場合は、SAMLアーティファクトを送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURIも指定します。

- このIDプロバイダ・パートナにPOSTバインディングのSAMLレスポンスを伝送するためのPOST形式を生成するカスタムWebアプリケーションのURL。

- このIDプロバイダ・パートナにアーティファクト・バインディングのSAMLレスポンスを伝送するためのPOST形式を生成するカスタムWebアプリケーションのURL。

これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。

このパートナとのドキュメントの交換をより安全に行うため、IDプロバイダ・パートナがローカル・サイトのバインディングに接続する際の基本認証で使用するクライアントのユーザー名とパスワードを指定することもできます。この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースで利用できます。

パートナ・サイト、証明書、サービス・エンドポイント情報の表示

SAML 2.0パートナの構成に使用する管理コンソールのパートナ構成ページには、パートナに関する以下の追加情報を表示および構成するためのタブが含まれています。

- 「サイト」タブには、サービス・プロバイダ・パートナに関する情報が表示されます。これは、パートナのメタデータ・ファイルから抽出されたものです。このタブのデータは読取り専用です。
WebLogic Serverでは、パートナ・サイト情報用にcom.bea.security.saml2.providers.registry.MetadataPartner Javaインタフェースが提供されています。

- 「シングル・サインオン署名用証明書」タブには、サービス・プロバイダ・パートナの署名用証明書の詳細が表示されます。これもまた、パートナのメタデータ・ファイルから抽出されたものです。このタブのデータは読取り専用です。
これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。

- 「トランスポート層クライアント証明書」タブには、パートナのトランスポート層クライアント証明書が表示されます。この証明書は、必要に応じて「ファイルからの証明書のインポート」をクリックしてインポートできます。
この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースを使用して操作できます。

- サービス・プロバイダ・パートナを構成するときには、「アサーション・コンシューマ・サービス・エンドポイント」タブにサービス・プロバイダ・パートナのACSエンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOSPPartner Javaインタフェースでも利用できます。

- サービス・プロバイダ・パートナを構成するときには、「シングル・サインオン・サービス・エンドポイント」タブにIDプロバイダ・パートナのシングル・サインオン・サービス・エンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースでも利用できます。

- 「アーティファクト解決サービス・エンドポイント」タブには、パートナのARSエンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースでも利用できます。

SAML 2.0におけるWebアプリケーション・デプロイメントの考慮事項

クラスタ環境においてSAMLベースのSSOのためのWebアプリケーションをデプロイする際は、SAMLベースのシングル・サインオンが失敗することのないよう、以下の事項を考慮に入れてください。

- デプロイメント記述子に関する推奨事項

- クラスタ環境におけるログイン・アプリケーションの考慮事項

- 強制認証とパッシブ属性の有効化による無効な構成

デプロイメント記述子に関する推奨事項

デプロイメント記述子ファイルで以下の要素を使用する場合は、下記の推奨事項を検討してください。

- relogin-enabled

- cookie-name

CLIENT-CERT認証でのrelogin-enabledの使用

Webアプリケーションにログインしたユーザーが認可されていないリソースにアクセスしようとすると、HTTP FORBIDDEN (403)レスポンスが生成されます。これは、Webアプリケーションの標準的な動作です。しかしWebLogic Serverでは、以前のリリースとの後方互換性を確保するため、weblogic.xmlデプロイメント記述子ファイルのrelogin-enabled要素を使用して、アクセス失敗のレスポンスが生成されると認証がリクエストされるようになっています。状況によっては、これが原因でSAML 2.0ベースのWebシングル・サインオンが失敗する可能性があります。

通常、SAML 2.0アサーション・コンシューマ・サービス(ACS)は、ユーザーをアプリケーションにログインさせた後、ユーザー・リクエストをターゲットWebアプリケーションにリダイレクトします。しかし、そのWebアプリケーションでSAML 2.0シングル・サインオンが有効になっていてCLIENT-CERT認証で保護されている場合に、relogin-enabledデプロイメント記述子要素がtrueに設定されていると、ユーザーの認証リクエストが繰返し発行されて無限ループが発生するおそれがあります。ユーザーがWebアプリケーションにログインした後に認可されていないリソースにアクセスしようとすると、FORBIDDENメッセージが生成されずに新しい認証リクエストが生成されるため、別のSAML 2.0ベースのWebシングル・サインオンが試行されてループが発生します。

CLIENT-CERT認証で保護されているWebアプリケーションでこのような状況が発生するのを回避するには、Webアプリケーションのrelogin-enabledデプロイメント記述子要素を削除するかfalseに設定します。これにより、Webアプリケーションの標準的な認証動作になります。

デフォルト以外のCookie名の使用

アサーション・コンシューマ・サービスがアサーションに含まれているサブジェクトをログインさせると、HTTPサーブレット・セッションがデフォルトのCookie名JSESSIONIDで作成されます。アサーションの処理が正常に完了すると、ACSによってユーザーのリクエストがターゲットWebアプリケーションにリダイレクトされます。ここで、ターゲットWebアプリケーションにおいてJSESSIONID以外のCookie名が使用されていると、サブジェクトのIDがターゲットWebアプリケーションに伝播されません。そのため、サーブレット・コンテナではユーザーが認証されていないかのように処理され、結果として認証リクエストが発行されます。

このような状況を回避するため、SAML 2.0ベースのシングル・サインオン用に構成されたドメインでWebアプリケーションをデプロイする際は、デフォルトのCookie名を変更しないようにしてください。

クラスタ環境におけるログイン・アプリケーションの考慮事項

ログインに関しては、以下の2つの制限に留意してください。これらはクラスタ環境ではまれにしか発生しませんが、発生するとシングル・サインオン・セッションが失敗する可能性があります。

- IDプロバイダのシングル・サインオン・サービスは、認証リクエストを受け取ると、ユーザーを認証するためにそのリクエストをログイン・アプリケーションにリダイレクトします。ログイン・アプリケーションは、シングル・サインオン・サービスと同じクラスタ・ノードで実行する必要があります。そうしないと、認証が成功しても、IDプロバイダでSAML 2.0アサーションを生成することができません。
通常の状況においてはログイン・アプリケーションをシングル・サインオン・サービスと同じノードで実行するため、認証リクエストがドメイン内の別のノードで実行されているログイン・アプリケーションにリダイレクトされる可能性は非常に低いといえます。しかし、ログイン・アプリケーションをホストするクラスタ・ノードとは別のノードによって認証リクエストがリダイレクトされると、このような状況が発生する可能性があります。こうした状況は、基本認証でデフォルトのログインURIが使用されるようにIDプロバイダを構成することで確実に回避できます。

- SAML 2.0アサーション・コンシューマ・サービス(ACS)は、アサーションを正常に消費すると、アサーションによって表現されたサブジェクトをログインさせます。次にACSは、ユーザー・リクエストをターゲット・アプリケーションにリダイレクトします。通常、ターゲット・アプリケーションはACSと同じノードで実行されています。しかしまれなケースとして、ユーザー・リクエストのリダイレクト先となるターゲット・アプリケーションが、ログインが発生したACSをホストするクラスタ・ノードとは別のノードで実行されていることがあります。このような状況が発生すると、アサーションによって表現されたIDがターゲット・アプリケーションのノードに伝播されません。その結果、シングル・サインオン・プロセスが再試行されるか、アクセスが拒否されます。
通常はターゲット・アプリケーションはACSと同じノードで実行されるため、このような状況は非常にまれにしか発生しません。

強制認証とパッシブ属性の有効化による無効な構成

SAML 2.0サービス・プロバイダ・サービスを構成する場合、強制認証とパッシブ属性の両方を有効にすると、WebLogic Serverが検出できない無効な構成となります。これらの属性がどちらも有効な場合に非認証ユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成され、シングル・サインオン・セッションが失敗します。

WebLogic ServerではSAMLログアウトがサポートされないため、「強制認証」属性の効果がない点に注意してください。ユーザーがIDプロバイダ・サイトですでに認証され、「強制認証」が有効な場合でも、そのユーザーは、IDプロバイダ・サイトで再認証が強制されることはありません。

SAML 1.1および2.0のデバッグの有効化

目的のServerDebug構成属性をtrueに設定すると、SSO用のSAMLを使用するWebアプリケーションのデバッグを有効にできます。WebLogic Serverは、次の項で説明されるように、デバッグを実行するための様々な方法を提供します。

- SAMLデバッグ・スコープおよび属性について

- コマンドラインを使用してデバッグの有効化

- WebLogic Server管理コンソールを使用してデバッグの有効化

- WebLogic Scripting Toolを使用してデバッグの有効化

- 標準出力へのデバッグ・メッセージの送信

SAMLデバッグ・スコープおよび属性について

表7-2および表7-3では、SAML 1.1および2.0用のWebLogic Serverで提供される登録済のデバッグ・スコープと属性をリストして説明しています。

表7-2 SAML 1.1デバッグ・スコープおよび属性

スコープ

属性

説明

weblogic.security.saml.atn

DebugSecuritySAMLAtn

SAML 1.1認証プロバイダ処理に関する情報を出力します。

weblogic.security.saml.credmap

DebugSecuritySAMLCredMap

SAML 1.1資格証明マッピング・プロバイダ処理に関する情報を出力します。

weblogic.security.saml.lib

DebugSecuritySAMLLib

SAML 1.1ライブラリ処理に関する情報を出力します。

weblogic.security.saml.service

DebugSecuritySAMLService

SAML 1.1 SSOプロファイル・サービスに関する情報を出力します。

表7-3 SAML 2.0デバッグ・スコープおよび属性

スコープ

属性

説明

weblogic.security.saml2.atn

DebugSecuritySAML2Atn

SAML 2.0認証プロバイダ処理に関する情報を出力します。

weblogic.security.saml2.credmap

DebugSecuritySAML2CredMap

SAML 2.0資格証明マッピング・プロバイダ処理に関する情報を出力します。

weblogic.security.saml2.lib

DebugSecuritySAML2Lib

SAML 2.0ライブラリ処理に関する情報を出力します。

weblogic.security.saml2.service

DebugSecuritySAML2Service

SAML 2.0 SSOプロファイル・サービスに関する情報を出力します。

コマンドラインを使用してデバッグの有効化

デバッグ・スコープまたは属性は、WebLogic Serverサーバーを起動するコマンドのオプションとして受け渡すことによって有効化できます。属性ごとのSAMLデバッグの有効化に使用できるコマンド・ライン・オプションは、表7-4にリストされています。

表7-4 SAMLデバッグのコマンドライン・オプション

SAMLバージョン

デバッグに使用可能なコマンドライン・オプション

SAML 1.1

-Dweblogic.debug.DebugSecuritySAMLAtn=true

-Dweblogic.debug.DebugSecuritySAMLCredMap=true

-Dweblogic.debug.DebugSecuritySAMLLib=true

-Dweblogic.debug.DebugSecuritySAMLService=true

SAML 2.0

-Dweblogic.debug.DebugSecuritySAML2Atn=true

-Dweblogic.debug.DebugSecuritySAML2CredMap=true

-Dweblogic.debug.DebugSecuritySAML2Lib=true

-Dweblogic.debug.DebugSecuritySAML2Service=true

SAMLデバッグを有効化するためにこの方法は静的なもので、サーバー起動時にのみ使用可能です。

WebLogic Server管理コンソールを使用してデバッグの有効化

WebLogic Server管理コンソールを使用してSAMLデバッグを構成するには、次の手順を実行します。

1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします(「チェンジ・センターの使用」を参照)。

2. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

4. 「デバッグ」をクリックします。

5. weblogicを展開します。

6. securityを展開します。

7. 次のとおりにSAMLデバッグを有効化します。

- すべてのSAML 1.1属性を網羅するSAML 1.1デバッグ・スコープを有効化するには、samlを選択して「有効化」をクリックします。

- 1つ以上の個別のSAML 1.1デバッグ属性を有効化するには、samlを展開し、目的の属性のスコープを展開し、目的の個別のSAML 1.1属性を選択して、「有効化」をクリックします。たとえば、samlを展開し、atnを展開し、DebugSecuritySAMLAtn属性を選択してSAML 1.0認証処理をデバッグします。

- すべてのSAML 2.0属性を網羅するSAML 2.0デバッグ・スコープを有効化するには、saml2を選択して「有効化」をクリックします。

- 1つ以上の個別のSAML 2.0デバッグ属性を有効化するには、saml2を展開し、目的の属性のスコープを展開し、目的の個別のSAML 2.0属性を選択して、「有効化」をクリックします。たとえば、saml2を展開し、credmapを展開し、DebugSecuritySAML2Credmap属性を選択してSAML 2.0資格証明マッピング・プロバイダ処理をデバッグします。

各登録済SAMLデバッグ属性の説明は、「SAMLデバッグ・スコープおよび属性について」を参照してください。

8. これらの変更をアクティブ化するには、管理コンソールのチェンジ・センターで、「変更のアクティブ化」 (チェンジ・センターの使用に関する項を参照)をクリックします。

SAMLデバッグ・スコープおよび属性への変更はただちに実行され、再起動する必要はありません。SAMLデバッグを有効化/無効化するための管理コンソールの使用は動的で、サーバーの稼働中に使用できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデバッグ設定の定義に関する項を参照してください。

WebLogic Scripting Toolを使用してデバッグの有効化

WebLogic Scripting Tool (WLST)を使用してSAMLデバッグ属性を構成できます。たとえば、次のコマンドはdebug.pyというデバッグ属性の設定用プログラムを実行します。

java weblogic.WLST debug.py

debug.pyプログラムには、属性DebugSecuritySAMLAtnのデバッグを有効化する次のコードが含まれます。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugSecuritySAMLAtn','true')
save()
activate()

JavaからWLSTを使用することができます。次の例は、DebugSecuritySAMLAtnデバッグ属性を設定するJavaプログラムのソース・ファイルを示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugSecuritySAMLAtn','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLSTの使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。

標準出力へのデバッグ・メッセージの送信

有効化されたデバッグ属性に対応するメッセージは、サーバー・ログ・ファイルに送信されます。任意で、WebLogic Serverを起動するためのコマンドのLogMBean上でStdoutSeverity=Debug属性を受け渡すことによって、デバッグ・メッセージを標準出力に送信することも可能です。たとえば、-Dweblogic.log.StdoutSeverity=Debugがあります。

詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のメッセージの出力およびロギングに関する項を参照してください。

8 セキュリティ・データの移行

この章では、あるセキュリティ・レルムまたはセキュリティ・プロバイダからセキュリティ・データをエクスポートして、WebLogic Server 10.3.6の別のレルムまたはプロバイダにインポートする方法について説明します。

この章の内容は以下のとおりです。

- セキュリティ・データ移行の概要

- 移行の概念

- WebLogicセキュリティ・プロバイダでサポートされるフォーマットと制約

- WLSTを使用したデータの移行

セキュリティ・データ移行の概要

WebLogicセキュリティ・レルムには様々なセキュリティ・データが永続化されます。これには、WebLogic認証プロバイダのユーザーとグループ、XACML認可プロバイダのセキュリティ・ポリシー、XACMLロール・マッピング・プロバイダのセキュリティ・ロール、WebLogic資格証明マッピング・プロバイダの資格証明マップなどがあります。新しいセキュリティ・レルムまたはセキュリティ・プロバイダを構成する場合、すべてのユーザー、グループ、ポリシー、ロール、および資格証明マップを再作成せずに、既存のセキュリティ・レルムまたはセキュリティ・プロバイダのセキュリティ・データを使用できます。WebLogicセキュリティ・プロバイダの一部は、セキュリティ・データの移行をサポートしています。つまり、あるセキュリティ・レルムからセキュリティ・データをエクスポートして、新しいセキュリティ・レルムへインポートできます。各セキュリティ・プロバイダのセキュリティ・データを個別に移行したり、すべてのWebLogicセキュリティ・プロバイダのセキュリティ・データ(セキュリティ・レルム全体のセキュリティ・データ)を一度に移行したりできます。同じデータ・フォーマットを使用しているプロバイダ間でのみセキュリティ・データを移行できます。「WebLogicセキュリティ・プロバイダでサポートされるフォーマットと制約」を参照してください。セキュリティ・データの移行は、WebLogic管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して行います。

セキュリティ・データの移行は次のような場合に有用です。

- 開発モードから本番モードへ移行します。

- 本番モードのセキュリティ構成を新しいWebLogicドメインのセキュリティ・レルムにコピーします。

- 同じWebLogicドメイン内の、あるセキュリティ・レルムから新しいセキュリティ・レルムにデータを移動します(1つまたは複数のデフォルトWebLogicセキュリティ・プロバイダが新しいセキュリティ・プロバイダに置き換えられる場合)。

以降では、セキュリティの移行の概念、WebLogicセキュリティ・プロバイダでサポートされるフォーマットと制約、およびWLSTを使用してセキュリティ・データを移行する手順について説明します。

WebLogic管理コンソールを使用したセキュリティ・データの移行については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「セキュリティ・レルムからのデータのエクスポート」

- 「セキュリティ・レルムへのデータのインポート」

- 「セキュリティ・プロバイダからのデータのエクスポート」

- 「セキュリティ・プロバイダへのデータのインポート」

移行の概念

フォーマットとは、セキュリティ・データのエクスポートまたはインポートの方法を指定するデータ・フォーマットです。サポートされるフォーマットは、特定のセキュリティ・プロバイダが処理方法を理解しているデータ・フォーマットのリストです。

制約とは、エクスポートまたはインポート処理のオプションの指定に使用されるキーと値の組合せです。制約を使用すると、セキュリティ・プロバイダのデータベース(WebLogic Serverセキュリティ・プロバイダの場合は組込みLDAPサーバー)からエクスポートまたはインポートするセキュリティ・データを制御できます。たとえば、認証プロバイダのデータベースから、グループではなくユーザーだけをエクスポートすることができます。サポートされる制約とは、特定のセキュリティ・プロバイダの移行処理で指定できる制約のリストのことを指します。たとえば、認証プロバイダのデータベースを使用してユーザーとグループをインポートするように指定できますが、セキュリティ・ポリシーはインポートできません。

エクスポート・ファイルは、移行処理のエクスポートの段階で、セキュリティ・データを(指定されたフォーマットで)書き込むファイルです。インポート・ファイルとは、移行処理のインポートの段階で、セキュリティ・データを(指定されたフォーマットで)読み込むファイルです。エクスポート・ファイルとインポート・ファイルはどちらも、あるセキュリティ・プロバイダのデータ・ストアから別のセキュリティ・プロバイダのデータ・ストアに移行する際の、セキュリティ・データの単なる一時的な格納場所です。

WebLogicセキュリティ・プロバイダでサポートされるフォーマットと制約

セキュリティ・プロバイダ間でセキュリティ・データをエクスポートおよびインポートするには、両方のセキュリティ・プロバイダが同じフォーマットを処理する必要があります。WebLogic Serverセキュリティ・プロバイダで使用されるデータ・フォーマットの一部は非公開なので、WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダの間で非公開のフォーマットを使用してセキュリティ・データを移行することは、現時点ではできません。

WebLogicセキュリティ・プロバイダは、表8-1に提示されているインポートおよびエクスポート・フォーマットをサポートします。

表8-1 WebLogicセキュリティ・プロバイダでサポートされるインポートおよびエクスポート・フォーマット

WebLogicプロバイダ

サポートされるフォーマット

WebLogic認証プロバイダ

DefaultAtn - 非公開のフォーマット

XACML認可プロバイダ

XACML - 標準のXACML 2.0フォーマット

DefaultAtz - 非公開のフォーマット

WebLogic認可プロバイダ

DefaultAtz - 非公開のフォーマット

XACMLロール・マッピング・プロバイダ

XACML - 標準のXACML 2.0フォーマット

DefaultRoles - 非公開のフォーマット

WebLogicロール・マッピング・プロバイダ

DefaultRoles - 非公開のフォーマット

WebLogic資格証明マッピング・プロバイダ

DefaultCreds - 非公開のフォーマット

SAML IDアサーションV2

SAML資格証明マッピング・プロバイダV2

XMLパートナ・レジストリ - SAMLパートナ・レジストリ・スキーマで定義されているXMLフォーマット

JKSキーストア - パートナ証明書のインポートおよびエクスポート専用のキーストア・ファイル形式

LDIFテンプレート - LDIFフォーマット

WebLogicセキュリティ・プロバイダは、表8-2に提示されているインポートおよびエクスポートの制約をサポートします。

表8-2 WebLogicセキュリティ・プロバイダでサポートされる制約

WebLogicセキュリティ・プロバイダ

サポートされる制約

説明

デフォルト認証

users

groups

すべてのユーザーまたはすべてのグループをエクスポートします。

- XACML認可

- WebLogic認可

- XACMLロール・マッピング

- WebLogicロール・マッピング

なし

なし

WebLogic資格証明マッピング

passwords

passwords=cleartext制約を使用した場合、パスワードはクリア・テキストでエクスポートされます。それ以外の場合、パスワードは暗号化された形式でエクスポートされます。

- SAML IDアサーションV2

- SAML資格証明マッピングV2

partners

インポートまたはエクスポートするパートナ。制約値は以下のいずれかになります。

- all - すべてのパートナ

- none - パートナなし

- list - リストされたパートナのみ

- enabled - 有効化されたパートナのみ

- disabled - 無効化されたパートナのみ

- SAML IDアサーションV2

- SAML資格証明マッピングV2

certificates

インポートまたはエクスポートする証明書。制約値は以下のいずれかになります。

- all - すべての証明書

- none - 証明書なし

- list - リストされた証明書のみ

- referenced - パートナによって参照される証明書のみ

- SAML IDアサーションV2

- SAML資格証明マッピングV2

passwords

passwords=cleartext制約を使用した場合、パスワードはクリア・テキストでエクスポートされます。それ以外の場合、パスワードは暗号化された形式でエクスポートされます。

- SAML IDアサーションV2

- SAML資格証明マッピングV2

importMode

インポートされたデータとSAMLレジストリ内の既存のデータとの間の名前の競合を解決する方法を指定します。制約値は以下のいずれかになります。

- fail - 競合が検出された場合、インポート操作は失敗します(デフォルト)

- rename - 競合しているインポートされたエントリの名前を変更します

- replace - 既存のエントリを、競合しているインポートされたエントリで置き換えます

WebLogic資格証明マッピング・プロバイダ、SAML資格証明マッピング・プロバイダ、またはSAML IDアサーション・プロバイダからエクスポートする場合、資格証明のパスワードをクリア・テキストでエクスポートするかどうかを指定する必要があります。passwords=cleartext制約を指定すると、パスワードはクリア・テキストでエクスポートされます。それ以外の場合、パスワードは暗号化された形式でエクスポートされます。パスワードの暗号化に使用されるメカニズムはWebLogicドメインごとに異なるため、別のWebLogicドメインで使用する場合は、パスワードをクリア・テキストでエクスポートできます。新しいWebLogicドメインに資格証明マップがインポートされると、パスワードは暗号化されます。移行処理中にシステムでセキュアなデータを利用できるようにするため、クリア・テキストの資格証明マップのエクスポート先となるディレクトリとファイルは慎重に保護してください。

注意:
WebLogic認証プロバイダは、デフォルトでは一方向のハッシュを使用してパスワードを格納します。このプロバイダによって暗号化されたパスワードは、データのエクスポート時にpasswords=cleartext制約を使用しても、暗号化せずに送信することはできません。このプロバイダからクリア・テキストでパスワードをエクスポートできるようにしたい場合は、それらのパスワードを作成または更新する前に、「パスワード・ダイジェストの有効化」属性をtrueに設定する必要があります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト認証プロバイダ: プロバイダ固有に関する項を参照してください。

WLSTを使用したデータの移行

WebLogic Scripting Tool (WLST)を使用して、セキュリティ・プロバイダからデータをエクスポートしてインポートできます。セキュリティ・プロバイダの実行時MBeanにアクセスして、そのimportData操作またはexportData操作を使用します。たとえば、以下のようなコマンドでWLSTを使用してデータをインポートします。

domainRuntime()
cd('DomainServices/DomainRuntimeService/DomainConfiguration/mydomain
/SecurityConfiguration/mydomain/DefaultRealm/myrealm/path-to-MBean/mbeanname')
cmo.importData(format,filename,constraints)

説明:

- mbeanname - セキュリティ・プロバイダMBeanの名前。

- format - 特定のセキュリティ・プロバイダで有効なフォーマット。表8-1を参照してください。

- filename - セキュリティ・データをエクスポートまたはインポートするディレクトリの場所とファイル名。WLSTコマンドでは、使用するオペレーティング・システムがUNIXかWindowsかに関係なく、パス名引数のパス区切りとしてバック・スラッシュではなくフォワードスラッシュを使用する必要があります。

- constraints - エクスポートまたはインポートするデータを限定する制約。

詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

9 組込みLDAPサーバーの管理

この章では、WebLogic Server 10.3.6に含まれ、デフォルト認証プロバイダ、認可プロバイダ、資格証明マッピング・プロバイダ、およびロール・マッピング・プロバイダのデフォルトのセキュリティ・プロバイダ・データ・ストアとしての役割を持つ組込みLDAPサーバーを構成および管理する方法について説明します。

この章の内容は以下のとおりです。

- 組込みLDAPサーバーの構成

- 組込みLDAPサーバーのレプリケーション

- LDAPブラウザからの組込みLDAPサーバーの内容の表示

- 組込みLDAPサーバーの情報のエクスポートおよびインポート

- LDAPアクセス制御の構文

- バックアップおよびリカバリ

組込みLDAPサーバーの構成

組込みLDAPサーバーには、ユーザー、グループ、グループ・メンバーシップ、セキュリティ・ロール、セキュリティ・ポリシー、および資格証明マップ情報が格納されます。デフォルトでは、各WebLogicドメインに、各種の情報のデフォルト値が構成されている組込みLDAPサーバーが1つあります。デフォルト認証、認可、資格証明マッピング、およびロール・マッピングの各プロバイダは、組込みLDAPサーバーをデータ・ストアとして使用します。新しいセキュリティ・レルムでこれらのプロバイダを使用する場合は、組込みLDAPサーバーのデフォルト値を変更して、環境に合せて最適化できます。

注意:
組込みLDAPサーバーは、10,000ユーザー未満の環境で最高のパフォーマンスを示します。これよりユーザーが多い場合は、別のLDAPサーバーと認証プロバイダの使用を検討してください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーの構成に関する項を参照してください。

組込みLDAPサーバーで使用されるデータ・ファイルおよび変更ログ・ファイルは、非常に大きなサイズになる場合があります。以下のweblogic.Serverコマンド・ライン引数を使用すると、こうしたファイルに対して最大サイズを構成できます。

- -Dweblogic.security.ldap.maxSize=<max bytes>。組込みLDAPサーバーで使用されるデータ・ファイルのサイズを制限します。データ・ファイルが指定されたサイズを超えると、削除済みのエントリによって占有されていたスペースがデータ・ファイルから削除されます。

- -Dweblogic.security.ldap.changeLogThreshold=<number of entries>。組込みLDAPサーバーで使用される変更ログ・ファイルのサイズを制限します。変更ログ・ファイルが指定されたエントリ数を超えると、すべての管理対象サーバーに送信されていたすべてのエントリを削除することによって変更ログが切り詰められます。

組込みLDAPサーバーのレプリケーション

ドメインのWebLogic Serverの組込みLDAPサーバーは、1つのマスターLDAPサーバー(ドメインの管理サーバーが保持する)と、レプリケートされたLDAPサーバー(ドメインの各管理対象サーバーが保持する)で構成されます。管理対象サーバーを使用して変更が行われると、その更新データは管理サーバー上の組込みLDAPサーバーに送信されます。管理サーバー上の組込みLDAPサーバーは、すべての変更のログを保持します。また、管理サーバー上の組込みLDAPサーバーは、管理対象サーバーのリストと各管理対象サーバーの現在の変更ステータスも保持します。管理サーバー上の組込みLDAPサーバーは、各管理対象サーバーに適切な変更を送信して、各サーバーの変更ステータスを更新します。この処理は管理サーバー上の組込みLDAPサーバーで更新が行われたときに発生します。ただし、更新の回数によっては、変更が管理対象サーバーにレプリケートされるのに数秒以上かかることがあります。

管理コンソールを使用すると、ドメイン内の管理サーバーと管理対象サーバー上の組込みLDAPサーバーの動作を構成できます。管理コンソールの「ドメイン」→「セキュリティ」→「組込みLDAP」ページで、次の属性を設定します。

- 起動時にレプリカをリフレッシュ - 管理対象サーバーの組込みLDAPサーバーがすべてのレプリケートされたデータを起動時にリフレッシュするかどうかを指定します。この設定は、管理対象サーバーがアクティブでないときに大量の変更を行った場合に、各変更を管理サーバーから管理対象サーバーに送るのではなく、レプリカ全体をダウンロードする場合に役立ちます。

- マスター優先 - 管理対象サーバーが、ローカルのレプリケートされたLDAPサーバーではなく常に管理サーバー上の組込みLDAPサーバーに接続するかどうかを指定します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーの構成に関する項を参照してください。

注意:
構成済みのセキュリティ・プロバイダをWebLogic管理コンソールで削除および修正する際には、組込みLDAPサーバーの手動クリーンアップが必要になることがあります。外部LDAPブラウザを使用して、不要な情報を削除します。

LDAPブラウザからの組込みLDAPサーバーの内容の表示

LDAPブラウザで組込みLDAPサーバーの内容を表示するには:

1. 外部LDAPブラウザをダウンロードしてインストールします。LDAPブラウザの1つは次のサイトにあります。
http://www.openldap.org/

この手順では、このLDAPブラウザを使用することを前提としています。他のLDAPブラウザでは詳細が異なる場合があります。

2. WebLogic Server管理コンソールで、組込みLDAPサーバーの資格証明を変更します。

1. 「ドメイン」→「セキュリティ」→「組込みLDAP」の順に展開します。

2. 「資格証明」フィールドに、新しい資格証明を入力します。

3. 「資格証明の確認」フィールドに、新しい資格証明をもう一度入力します。

4. 「保存」をクリックします。

5. WebLogic Serverを再起動します。

警告:
資格証明を変更すると、ドメインの動作に影響することがあります。本番サーバーでは、この手順は実行しないでください。

3. LDAPブラウザを起動します。ステップ1で示したLDAPブラウザ/エディタを起動するには、次のコマンドを使用します。

lbe.sh

4. LDAPブラウザで、新しい接続を構成します。

1. 「QuickConnect」タブを選択します。

2. 「ホスト」フィールドをlocalhostに設定します。

3. 「ポート」フィールドを7001 (SSLを使用する場合は7002)に設定します。

4. 「ベースDN」フィールドをdc=mydomainに設定します。mydomainは使用するWebLogicドメインの名前です。

5. 「匿名バインド」オプションのチェックを解除します。

6. 「ユーザーDN」フィールドをcn=Adminに設定します。

7. 「パスワード」フィールドにステップ2で指定した資格証明を設定します。

5. 新しい接続をクリックします。
LDAPブラウザを使用して、組込みLDAPサーバーの階層をナビゲートします。

注意:
データをエクスポートし、エクスポート・ファイルを参照することで、組込みLDAPサーバーの内容を表示することもできます。「組込みLDAPサーバーの情報のエクスポートおよびインポート」を参照してください。

組込みLDAPサーバーの情報のエクスポートおよびインポート

WebLogic Server管理コンソールまたはLDAPブラウザでは、組込みLDAPサーバーからデータをエクスポートしてインポートできます。管理コンソールでデータをエクスポートおよびインポートするには、各セキュリティ・プロバイダの「移行」ページを使用します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・プロバイダからのデータのエクスポートに関する項およびセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。

警告:
管理コンソールの「移行」タブを使用してセキュリティ・データをエクスポートすると、ターゲット・ディレクトリ内の拡張子.datの既存ファイルはすべて削除されます。セキュリティ・データは、必ず空のディレクトリにエクスポートするようにしてください。

この節では、LDAPブラウザを使用して、組込みLDAPサーバーに格納されているデータをエクスポートおよびインポートする方法について説明します。表9-1に、組込みLDAPサーバーの階層におけるデータの格納場所をまとめます。

表9-1 組込みLDAPサーバー内のセキュリティ・データの場所

セキュリティ・データ

組込みLDAPサーバーDN

ユーザー

ou=people,ou=myrealm,dc=mydomain

グループ

ou=groups,ou=myrealm,dc=mydomain

セキュリティ・ロール

ou=ERole,ou=myrealm,dc=mydomain

セキュリティ・ポリシー

ou=EResource,ou=myrealm,dc=mydomain

LDAPブラウザ/エディタを使用して組込みLDAPサーバーからセキュリティ・データをエクスポートするには:

1. コマンド・プロンプトに次のコマンドを入力して、LDAPブラウザ/エディタを起動します。

lbe.sh

2. エクスポートするデータを指定します(たとえば、ユーザーをエクスポートするにはou=people,ou=myrealm,dc=mydomainと指定します)。

3. 「LDIF」>「エクスポート」オプションを選択します。

4. 「すべての子をエクスポートする」を選択します。

5. データのエクスポート先ファイルの名前を指定します。

LDAPブラウザ/エディタを使用して組込みLDAPサーバーにセキュリティ・データをインポートするには:

1. コマンド・プロンプトに次のコマンドを入力して、LDAPブラウザを起動します。

lbe.sh

2. インポートするデータを指定します(たとえば、ユーザーをインポートするにはou=people,ou=myrealm,dc=mydomainと指定します)。

3. LDAPブラウザ/エディタで、「LDIF」>「インポート」オプションを選択します。

4. 「更新/追加」を選択します。

5. データをインポートするファイルの名前を指定します。

LDAPアクセス制御の構文

組込みLDAPサーバーはIETFの「LDAP Access Control Model for LDAPv3」をサポートしています。この節では、そのアクセス制御を組込みLDAPサーバーの内部に実装する方法について説明します。これらのルールは、標準で想定されているようにディレクトリ内のエントリに直接適用することも、アクセス制御ファイル(acls.prop)を編集して構成および管理することもできます。

注意:
組込みLDAPサーバーのデフォルトの動作では、WebLogic ServerのAdminアカウントからのアクセスのみが許可されます。WebLogicセキュリティ・プロバイダでは、Adminアカウントのみを使用して組込みLDAPサーバーにアクセスします。外部LDAPブラウザから組込みLDAPサーバーにアクセスする予定がない場合やAdminアカウントのみを使用する予定の場合、acls.propファイルの編集は不要なので、この項の情報は無視して構いません。

アクセス制御ファイル

組込みLDAPサーバーが保持するアクセス制御ファイル(acls.prop)には、LDAPディレクトリ全体のアクセス制御リスト(ACL)の完全なリストが含まれています。アクセス制御ファイルの各行には、アクセス制御ルールが1つずつ含まれています。アクセス制御ルールは以下の要素で構成されています。

- ルールを適用するLDAPディレクトリ内の場所。「アクセス制御の場所」を参照してください。

- その場所の内部でルールを適用する範囲。「アクセス制御のスコープ」を参照してください。

- アクセス権(付与または拒否)。「アクセス権」を参照してください。

- パーミッション(付与または拒否)。「属性のパーミッション」および「エントリのパーミッション」を参照してください。

- ルールを適用する属性。「属性タイプ」を参照してください。

- アクセスを付与または拒否するサブジェクト。「サブジェクト・タイプ」を参照してください。

例9-1に、アクセス制御ファイルのサンプルを示します。

例9-1 サンプルacl.propsファイル

[root]|entry#grant:r,b,t#[all]#public

ou=Employees,dc=octetstring,dc=com|subtree#grant:r,c#[all]#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:b,t#[entry]#public:
ou=Employees,dc=octetstring,dc=com|subtree#deny:r,c#userpassword#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:r#userpassword#this:
ou=Employees,dc=octetstring,dc=com|subtree#grant:w,o#userpassword,title,
description,
postaladdress,telephonenumber#this:
cn=schema|entry#grant:r#[all]#public:

アクセス制御の場所

各アクセス制御ルールはLDAPディレクトリ内の特定の場所に適用されます。場所は通常は識別名(DN)ですが、アクセス制御ルールをディレクトリ全体に適用する場合は、acls.propファイルで特定の場所のrootを指定できます。

LDAPサーバー上でアクセスまたは変更されるエントリが、アクセス制御ルールの場所に一致しないか下位ディレクトリに存在しない場合、指定されたアクセス制御ルールはそれ以上評価されません。

アクセス制御のスコープ

以下のアクセス制御のスコープが定義されています。

- エントリ - エントリのスコープを持つACLは、LDAPディレクトリ内のエントリが、アクセス制御ルールの場所と同じDNを共有する場合にのみ評価されます。このようなルールは、単一のエントリに、同列または下位のエントリよりも重要な情報が含まれる場合に有用です。

- サブツリー - サブツリーのスコープは、LDAPディレクトリ内のエントリが、このアクセス制御の場所と同じ、またはこのアクセス制御の場所で終わる場合に評価されます。このスコープでは、その場所のエントリとすべての下位エントリが保護されます。

ディレクトリ内のエントリが、競合するアクセス制御ルールの対象となっている場合(たとえば、あるルールが「エントリ」のルールで、別のルールが「サブツリー」のルールである場合)、「エントリ」のルールが「サブツリー」のルールよりも優先されます。

アクセス権

アクセス権はオブジェクト全体またはオブジェクトの属性に適用されます。アクセスは付与または拒否されます。アクセス制御ルールを作成または更新するときに、grantまたはdenyのアクションを使用できます。

LDAPのアクセス権はそれぞれが分離しています。ある権限に別の権限が含まれることはありません。権限では実行できるLDAP操作のタイプを指定します。

属性の権限

表9-2で示される権限は、属性を含むアクションに適用されます。

表9-2 属性の権限

権限

説明

r Read

属性を読み込みます。付与される場合、読み込みまたは検索操作で、属性と値を返すことが許可されます。

w Write

属性を変更または追加します。付与される場合、変更操作で属性と値の追加が許可されます。

o Obliterate

属性を変更または削除します。付与される場合、変更操作で属性と値の削除が許可されます。

s Search

指定された属性を持つエントリを検索します。付与される場合、属性と値が検索操作の対象となることが許可されます。

c Compare

属性値を比較します。付与される場合、属性と値が比較操作の対象となることが許可されます。

m Make

このエントリの下の新しいLDAPエントリに属性を作成します。

m権限は、オブジェクトを作成するときにオブジェクトに配置されるすべての属性に対して必須です。変更操作でwおよびo権限が使用されるのと同様に、m権限は追加操作で使用されます。wおよびo権限は追加操作とは無関係で、m権限は変更操作とは無関係です。新しいオブジェクトはまだ存在していないため、オブジェクトの作成に必要なaおよびm権限は、新しいオブジェクトの親に付与されている必要があります。この要件は、変更対象のオブジェクトに付与する必要のあるwおよびo権限とは異なります。エントリに新しい子を追加するために必要な権限と、同じエントリの既存の子を変更するために必要な権限が競合しないように、m権限はwおよびo権限とは別個で固有のものになっています。変更操作で値を置き換えるには、ユーザーはw権限とo権限の両方を持つ必要があります。

エントリの権限

表9-3で示される権限は、LDAPエントリ全体に適用されます。

表9-3 エントリの権限

権限

説明

a Add

このLDAPエントリの下にエントリを追加します。付与される場合、DITサブジェクト内にエントリを作成して、作成時に新しいエントリに配置されるすべての属性と値を制御することが許可されます。エントリを追加するには、少なくとも必須の属性を追加する権限も付与されなければなりません。

d Delete

このエントリを削除します。付与される場合、エントリ内の属性の制御に関係なく、DITからエントリを削除することが許可されます。

e Export

エントリとすべての下位エントリを新しい場所にエクスポートします。

付与される場合は、エントリとその下位エントリ(存在する場合)のエクスポートが許可されます。つまり、エクスポート先に適した許可を付与するという前提で、エントリを現在の場所から削除して新しい場所に配置します。

最後のRDNを変更する場合は、現在の場所でRename権限も必要になります。

エントリまたはその下位エントリをエクスポートする際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。

i Import

エントリと下位エントリを指定された場所からインポートします。

付与される場合、エントリとその下位エントリ(存在する場合)のインポートが許可されます。つまり、新しい場所に適した権限が付与される場合、エントリをある場所から削除して指定された場所に配置します。

エントリまたはその下位エントリをインポートする際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。

n RenameDN

LDAPディレクトリのDNを変更します。エントリの名前を新しいRDNに変更する(下位エントリのDNも結果として変更される)場合は、Rename権限を付与する必要があります。上位のエントリの名前を変更しない場合、付与は十分です。

エントリの名前を変更する際に、エントリに含まれる属性(RDN属性を含む)に必須の権限はありません。操作によって新しい属性値が追加されたり、RDNの変更の結果として属性値が削除されたりする場合でも、このことが当てはまります。

b BrowseDN

エントリのDNを参照します。付与される場合、ディレクトリ操作を使用してエントリにアクセスすることが許可されます。この操作では、エントリの名前は明示的に提供されません。

t ReturnDN

操作の結果にエントリのDNを公開することが許可されます。付与される場合、操作の結果にエントリの識別名を公開することが許可されます。

属性タイプ

アクセス制御ルールが適用される属性タイプは、必要な場合にACLにリストする必要があります。以下のキーワードが使用されます。

- entry - 権限がオブジェクト全体に適用されることを示します。オブジェクトの削除や子オブジェクトの追加などのアクションを意味します。

- all - 権限がエントリのすべての属性に適用されることを示します。

ACL内でキーワードallと別の属性の両方が指定されている場合、属性に対する限定性の高い権限が、allキーワードで指定される限定性の低い権限をオーバーライドします。

サブジェクト・タイプ

アクセス制御ルールは、様々なサブジェクト・タイプと関連付けることができます。アクセス制御ルールのサブジェクトによって、現在接続しているセッションにアクセス制御ルールが適用されるかどうかが決まります。

以下のサブジェクト・タイプが定義されます。

- authzID - サブジェクト定義の一部として指定できる単一のユーザーに適用されます。ユーザーのIDは、LDAPディレクトリ内で通常DNとして定義されます。

- Group - 以下のいずれかのオブジェクト・クラスで指定されるユーザーのグループに適用されます。

- groupOfUniqueNames

- groupOfNames

- groupOfUniqueURLs

1番目と2番目のタイプのグループにはユーザーのリストが含まれます。3番目のタイプでは、定義された基準に基づいてユーザーが自動的にグループに分類されます。

- Subtree - LDAPディレクトリ・ツリー内のサブジェクトとすべての下位エントリの一部として指定されるDNに適用されます。

- IP Address - 特定のインターネット・アドレスに適用されます。このサブジェクト・タイプは、すべてのアクセスがプロキシ・サーバーまたは他のサーバーを経由しなければならない場合に便利です。特定のホストにのみ適用され、範囲やサブネットには適用されません。

- Public - 認証されるかどうかにかかわらず、ディレクトリに接続するすべての対象に適用されます。

- This - アクセスされるエントリのDNに一致するDNを持つユーザーに適用されます。

評価ルールの付与または拒否

エントリ内の情報に対するクライアント・アクセスを付与または拒否するかどうかの決定は、アクセス制御ルールや保護されるエントリに関連する様々な要因に基づいて行われます。意思決定プロセスの過程には、以下のような指針となる原則があります。

- 限定性の高いルールが限定性の低いルールをオーバーライドします(たとえば、ACL内の個々のユーザー・エントリは、グループ・エントリに優先します)。

- ルールの限定性に関係なく競合が解消されない場合は、ルールのサブジェクトによって適用すべきルールが決まります。IP Addressサブジェクトに基づくルールが最優先され、その次に、特定のAuthzIDまたはThisサブジェクトに適用されるルールが続きます。次に優先されるのは、Groupサブジェクトに適用されるルールです。優先度が最も低いのは、SubtreeおよびPublicサブジェクトに適用されるルールです。

- ACLに競合する値がある場合、拒否の方が付与よりも優先されます。

- アクセス制御情報がない場合は、デフォルトで拒否されます。また、エントリのスコープはサブツリーのスコープに優先します。

バックアップおよびリカバリ

任意のセキュリティ・レルムがデフォルト認証、認可、資格証明マッピングまたはロール・マッピング・プロバイダを使用する場合、次のディレクトリ・ツリーの最新バックアップを保持する必要があります:

domain_name/servers/adminServer/data/ldap

前述のディレクトリでは、domain_nameはドメインのルート・ディレクトリ、adminServerは、管理サーバーがランタイム・セキュリティ・データを保存するディレクトリとなります。組込みLDAPサーバー・データのバックアップの詳細は、次のトピックを参照してください。

- 『Oracle WebLogic Serverサーバーの起動と停止の管理』のLDAPリポジトリのバックアップに関する項

- Oracle WebLogic Server管理コンソール・ヘルプの組込みLDAPサーバーのバックアップの構成に関する項を参照してください。

組込みLDAPサーバー・ファイルが破損または使用不能の場合、管理サーバーはNumberFormatExceptionを生成して起動できません。このような状況はほとんど起こりませんが、ディスク容量がいっぱいなため組込みLDAPファイルが無効な状態になる場合には発生する可能性があります。

組込みLDAPサーバー・ファイルが使用不能な状態から復元するには、次の手順を実行します。

1. 次のディレクトリを変更します。

domain_name/servers/adminServer/data

2. 組込みLDAPサーバー・ファイルの名前を、次の例のように変更します。

mv ldap ldap.old

ファイル名を変更し、ファイルを完全には削除しないことによって、分析や今後のデータ・リカバリ用にファイルが使用できる状態になります。

3. 管理サーバーを起動します。
管理サーバーが起動すると、新しい組込みLDAPサーバー・ファイルが作成されます。

4. WebLogicドメインの作成時から追加されたデータを新しい組込みLDAPサーバーに復元します。
組込みLDAPサーバーのバックアップを構成済の場合は、それをインポートすることによってバックアップされたデータを復元できます。詳細は、「組込みLDAPサーバー内の情報のエクスポートおよびインポート」を参照してください。

10 RDBMSセキュリティ・ストアの管理

この章では、WebLogic Server 10.3.6で認可プロバイダ、ロール・マッピング・プロバイダ、資格証明マッピング・プロバイダ、および証明書レジストリ・プロバイダに使用されるデータ・ストアとして、外部のRDBMSを使用するオプションについて説明します。RDBMSセキュリティ・ストアと呼ばれるこのデータ・ストアを本番環境で使用すると、SAML 2.0セキュリティ・プロバイダで管理するデータを、それらを共有するすべてのWebLogic Serverインスタンスの間で同期させることができます。(開発環境のみの場合は、SAML 2.0セキュリティ・プロバイダでセキュリティ・ストアとしてLDAPを使用します)。

注意:
RDBMSセキュリティ・ストアを使用するには、まず、ドメインを作成して外部RDBMSサーバーを構成します。ドメインを起動する前に、RDBMSセキュリティ・ストアで必要になる表をデータストア内に作成します。WebLogic Serverインストール・ディレクトリには、サポート対象のデータベースごとに、これらの表を作成する一連のSQLスクリプトが含まれています。

以下の節では、RDBMSセキュリティ・ストアの構成および管理方法について説明します。

- RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダ

- RDBMSセキュリティ・ストアの構成

- RDBMSセキュリティ・ストアを使用するドメインのアップグレード

RDBMSセキュリティ・ストアとして機能する、WebLogic Serverでサポートされる特定のデータベース・システムの最新の詳細は、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。

RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダ

以下のセキュリティ・プロバイダは、ドメイン内にRDBMSセキュリティ・ストアが構成されている場合は、そのストアを使用します。

- XACML認可プロバイダ

- XACMLロール・マッピング・プロバイダ

- SAML 1.1の以下のプロバイダ

- SAML IDアサーション・プロバイダV2

- SAML資格証明マッピング・プロバイダV2

- SAML 2.0の以下のプロバイダ

- SAML 2.0 IDアサーション・プロバイダ

- SAML 2.0資格証明マッピング・プロバイダ

- WebLogic資格証明マッピング・プロバイダ

- PKI資格証明マッピング・プロバイダ

- 証明書レジストリ

ドメイン内にRDBMSセキュリティ・ストアが構成されている場合、セキュリティ・レルム内に作成されている上記のいずれかのセキュリティ・プロバイダのインスタンスは、自動的にRDBMSセキュリティ・ストアのみをデータストアとして使用し、組込みLDAPサーバーは使用しません。ドメイン内に構成されている上記のリスト以外のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します。たとえば、デフォルト認証プロバイダは組込みLDAPサーバーを使用します。

RDBMSセキュリティ・ストアはドメインの作成時に構成することをお薦めします。このプロセスを簡素化するように構成ウィザードが改良されました。このユーティリティにはRDBMS接続をテストするオプションが含まれており、ドメインの起動時にドメインへのアクセスに必要なセキュリティ・ポリシーが確実に取得されるようになります。

構成ウィザードに加えて、RDBMSSecurityStoreMBeanも用意されています。WebLogic Scripting Tool (WLST)からRDBMSセキュリティ・ストアを構成するためのインタフェースです。

RDBMSセキュリティ・ストアの構成

ドメインでRDBMSセキュリティ・ストアを作成して構成するには、以下の節で説明するタスクを完了します。

- RDBMSセキュリティ・ストアを使用するドメインの作成

- セキュリティ・データ・ストア内でのRDBMS表の作成

- RDBMSセキュリティ・ストアのJMSトピックの構成

RDBMSセキュリティ・ストアを使用するドメインの作成

ドメインでRDBMSセキュリティ・ストアを使用するには、ドメインの作成時にRDBMSセキュリティ・ストアを構成することをお薦めします。RDBMSセキュリティ・ストアを使用するように既存のドメインを変更することはできますが、データベース接続が正しく構成されていない場合、ドメインへのアクセスを許可するために必要なポリシーが使用できず、ドメインを使用できなくなる可能性があるため、お薦めしません。

WebLogic Serverには、RDBMSセキュリティ・ストアを構成できるドメインの作成方法として2通りの方法があります。

- 構成ウィザードを使用する - RDBMSセキュリティ・ストアを構成するオプションが用意されています。このオプションは「環境とサービスの設定のカスタマイズ」ページにあります。
このオプションを選択すると、構成ウィザードには以下の操作が可能な後続のウィンドウが表示されます。

1. RDBMSセキュリティ・ストアとして使用する特定のデータベース・システムを選択する

2. データベース接続設定を構成する

3. データベース接続をテストする

- WebLogic Scripting Tool (WLST)オフラインを使用します。RDBMSセキュリティ・ストアを作成および構成するためのオプションはRDBMSSecurityStoreMBeanで提供されています。

どちらの方法を選んでドメインを作成する場合でも、以下の節で説明するように、RDBMSセキュリティ・ストアとして機能するデータベースの接続プロパティを必ず構成してください。

データベース接続プロパティの指定

構成ウィザードまたはWLSTでRDBMSセキュリティ・ストアを構成するときに、以下の項目を指定する必要があります。

- RDBMSのタイプ
RDBMSセキュリティ・ストアを含むことをサポートされるデータベースの詳細は、Oracle Technology NetworkのOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

- RDBMSに接続するためのJDBCドライバとクラス名

- RDBMSの名前、ホスト、ポート、およびURL

- RDBMSシステムにアクセスできるドメイン・ユーザーのユーザー名とパスワード

警告:
この項で提供されるWLSTの例では、わかりやすいように、RDBMSシステム・ユーザーのユーザー名とパスワードの資格証明をクリア・テキストで渡しています。通常はWLSTコマンドにクリア・テキストのパスワードを入力しないでください。特に、クリア・テキストのパスワードが含まれるWLSTスクリプトをディスクに保存することは避けてください。このような状況では、暗号化されたパスワードを渡すメカニズムをかわりに使用する必要があります。

- RDBMSシステムに渡す必要のある任意のプロパティ(オプション)

JDBCドライバの接続プロパティ属性で指定するパラメータはカンマ区切りのリストにする必要があります。以下のサンプルでは、WLSTを使用してOracle、MS-SQL、およびDB2のデータベース接続プロパティを構成する方法を示します。

Oracleのサンプル

例10-1に、RDBMSセキュリティ・ストア用にOracleを構成するサンプルを示します。

例10-1 RDBMSセキュリティ・ストア用のOracleの構成

create('base_domain','SecurityConfiguration')
cd('/SecurityConfiguration/base_domain')
a=get('DefaultRealm')
cd('Realm/myrealm')
rdbms = create("myRDBMSSecurityStore", "RDBMSSecurityStore")
rdbms.setUsername('ortiz')
rdbms.setPassword('welcome1')
rdbms.setConnectionURL('jdbc:bea:oracle://avitek21:1521')
rdbms.setDriverName('weblogic.jdbc.oracle.OracleDriver')
rdbms.setConnectionProperties('user=ortiz,portNumber=1521,SID=pint101a,serverName=avitek21')

MS-SQLのサンプル

例10-2に、RDBMSセキュリティ・ストア用にMS-SQLを構成するサンプルを示します。

例10-2 RDBMSセキュリティ・ストア用のMS-SQLの構成

create('base_domain','SecurityConfiguration')
cd('/SecurityConfiguration/base_domain')
a=get('DefaultRealm')
cd('Realm/myrealm')
rdbms = create("myRDBMSSecurityStore", "RDBMSSecurityStore")
rdbms.setUsername('garnett')
rdbms.setPassword('welcome1')
rdbms.setConnectionURL('jdbc:bea:sqlserver://avitek6:1433')
rdbms.setDriverName('weblogic.jdbc.sqlserver.SQLServerDriver')
rdbms.setConnectionProperties('user=garnett,portNumber=1433,databaseName=wls3,serverName=avitek6')

DB2のサンプル

例10-3に、RDBMSセキュリティ・ストア用にDB2を構成するサンプルを示します。

注意:
DB2を選択する場合は、WebLogic Serverで提供されているDB2用のWebLogicタイプ4 JDBCドライバを選択するオプションがあります。ただし、このJDBCドライバを使用する場合は、追加のプロパティBatchPerformanceWorkaroundを指定してtrueに設定する必要があります。この構成でBatchPerformanceWorkaroundをtrueに設定しない場合、WebLogic Serverは起動に失敗し、SecurityServiceExceptionメッセージが生成されます。

例10-3 RDBMSセキュリティ・ストア用のDB2の構成

create('base_domain','SecurityConfiguration')
cd('/SecurityConfiguration/base_domain')
a=get('DefaultRealm')
cd('Realm/myrealm')
rdbms = create("myRDBMSSecurityStore", "RDBMSSecurityStore")
rdbms.setUsername('brady')
rdbms.setPassword('welcome1')
rdbms.setConnectionURL('jdbc:bea:db2://avitek3:50000')
rdbms.setDriverName('weblogic.jdbc.db2.DB2Driver')
rdbms.setConnectionProperties('user=brady,portNumber=50000,databaseName=wls,serverName=avitek3,batchPerformanceWorkaround=true')

DB2用のWebLogic Type 4 JDBCドライバの接続プロパティの指定の詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogicブランドのDataDirectドライバの使用に関する項を参照してください。

デフォルトの接続プロパティの詳細

RDBMSセキュリティ・ストアは内部的にはOracle Kodoを使用して、DB2用のWebLogicタイプ4 JDBCドライバを使用するデータベースに接続し、やり取りします。RDBMSSecurityStoreMBeanで設定された属性はKodoのjavax.sql.DataSource実装のプロパティで設定される属性に変換されます。

これらの属性の詳細は、以下のトピックを参照してください。

- RDBMSSecurityStoreMBeanで設定できる属性の詳細は、Oracle WebLogic Server MBeanリファレンスのRDBMSSecurityStoreMBeanに関する項を参照してください。

- Kodo DataDourceのデフォルトのデータベース接続プロパティについては、Kodo JPA/JDOリファレンス・ガイドの「JDBC」の章のKodo DataSourceの使用に関する項を参照してください。

データベース接続のテスト

構成ウィザードでRDBMSセキュリティ・ストアを構成する途中で、データベース接続をテストするオプションが表示されます。接続が適切に設定されているかどうか検証できるため、このオプションを使用することを強くお薦めします。データベース接続に問題があると、ドメインへのアクセスを制御するセキュリティ・プロバイダが必要なセキュリティ・ポリシーを取得できない場合に、ドメインを起動できなくなる可能性があります。

構成ウィザードでのRDBMSセキュリティ・ストアの構成については、『構成ウィザードによるドメインの作成』のオプションの構成の選択に関する項を参照してください。

セキュリティ・データ・ストア内でのRDBMS表の作成

ドメインを起動する前に、データベース管理者はRDBMSセキュリティ・ストアで使用されるデータベース内にRDBMS表を作成するSQLスクリプトを実行する必要があります。以下のWebLogic Serverインストール・ディレクトリには、サポートされる各RDBMSシステム用に、これらの表を作成および削除するための一連のSQLスクリプトが用意されています。

WL_HOME/server/lib

RDBMSセキュリティ・ストアとして機能するデータベース用の該当するSQLスクリプトを実行するときは、必ず、ドメイン作成時にRDBMSに対して指定したものと同じ接続プロパティ(アクセスするユーザーの資格証明、データベースURLなど)を指定してください。

表10-1に、各SQLスクリプトの名前を示します。

表10-1 RDBMSデータ・ストア表を作成および削除するためのSQLスクリプト

RDBMSシステム

データ・ストア表の作成

データ・ストア表の削除

Oracle 9i、10g、11g

rdbms_security_store_oracle.sql

rdbms_security_store_oracle_remove.sql

MS-SQL 2000、2005

rdbms_security_store_sqlserver.sql

rdbms_security_store_sqlserver_remove.sql

DB2 9.2、9.5

rdbms_security_store_db2.sql

rdbms_security_store_db2_remove.sql

Derby

rdbms_security_store_derby.sql

rdbms_security_store_derby_remove.sql

RDBMSセキュリティ・ストアのJMSトピックの構成

複数のWebLogic Serverインスタンスを含むドメイン、またはクラスタ内にRDBMSセキュリティ・ストアを構成する場合は、以下のタスクを実行することを強くお薦めします。

1. そのドメインでJMS通知を有効にします。

2. RDBMSセキュリティ・ストアで使用できるJMSトピックを構成します。

JMS通知を使用すると、RDBMSセキュリティ・ストアに格納され、レルム内のセキュリティ・プロバイダによって管理されるセキュリティ・データを、ドメイン内のすべてのサーバー・インスタンスにわたって同期化することができます。

警告:
RDBMSセキュリティ・ストアが複数サーバーのドメインやクラスタリングされたドメインで構成されているときに、そのストアで使用できるJMSトピックを構成しない場合は、セキュリティ・ポリシーの作成やセキュリティ構成の更新を慎重に行う必要があります。JMSトピックを構成しない場合、セキュリティの更新内容に従ってすべてのサーバー・インスタンスが一貫して機能するにはドメインの再起動が必要になる可能性があります。

JMS通知を有効にするには、RDBMSセキュリティ・ストアが構成されているドメインを起動して、以下のいずれかの方法でRDBMSSecurityStoreMBeanの属性を構成します。

- WebLogic Scripting Tool

- 管理コンソールの「セキュリティ・レルム」→「レルム名」→「RDBMSセキュリティ・ストア」ページ

JMS通知を有効にするために設定する必要があるRDBMSSecurityStoreMBeanの属性について表10-2で説明します。

表10-2 JMSトピックを構成するためのRDBMSSecurityStoreMBeanの属性

属性名

説明

JMSTopic

Kodoリモート・コミット・プロバイダが通知をパブリッシュしたり、他のJVMから送信された通知をサブスクライブしたりするJMSトピック。ターゲットとなるJMSトピックはあらかじめデプロイされている必要があります。

JMSTopicConnectionFactory

JMSトピックを検索するために使用するjavax.jms.TopicConnectionFactoryインスタンスのJNDI名。

『Oracle WebLogic Server JMSの構成と管理』の接続ファクトリの構成に関する項では、javax.jms.TopicConnectionFactoryのインスタンスであるWebLogic JMS接続ファクトリweblogic.jms.ConnectionFactoryについて説明しています。接続ファクトリの構成については、このトピックを参照してください。

NotificationProperties

JNDI InitialContextの作成時に渡すキーと値のプロパティのカンマ区切りのリスト。形式はxxKey=xxValue, xxKey=xxValue。以下のプロパティを指定する必要があります。

- java.naming.provider.url - 使用するサービス・プロバイダの構成情報を指定するためのプロパティ。このプロパティの値にはURL文字列を含める必要があります。例:

iiops://localhost:7002

- java.naming.factory.initial - 使用する初期コンテキスト・ファクトリを指定するためのプロパティ。このプロパティの値は、初期コンテキストを作成するファクトリの完全修飾クラス名にします。例:

weblogic.jndi.WLInitialContextFactory

JNDIUserName

JNDIにアクセスするセキュリティ・レルム内の有効なユーザーのID。

JNDIPassword

JNDIUserName属性で指定したユーザー名のパスワード。

JMSExceptionReconnectAttempts

JMSシステムがKodoに深刻な接続エラーを通知した場合に試行される再接続の回数。デフォルトは0で、エラーはログに記録されるが再接続は試行されません。

詳細は、以下のトピックを参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトピックの構成に関する項

- 『Oracle WebLogic Server JMSの構成と管理』の基本JMSシステム・リソースの構成に関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのRDBMSセキュリティ・ストアの構成に関する項

- Oracle WebLogic Server MBeanリファレンスのRDBMSSecurityStoreMBeanに関する項

障害発生時のJMS接続リカバリの構成

通常、複数ノード・ドメインの各WebLogic Serverインスタンスに含まれているWebLogicセキュリティ・サービスは起動時にJMSサーバーに接続します。RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダがセキュリティ・データを変更した場合は、JMSを介してすべてのWebLogic Serverインスタンスに通知され、各WebLogic ServerインスタンスのWebLogicセキュリティ・サービスで使用されているローカル・キャッシュは、その変更を反映するために同期化されます。

正常に起動されたWebLogic ServerインスタンスでJMS接続が失敗すると、そのサーバー・インスタンスに関連付けられたWebLogicセキュリティ・サービスはJMS接続のリカバリ・プロセスを開始します。リカバリ・プロセスでは次の再接続の試行までに1秒間スリープします。JMSExceptionReconnectAttemptsプロパティで構成された再接続の試行回数に達した後もJMS接続エラーが続く場合、リカバリ・プロセスは停止します。再接続はそれ以上試行されません。つまり、あるWebLogic Serverインスタンスでセキュリティ・データが変更されても、他のWebLogic ServerインスタンスのWebLogicセキュリティ・サービスで管理されているローカル・キャッシュはその変更を反映するために同期化されません。ただし、他の手段(サーバーの再起動など)でJMS接続が正常に回復されると、それらのキャッシュは同期化されます。

WebLogic Serverインスタンスの起動時にJMS接続が正常に開始されない場合は、再接続を試行するタイマー・タスクが自動的に開始されます。接続が正常に行われると、タイマー・タスクは取り消されます。このタイマー・タスクに関する2つのシステム・プロパティを構成できます。

- com.bea.common.security.jms.initialConnectionRecoverInterval
接続リカバリ・タスクを実行するまでの遅延を指定します(ミリ秒単位)。デフォルト値は1000で、接続リカバリ・プロセスは1秒間遅延した後に実行されます。

- com.bea.common.security.jms.initialConnectionRecoverAttempts
タイマー・タスクを取り消すまでに試行される再接続の最大回数を指定します。デフォルト値は3600で、再接続が3600回試行されるとタイマー・タスクは取り消されます。それ以上の再接続は試行されません。

上記のシステム・プロパティで指定した値を掛け合わせると、接続ポーリングの最大期間を計算できます。たとえば、2つのプロパティのデフォルト値を掛け合わせると(1000ミリ秒の遅延に3600回の再接続試行回数を掛ける)、最大ポーリング期間は1時間となります。

RDBMSセキュリティ・ストアを使用するドメインのアップグレード

RDBMSセキュリティ・ストアを使用するドメインをアップグレードするには、RDBMSセキュリティ・ストアを構成した新しいドメインを作成することをお薦めします。新しいドメインを作成した後で、古いドメインのセキュリティ・レルムからセキュリティ・データをエクスポートして、新しいドメインのセキュリティ・レルムにインポートする必要があります。RDBMSセキュリティ・ストアを使用するドメインのセキュリティ・レルムにセキュリティ・データをインポートすると、RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダのデータは、自動的にそのデータ・ストアにロードされます。RDBMSセキュリティ・ストアを使用しないセキュリティ・プロバイダのデータは、それらのプロバイダが通常デフォルトで使用するストアに自動的にインポートされます。

セキュリティ・レルムから別のセキュリティ・レルムに個々のセキュリティ・プロバイダを選択的に移行することもできます。ただし、RDBMSセキュリティ・ストアを使用するドメインにセキュリティ・データを移行する場合は、セキュリティ・レルムのデータを1回の操作で移行することをお薦めします。

セキュリティ・レルムの移行の詳細は、以下のトピックを参照してください。

- セキュリティ・データの移行

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・レルムからのデータのエクスポートに関する項およびセキュリティ・レルムへのデータのインポートに関する項

11 IDと信頼の構成

この章では、WebLogic Server 10.3.6のIDおよび信頼を構成する方法について説明します。

この章の内容は以下のとおりです。

- 秘密鍵、デジタル証明書、信頼性のある認証局

- IDキーストアと信頼キーストア

- WebLogic Serverが信頼を検索する方法

- IDと信頼の構成: 主な手順

- キーストアの作成: サンプル

- 証明書コールバック・ハンドラを使用したエンド・ユーザー証明書の検証

この章の手順を実行する前に、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。

秘密鍵、デジタル証明書、信頼性のある認証局

サーバーのIDと信頼は、秘密鍵、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。

SSLでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバー用に公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号化できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。

公開鍵は、公開鍵のオーナーに関する情報(名前、番地、電子メール・アドレスなど)とともに、デジタル証明書に組み込まれます。秘密鍵とデジタル証明書によって、サーバーにIDが提供されます。

デジタル証明書に組み込まれたデータは認証局(CA)によって検証され、その認証局のデジタル証明書でデジタル署名されます。よく知られる認証局には、EntrustやSymantec Corporationがあります。信頼性のあるCA証明書によって、証明書の「信頼」が確立されます。

SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。

サーバーでは、秘密鍵、それに一致する公開鍵が含まれているデジタル証明書、および少なくとも1つの信頼性のある認証局(CA)の証明書が必要です。WebLogic Serverでは、以下のソースからの秘密鍵、デジタル証明書、信頼性のあるCA証明書をサポートしています。

- WL_HOME\server\libディレクトリとJAVA_HOME\jre\lib\securityディレクトリにある、デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書。

注意:
デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。

- keytoolユーティリティによって作成されるWebLogic Serverの秘密鍵と自己署名デジタル証明書。次の点に注意してください。

- 秘密鍵と自己署名デジタル証明書を作成したら、keytoolを使用して証明書署名リクエスト(CSR)を生成します。CSRを認証局に提出すると、WebLogic Server用のデジタル証明書を取得できます。

- keytoolユーティリティを使用して、自己署名デジタル証明書を新しいデジタル証明書に更新できます。

- 本番環境でWebLogic Serverを使用している場合、keytoolユーティリティを使用して信頼とIDを取得できます。

詳細は、「keytoolユーティリティの使い方」を参照してください。

- デジタル証明書と秘密鍵は、CertGenユーティリティによって生成されます。ただし、これらは本番環境ではなく、開発環境におけるデモンストレーションやテスト目的にのみ使用する必要があります。CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します。(WebLogic Serverが提供するデモ用のデジタル証明書では、マシンのデフォルト・ホスト名がホスト名として使用されます。)CertGenユーティリティを使用して秘密鍵とデジタル証明書を取得する方法については、「CertGenユーティリティの使い方」を参照してください。

注意:
Certificate Request Generatorサーブレットは非推奨になりました。「keytoolユーティリティの使い方」で示されるように、keytoolユーティリティをかわりに使用します。

IDと信頼のサポートされるフォーマット

PEM (Privacy Enhanced Mail)フォーマットは、秘密鍵、デジタル証明書、および信頼性のある認証局(CA)証明書向けの推奨フォーマットです。推奨されるキーストアのフォーマットはJKS (Javaキーストア)です。

.pemフォーマットのファイルは次の行で始まります:

----BEGIN CERTIFICATE----

そして、次の行で終わります:

----END CERTIFICATE----

.pemフォーマット・ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。ファイル内の証明書の順序は重要です。サーバーのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。その後、発行者の証明書と続きます。チェーン内の各証明書の次には、その発行者の証明書が来ます。チェーン内の最後の証明書がそのチェーンの自己署名型(自己発行型)のルート証明書である場合、チェーンは終了していると見なされます(チェーンは必ずしも終了している必要はありません)。

非推奨のファイル・ベースの秘密鍵、デジタル証明書、および信頼性のあるCA証明書を使用する場合、WebLogic ServerではPEMまたはDER (distinguished encoding rules)フォーマットのデジタル証明書を使用できます。

.derフォーマットのファイルには1つの証明書のバイナリ・データが含まれます。.pemファイルは複数の証明書用に使用できますが、.derファイルは1つの証明書用にのみ使用できます。

MicrosoftもCAとしてよく使用されます。Microsoftはp7bフォーマットで信頼性のあるCA証明書を発行します。この信頼性のあるCA証明書をWebLogic Serverで使用する前には、必ずPEMに変換しておく必要があります。詳細は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。

秘密鍵ファイル(キーストアに格納されていない秘密鍵)は、PKCS#5/PKCS#8 PEMフォーマットである必要があります。

WebLogic Serverの他のバージョンで使用していた秘密鍵およびデジタル証明書は、WebLogic Serverのこのバージョンでも使用できます。秘密鍵およびデジタル証明書をDER (distinguished encoding rules)フォーマットからPEM (privacy-enhanced mail)フォーマットに変換します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「WebLogic Server Javaユーティリティの使用」にあるder2pemユーティリティの説明を参照してください。

ファイルの変換後には、デジタル証明書ファイルに-----BEGIN CERTIFICATE-----ヘッダーと-----END CERTIFICATE-----フッターがあることを確認します。そうでない場合、デジタル証明書は機能しません。

注意:
OpenSSLは、生成するPEM証明書にヘッダーを追加します。このような証明書をWebLogic Serverで使用するには、テキスト・エディタを使用して「-----BEGIN CERTIFICATE-----」の前の部分を証明書から削除します。

IDキーストアと信頼キーストア

SSLを構成する場合には、IDと信頼の格納方法を決定する必要があります。IDと信頼の両方で1つのキーストアを使用することはできますが、IDキーストア(秘密鍵とデジタル証明書のペア)と信頼キーストア(信頼性のあるCA証明書)ではセキュリティ要件が異なる場合があるので、IDと信頼のそれぞれに個別のキーストアを使用することをお薦めします。例:

- 信頼キーストアの場合、キーストア内に証明書(機密情報以外のデータ)のみが必要です。ただし、IDキーストアの場合、キーストア内に証明書と秘密鍵(機密データ)を追加します。

- 信頼キーストアはネットワーク上で配布できるが、IDキーストアは企業のポリシーによって企業ネットワークへの参加を禁止される場合があります。

- 信頼キーストアでは書込み保護のみが必要とされますが、IDキーストアでは、無認可ユーザーによる読込みと書込みの両方をオペレーティング・システムにより保護できます。

- 通常、IDキーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されません。

一般的にドメイン内のシステムには、それぞれのサーバーIDが付けられることが多い一方で、同じ信頼ルールが適用されます(つまり、信頼性のあるCAの同じセットが使用されます)。IDには秘密鍵が必要であり、秘密鍵はあるシステムから別のシステムへコピーできません。そのため、システムごとに異なるIDキーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバーIDのみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。

IDはnCipherなどのハードウェア・キーストアに格納する場合も多くあります。信頼ストアには秘密鍵ではなく証明書のみが含まれるため、信頼をファイル・ベースのJDKキーストアに格納してもセキュリティの問題はありません。

WebLogic Serverが信頼を検索する方法

WebLogic Serverでは、信頼性のあるCA証明書をロードするときに次のアルゴリズムが使用されます。

1. キーストアが-Dweblogic.security.SSL.trustedCAkeystoreコマンド・ライン引数で指定されている場合は、そのキーストアから信頼性のあるCA証明書がロードされます。

2. キーストアが構成ファイル(config.xml)で指定されている場合は、その指定されたキーストアから信頼性のあるCA証明書がロードされます。サーバーでDemoTrustが構成されている場合、信頼性のあるCA証明書はWL_HOME\server\lib\DemoTrust.jksキーストアおよびJDK cacertsキーストアからロードされます。

3. 信頼性のあるCAファイルが構成ファイル(config.xml)で指定されている場合は、そのファイルから信頼性のあるCA証明書がロードされます(これは6.x SSL構成との互換性のみを目的としています)。

4. 上記以外の場合、信頼性のあるCA証明書はWL_HOME\server\lib\cacertsキーストアからロードされます。

IDと信頼の構成: 主な手順

サーバー用にIDおよび信頼を作成するには:

1. デジタル証明書、秘密鍵、および信頼性のあるCA証明書を取得します。「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得」を参照してください。

2. IDキーストアおよび信頼キーストアを作成します。「キーストアの作成および秘密鍵と証明書の読込みに使用するツールとユーティリティ」を参照してください。

3. 秘密鍵、デジタル証明書、および信頼性のあるCA証明書をキーストアに格納します。「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。

注意:
推奨されるキーストアのフォーマットはJKS (Javaキーストア)です。WebLogic Serverでは、後方互換性を保持するためだけに、ファイルまたはWebLogicキーストア・プロバイダに格納された秘密鍵と信頼性のあるCA証明書がサポートされています。

4. WebLogic Serverのキーストアを構成します。「WebLogic Server用のIDおよび信頼キーストアの構成」を参照してください。

注意:
WebLogic Serverは、デフォルトではCerticomベースのSSL実装で構成されています。ただし、サーバー・インスタンスによって使用されているID証明書がSHA-256署名アルゴリズムで署名されている場合は、SSLを有効化した後にWebLogic Serverが起動しない可能性があります。詳細は、「SSL構成後におけるWebLogic Serverの起動の失敗」を参照してください。

秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得

WebLogic Server環境用の秘密鍵、デジタル証明書、信頼性のあるCA証明書を取得するための選択肢は複数あります。選択の際には、次の検討事項に注意してください。

- CertGenユーティリティ、keytoolユーティリティ、またはEntrustやSymantec Corporationなどの信頼できるベンダーから鍵、証明書、信頼性のあるCAアーティファクトを取得できます。ただし、本番環境の場合、EntrustやSymantec Corporationなどの信頼できる認証局からのみ秘密鍵やデジタル証明書を取得する必要があります。

- WebLogic Serverに用意されているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用することもできます。ただし、これらは開発環境でのみ使用する必要があります。

この項では、鍵、証明書、および信頼性のあるCA証明書を取得するためのツールと方法を説明します。次の内容について説明します。

- keytoolユーティリティの使い方

- CertGenユーティリティの使い方

- 独自の認証局の使い方

- Microsoft p7bフォーマットからPEMフォーマットへの変換

- Webブラウザのデジタル証明書の取得

- 証明書チェーンの使い方(非推奨)

keytoolユーティリティの使い方

keytoolとは、鍵と証明書を管理するためのユーティリティです。これによってユーザーは、デジタル署名を使用して、独自の秘密/公開鍵ペア、および自己認証(ここでは、ユーザーが自分自身を他のユーザーやサービスに証明すること)またはデータ整合性や認証サービスに使用できる関連証明書を管理できます。また、ユーザーは通信ピアの秘密鍵(証明書の形式)をキャッシュすることも可能になります。

キー・ペア、自己署名サーバー証明書および信頼性のあるCA証明書を取得するためにkeytoolを使用する例については、「キーストアの作成: サンプル」を参照してください。keytoolの包括的な詳細は、「keytool - 鍵および証明書管理ツール」(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。

注意:
keytoolユーティリティを使用する場合、デフォルトのキー・ペア生成アルゴリズムはDSA (Digital Signature Algorithm)です。WebLogic ServerではDSAをサポートしていません。WebLogic Serverを使用する場合には、別のキー・ペア生成および署名アルゴリズムを指定します。

表11-1に、WebLogic ServerでJKSキーストアを作成および使用する場合のkeytoolコマンドを示します。この表では、オプションを囲むブラケットは、コマンドラインでオプションが指定されていない場合に、ユーザーが値を入力するように求められることを示します。

警告:
keytoolコマンドには、表11-1で示すように、パスワードを指定するためのオプションが含まれますが、コマンドラインには暗号化していないパスワードを決して入力しないでください。かわりに、次の例で示すように、コマンド入力後にkeytoolから必要なパスワードの入力を求めるように許可する必要があります。ユーザーが入力する部分は太字で示されています。

C:\DOMAIN_NAME>keytool -genkeypair -keystore MyKeyStore
Enter keystore password:
Re-enter new password:

コマンドライン・オプションで指定されるパスワードとは異なり、プロンプトのレスポンスとして入力するパスワードは、コマンド・ウィンドウ内でエコーされず、ログに取り込まれないので、パスワードの入力でセキュリティが確保されます。

表11-1 一般的に使用されるkeytoolコマンド

コマンド

説明

keytool -genkeypair -keystore keystorename

-storepass keystorepassword

キーストア内のキー・ペア(公開鍵と関連する秘密鍵)および自己署名デジタル証明書を生成します。キーストアが存在しない場合、作成します。

keytool -importcert -alias aliasforprivatekey
-file privatekeyfilename.pem
-keyfilepass privatekeypassword
-keystore keystorename -storepass keystorepassword

自己署名デジタル証明書を信頼性のあるCAによって署名された証明書で更新します。

keytool -importcert -alias rootCA
-trustcacerts -file RootCA.pem
-keystore trust.jks -storepass keystorepassword

keytool -importcert -alias intermediate
-trustcacerts -file Intermediate.pem
-keystore keystorename -storepass keystorepassword

中間的なCA証明書を格納するために使用されるカスタム・キーストアを作成します。

- 最初のkeytoolコマンドでキーストアtrust.jksが作成されます。このキーストアはルートCA証明書を格納します。

- 2番目のkeytoolコマンドで中間的なCA証明書がtrust.jksにインポートされます。

これによりWebLogic ServerのSSL実装は、SSLハンドシェーク中にサーバーのパブリック証明書と一緒に中間的な証明書をクライアントに転送できるようになります。

keytool -importcert -alias aliasfortrustedca
-trustcacerts -file trustedcafilename.pem
-keystore keystorename -storepass keystorepassword

信頼性のあるCA証明書をキーストアにロードします。キーストアが存在しない場合、作成します。

keytool -certreq -alias alias
-sigalg sigalg
-file certreq_file
-keyfilepass privatekeypassword
-storetype keystoretype
-keystore keystorename
-storepass keystorepassword

PKCS#10フォーマットによる証明書署名リクエスト(CSR)と秘密鍵による自己署名デジタル証明書を生成します。

CSRを指定されたcertreq_fileに格納し、証明書/秘密鍵のペアを指定されたキーストアに指定された別名でキー・エントリとして格納します。

keytool -list -keystore keystorename

キーストアのコンテンツを表示します。

keytool -delete -keystore keystorename

-storepass keystorepassword

-alias privatekeyalias

指定された別名によって識別されたエントリをキーストアから削除します。

keytool -help

keytoolのオンライン・ヘルプを表示します。

CertGenユーティリティの使い方

注意:
CertGenユーティリティで生成されたデジタル証明書と秘密鍵は、本番環境用ではなくデモまたはテスト目的でのみ使用するようにします。CertGenの使用上の制限に関する重要な情報については、「CertGenを使用する場合の制限事項」を参照してください。

CertGenユーティリティでは、CA証明書と、生成された証明書を発行するためのキーを指定する、コマンド・ライン・オプションを使用できます。CertGenユーティリティによって生成されたデジタル証明書には、デフォルトではそれらが生成されたマシンのホスト名のみが共通名フィールド(cn)の値として保持され、完全修飾DNS名は保持されません。コマンド・ライン・オプションを使用すると、cnの値と他のサブジェクト・ドメイン名(DN)フィールド(orgunit、organization、locality、state、countrycodeなど)の値を指定できます。

CertGenユーティリティでは、公開証明書と秘密鍵ファイルがPEMおよびDERフォーマットで生成されます。Windowsでは、.derファイルをダブルクリックすると、生成されたデジタル証明書の詳細を確認できます。.pemファイルは、WebLogic Serverを起動するときやクライアントでデジタル証明書を使うときに使用できます。

CertGenユーティリティではデフォルトで、CertGenCA.derおよびCertGenCAKey.derという、デモ用のデジタル証明書ファイルおよび秘密鍵ファイルが使用されます。CertGenユーティリティは、カレント・ディレクトリまたはWL_HOME/server/lib directoryディレクトリからこれらのファイルを検索します。これについてはweblogic.homeシステム・プロパティまたはCLASSPATHに指定されています。これらのファイルを使用する場合、コマンド・ラインでCAファイルを指定する必要はありません。かわりに、コマンド・ラインでCAファイルを指定することもできます。

コマンド構文と例

CertGenユーティリティの構文と引数については、『Oracle WebLogic Serverコマンド・リファレンス』のCertGenに関する項を参照してください。

CertGenユーティリティで証明書および秘密鍵を生成し、その後ImportPrivateKeyユーティリティでキーストアを作成し秘密鍵を格納する例については、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。

注意:
-cnオプションでホスト名を明示的に指定しない場合、CertGenはJDK InetAddress.getHostname()メソッドを使用して、サブジェクト共通名に指定するホスト名を取得します。getHostName()メソッドの動作は、プラットフォームによって異なります。Solarisなどのプラットフォームでは完全修飾ドメイン名(FQDN)を返し、Windows NTなどでは短いホスト名を返します。Solarisでは、InetAddress.getHostname()の結果は、ホスト・エントリが/etc/nsswitch.confファイルでどのように構成されているかで決まります。
WebLogic Serverがクライアントとして動作している場合(およびデフォルトでホスト名検証が有効になっている場合)、URLに指定されるホスト名がサーバーの証明書のサブジェクト共通名と一致している必要があります。そうでないと、接続は失敗します。

CertGenを使用する場合の制限事項

WebLogic Serverは、デフォルトではDemoIdentity.jksキーストアを使ってインストールおよび構成されます。このキーストアには、WebLogic Serverのデモ用のパブリック証明書と秘密鍵が格納されています。この証明書とキーはCertGenによって作成されますが、CertGenのデフォルト・オプションでは、共通名フィールド(cn)に完全修飾DNS名ではなくホスト名のみが格納されます。そのため、SSL接続を確立しようとしたときに、状況によってはホスト名の検証例外が発生します。この節では、この制限事項とその回避策について説明します。

マルチサーバー・ドメインでデモ用の証明書を使用している場合、管理対象サーバーと管理サーバーの間にSSL接続を確立できないと、管理対象サーバー・インスタンスの起動に失敗します。その場合、次のようなエラー・メッセージが生成されます。

BAD_CERTIFICATE alert was
received from node-name.avitek.com - xxx.yy.zzz.yyy. Check the peer to
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.

上のエラーが発生するのは、このホスト名検証によって、証明書のcnフィールドの値とSSLサーバー(SSL接続を許可するサーバー)の完全修飾DNS名が比較されるためです。これらの名前が一致しない場合はSSL接続が中断されます。

WebLogicドメインでデモ用のID証明書を使用している場合は、以下の方法でエラーを回避できます。

- 証明書のcnフィールドに表示されるホスト名として、ドメインの各WebLogic ServerインスタンスのSSLリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスの使用は避けてください。この回避策は、次の2つの手順で行われます。

1. 構成ウィザードを使用してWebLogicドメインを作成する場合、証明書のcnフィールドに表示される簡易ホスト名として、各WebLogic Serverインスタンスのリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスは使用しないでください。たとえば、証明書のホスト名がavitek01の場合、サーバー・インスタンスのリスニング・アドレスをavitek01と指定します。

2. 実行時にサーバー・インスタンスのSSLリスニング・アドレスを指定する場合、証明書のcnフィールドに指定した該当サーバーのホスト名にURLも一致するようにします。例:

https://avitek01:7002

- 管理対象サーバー・インスタンスを起動する際に、startManagedWebLogicスクリプトへのパラメータとして管理サーバーのSSLリスニング・アドレスを渡します。URLは、ドメイン接尾辞を除いた形式で指定する必要があります。例:

C:\mydomain\bin> startManagedWebLogic.cmd https://admin01:7002

- ホスト名検証を無効にします。ホスト名検証を無効にすると、接続の確立に使用するURL内のホスト名と、SSL接続の一部としてサーバーから返送されるデジタル証明書のホスト名が一致しているかどうかがチェックされなくなります。
ホスト名検証を無効にするには、次のsetDomainEnvスクリプトのようなコマンドを含めます。

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.security.SSL.ignoreHostnameVerification=true

ホスト名検証の構成については、「ホスト名検証の使い方」を参照してください。

注意:
本番環境でデモ用のデジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくありません。

独自の認証局の使い方

多くの企業が独自の認証局として機能しています。それらの信頼性のあるCA証明書をWebLogic Serverで使用するには:

1. 信頼性のあるCA証明書がPEMフォーマットであることを確認します。

- 信頼性のあるCA証明書がDERフォーマットの場合は、der2pemを使用して変換します。

- 信頼性のあるCA証明書がMicrosoftによって発行されている場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。

- 信頼性のあるCA証明書がカスタム・ファイル・タイプの場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」にある手順で、信頼性のあるCA証明書をPEMフォーマットに変換します。

2. 信頼キーストアを作成し、信頼性のあるCA証明書をその中に保存します。詳細は、「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。

3. その信頼キーストアを使用するようにWebLogic Serverを構成します。詳細は、「本番用のキーストアの構成」を参照してください。

Microsoft p7bフォーマットからPEMフォーマットへの変換

Microsoftから発行されるデジタル証明書のフォーマット(p7b)は、WebLogic Serverでは使用できません。次の例は、p7b (PKCS#7)フォーマットのデジタル証明書をWindows XPでPEMフォーマットに変換します。

1. Windowsエクスプローラで、変換するファイル(filename.p7b)を選択します。ファイルをダブルクリックすると、「証明書」ウィンドウが表示されます。

2. 「証明書」ウィンドウの左ペインで、ファイルを展開します。

3. 「証明書」フォルダを展開して、証明書のリストを表示します。

4. PEMフォーマットに変換する証明書を選択します。証明書を右クリックして「すべてのタスク」→「エクスポート」を選択します。証明書のエクスポート・ウィザードが表示されます。

5. ウィザードで「次へ」をクリックします。

6. 「Base-64 encoded X.509 (.CER)」(.CER)オプションを選択します。「次へ」をクリックします(Base-64エンコードはPEMフォーマットです。)

7. 「ファイル名」フィールドで、変換したデジタル証明書の名前を入力します。「次へ」をクリックします。

注意:
ウィザードでは出力ファイルに.cer拡張子が付加されます。.cer拡張子はBase64でエンコードされた証明書およびDER証明書の両方に付加される汎用的な拡張子です。ウィザードの終了後にこの拡張子を.pemに変更できます。

8. 設定が正しいことを確認します。設定が正しい場合は「完了」をクリックします。正しくない場合は、「戻る」をクリックして必要な修正を行います。

注意:
証明書チェーンが含まれているp7b証明書ファイルの場合、発行元のPEMデジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Serverで使用できます。

Webブラウザのデジタル証明書の取得

セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。

受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。後で認証がリクエストされた場合に、このデジタル証明書を提示します。

デジタル証明書の取得プロセスの一部として、Webブラウザは公開鍵/秘密鍵の組合せを生成します。秘密鍵は非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密鍵を暗号化できます。パスワードは格納されません。秘密鍵を暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。

注意:
Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。

証明書チェーンの使い方(非推奨)

注意:
ファイル・ベースの証明書チェーンの使用は非推奨になりました。証明書チェーン全体がキーストアにインポートされるようになりました。次の手順は、後方互換性のみを目的に説明しています。

WebLogic Serverで証明書チェーンを使用するには:

1. すべてのデジタル証明書が必ずPEMフォーマットであるようにします。DERフォーマットの場合は、der2pemユーティリティを使用して変換できます。Microsoftによって発行されたデジタル証明書を使用する場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。この節の手順に従うことで、他のタイプのデジタル証明書を変換できます。デジタル証明書はBase64フォーマットで保存します。

2. テキスト・エディタを開き、すべてのデジタル証明書ファイルを1つのファイルに含めます。順序は重要です。サーバーのデジタル証明書を、ファイル内の最初のデジタル証明書にする必要があります。そのデジタル証明書の発行元が次のファイルとなり、自己署名のルート認証局(CA)の証明書にたどり着くまで続くようにします。このデジタル証明書をファイル内の最後の証明書にする必要があります。
デジタル証明書の間に空白行を入れないようにします。

3. WebLogic Server管理コンソールの「構成」→「SSL」ページの「サーバー証明書のファイル名」フィールドで、このファイルを指定します。

例11-1に、証明書チェーンのサンプルを示します。

例11-1 証明書チェーンを含むファイルのサンプル

-----BEGIN CERTIFICATE-----
MIICyzCCAjSgAwIBAgIBLDANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUB
gNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJk
RlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4
XDTAyMTEwMTIwMDIxMloXDTA2MTAxNTIwMDIxMlowgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYD
VQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MRkwFwYDVQQDExB3Z
WJsb2dpYy5iZWEuY29tMR4wHAYJKoZIhvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAo
GBAMJX8nKUgsFej8pEu/1IVcHUkwY0c2JbBzOryu3sce4QjX+rGxiCjoPm2MY=yts2BvonuJ6CztdZf8B/LBEWCz+qRrtdFn9
mKSZWGvrAkmMPz2RhXEOThpoRo5kZz2FQ9XF/PxIJXTYCM7yooRBwXoKYjquRwiZNtUiU9kYi6Z3prAgMBAAEwDQYJKoZIhvc
NAQEEBQADgYEAh2eqQGxEMUnNTwEUD

0tBq+7YuAkjecEocGXvi2G4YSoWVLgnVzJoJuds3c35KE6sxBe1luJQuQkE9SzALG/6lDIJ5ctPsHFmZzZxY7scLl6hWj5ON8
oN2YTh5Jo/ryqjvnZvqiNIWe/gqr2GLIkajC0mz4un1LiYORPig3fBMH0=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIC+jCCAmOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUB
gNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJk
RlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4
XDTAyMTEwMTIwMDIxMVoXDTA2MTAxNjIwMDIxMVowgbYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYD
VQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MS8wLQYDVQQDEyZEZ
W1vIENlcnRpZmljYXRlIEF1dGhvcml0eSBDb25zdHJhaW50czEfMB0GCSqGSIb3DQEJARYQc2VjdXJpdHlAYmVhLmNvbTCBnz
ANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3ynD8l5JfLob4g6d94dNtI0Eep6QNl9bblmswnrjIYz1BVjjRjNVal9fRs+8jvm
85kIWlerKzIMJgiNsj50WlXzNX6orszggSsW15pqV0aYE9Re9K

CNNnORlsLjmRhuVxg9rJFEtjHMjrSYr2IDFhcdwPgIt0meWEVnKNObSFYcCAwEAAaMWMBQwEgYDVR0TAQH/BAgwBgEB/wIBAT
ANBgkqhkiG9w0BAQQFAAOBgQBS+0oqWxGyqbZO028zf9tQT2RKojfuwywrDoGW96Un5IqpFnBHIu5atliJo3OUpiH18KkwLN8
DVP/3t3K3O3kXdIuLbqAL0i5xyBlAhr7gE5eVhIyeMg7ETBPLyGO2BF13Y24LlsO+MX9jW7fxMraPN608QeJXkZw0E0cGwrw2AQ==

-----END CERTIFICATE-----

秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納

秘密鍵、デジタル証明書、および信頼できるCA証明書を取得した後は、それらを格納し、WebLogic Serverでそれらを使用してIDを検索および確認できるようにする必要があります。秘密鍵、秘密鍵に関連付けられたデジタル証明書、および信頼できるCA証明書は、キーストアに格納されます。続いて、WebLogic Serverで当該キーストアを構成する必要があります。

この項では、次のトピックについて説明します。

- デモンストレーション用キーストアの使用

- キーストアの作成および秘密鍵と証明書の読込みに使用するツールとユーティリティ

- クライアントのデモ証明書の構成

keytoolユーティリティを使用してキーストアを作成し、鍵と証明書をその中に保存する際のステップ・バイ・ステップの例に関しては、「キーストアの作成: サンプル」を参照してください。

デモンストレーション用キーストアの使用

デフォルトでは、WebLogic Serverは2つのキーストアを使用して構成され、WL_HOME\server\libディレクトリに配置されます。

- DemoIdentity.jks - WebLogic Serverのデモ用秘密鍵が格納されます。このキーストアには、WebLogic ServerのIDが格納されます。

- DemoTrust.jks - WL_HOME\server\lib\DemoTrust.jksキーストアおよびJDK cacertsキーストアからの信頼性のある認証局が格納されます。このキーストアによってWebLogic Serverの信頼が確立されます。

開発目的やテスト目的の場合は、このキーストア構成で十分です。ただし、デモ用キーストアは本番環境では使用しないでください。デモ用キーストア内のデジタル証明書および信頼性のあるCA証明書はWebLogic Serverのデモ用認証局によって署名されるので、デモ用キーストアを使用するインストールされたWebLogic Serverはデモ用キーストアを使用するすべてのインストールされたWebLogic Serverを信頼することになります。使用するインストールのみが相互に信頼するセキュアな環境を作成する必要があります。

キーストアの作成および秘密鍵および証明書の読込みに使用するツールおよび
ユーティリティ

キーストアは、秘密鍵とデジタル証明書のペアおよび信頼性のあるCA証明書を安全に保存および管理するためのメカニズムです。以下のメカニズムを使用して、キーストアを作成し、秘密鍵と信頼性のあるCA証明書をそのキーストアにロードします。

- WebLogic ImportPrivateKeyユーティリティ。ImportPrivateKeyユーティリティを使用すると、秘密鍵およびデジタル証明書のファイルを取得してキーストアにロードできます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。

- keytoolユーティリティ。keytoolユーティリティを使用すると、キー・ペア(公開鍵と関連する秘密鍵)と自己署名デジタル証明書を生成し、キーストアにそれらを保存できます。keytoolユーティリティでは新しいキーペアとデジタル証明書を生成してキーストアに追加できますが、既存の秘密鍵をファイルから取得してキーストアにインポートすることはできません。かわりに、WebLogic ImportPrivateKeyユーティリティを使用してください。

注意:
keytoolユーティリティでは、信頼性のあるCA証明書をファイルからキーストアにインポートできます。

キーストアを作成するためにkeytoolを使用する方法のステップ・バイ・ステップの手順説明については、「キーストアの作成: サンプル」を参照してください。

- カスタム・ユーティリティ。WebLogic Serverでは、カスタム・ツールまたはカスタム・ユーティリティによって作成されたキーストアを使用できます。これらのユーティリティの作成方法および使用方法については、このドキュメントでは取扱いません。

キーストアのすべての秘密鍵エントリには、固有の別名を介してWebLogic Serverからアクセスできます。別名は、秘密鍵をキーストアにロードするときに指定します。別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。秘密鍵の別名は、WebLogic Server管理コンソールの「構成」>「SSL」ページの「秘密鍵の別名」フィールドで指定します。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。

WebLogic Serverによって信頼されているものとして識別される、キーストア内の認証局はすべて信頼されます。

クライアントのデモ証明書の構成

開発モードにおいてクライアント(Eclipseなど)とWebLogic Serverの間でSSLを使用するには、クライアントとサーバーの両方のJVMでデモ証明書を構成します。

1. MW_HOME/wlserver_10.3/server/lib/cacertsを、クライアントのJVMのjre/lib/securityディレクトリにコピーします。たとえば、EclipseをデフォルトのJDKで使用している場合は、cacertsをMW_HOME/jdk160_11/jre/lib/securityにコピーします。

2. MW_HOME/wlserver_10.3/server/lib/cacertsを、WebLogic ServerのJVMのjre/lib/securityディレクトリにコピーします。たとえば、ドメインでJRockitを使用している場合は、cacertsをMW_HOME/jrockit_160_05/jre/lib/securityにコピーします。

3. WebLogic Serverとクライアントの両方を再起動します。

別の方法として、cacertsファイルをコピーするかわりに、証明書をインポートすることもできます。

WebLogic Server用のIDおよび信頼キーストアの構成

この項には次のトピックが含まれます:

- 本番用のキーストアの構成

- WebLogicキーストア・プロバイダによってアクセスできるファイルまたはJKSキーストアに保存される鍵と証明書の構成

本番用のキーストアの構成

本番環境で使用するIDと信頼キーストアを作成したら、WebLogic Serverで構成する必要があります。次の任意の方法を使用してこれを実行できます。

- WebLogic Server管理コンソールの「構成」>「キーストア」ページ。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

- WLSTスクリプト。『Oracle WebLogic Scripting Tool』を参照してください。

- 新しいセキュリティ構成を作成するためのJava Management Extensions (JMX) API。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

WebLogicキーストア・プロバイダによってアクセスされるファイルまたは
JKSキーストアに保存される鍵と証明書の構成

後方互換性を保持するために、秘密鍵と信頼性のあるCA証明書をファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアに格納できます。さらに、信頼性のあるCA証明書はJKSキーストアにも格納できます。ファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアを使用する場合、WebLogic Server管理コンソールの「構成」>「SSL」ページでIDと信頼について指定できます。

キーストアの作成: サンプル

この項では、キーストアを作成し、鍵と証明書をその中に保存するためのkeytoolユーティリティの使用に関する例を示します。ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDキーストアと信頼キーストア」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項に示す各keytoolコマンド・オプションの詳細は、「keytool - 鍵および証明書管理ツール」(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。

キーストアを作成し、秘密鍵と証明書を使用して設定するには、次の手順を実行します。

1. MW_HOME/keystoresなどの、キーストアを保持するためのディレクトリを作成します。

2. 次のスクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。

DOMAIN_HOME/bin/setDomainEnv

前のパスでは、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。

3. 手順1で作成した、キーストアを保持するためのディレクトリに変更します。

4. 次のkeytoolコマンド構文を使用して、キーストアを作成します。また、このコマンドはキー・ペア(公開鍵と関連する秘密鍵)と秘密鍵の別名も作成します。

keytool -genkeypair -alias alias -keyalg RSA -keysize 1024 -dname dn -keystore keystore

前のコマンド構文では:

- aliasは、秘密鍵の別名を表します。

- dnは、秘密鍵の別名に関連付けられたX.500識別名を表します。

- keystoreは、作成されるキーストア名を表します。

例:

prompt> keytool -genkeypair -alias server_cert -keyalg RSA -keysize 1024
-dname "CN=server.avitek.com,OU=Support,O=Avitek,L=Reading,ST=Berkshire,C=GB"
-keystore keystore.jks

前のサンプルでは次の項目に注意してください。

- server.avitek.comは、WebLogic ServerホストとDNSドメイン名を表します。

- keytoolコマンドには、キーストアと秘密鍵のパスワードをそれぞれ指定するための-storepassと-keypassオプションが含まれますが、これらのコマンドライン・オプションを使用することは避けます。1つ以上のパスワードを求めるkeytoolコマンドを入力しても、それを受け渡すためのコマンドライン・オプションを省略するとき、後で入力するように求められます。ただし、コマンドライン・オプションで受け渡されたパスワードと異なり、プロンプトへのレスポンスで入力したパスワードはコマンド・ウィンドウに表示されず、ログにも取り込まれません。

- 指定する秘密鍵の別名とパスワードはメモしておき、パスワードは必ず安全な場所にのみ記録してください。

5. 手順4で作成したキーストアをバックアップ・コピーします。

6. キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreは、作成したキーストア名を表します。

keytool -list -v -keystore keystore

前のコマンドを入力すると、キーストアのパスワードを入力するよう求められます。たとえば、次のコマンドはkeystore.jksのコンテンツをリストで表示します。

prompt> keytool -list -v -keystore keystore.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: server_cert
Creation date: Sep 13, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Issuer: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Serial number: 4c8e1ad5
Valid from: Mon Sep 13 13:36:37 BST 2010 until: Sun Dec 12 12:36:37 GMT 2010
Certificate fingerprints:
MD5: 1A:4A:3B:42:7E:BD:94:65:67:0E:9B:02:28:90:D6:A8
SHA1: C1:53:48:50:EB:F1:FD:A0:DC:28:9F:EF:3B:C8:FB:22:82:9F:8E:EE
Signature algorithm name: SHA1with RSA
Version: 3

*******************************************
*******************************************

7. 次のkeytoolコマンド構文を使用して、証明書署名リクエスト(CSR)を作成します。

keytool -certreq -v -alias alias -file certreq_file -keystore keystore

前のコマンド構文では:

- aliasは、手順4で指定した秘密鍵の別名を表します。

- certreq_fileは、CSRを含むファイルの名前を表します。

- keystoreは、手順4で作成したキーストアを表します。

前のコマンドを使用してCSRを作成するとき、キーストアと秘密鍵のパスワードを入力するよう求められます。

たとえば、次のコマンドはserver.csrファイルの中にCSRを作成します。

prompt> keytool -certreq -v -alias server_cert -file server.csr -keystore keystore.jks

CSRファイルはPKCS#10形式でエンコードされ、次に類似しているように見えます。

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBtzCCASACAQAwdzELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA
4GA1UEBxMHUmVhZGluZzEPMA0GA1UEChMGT3JhY2xlMRAwDgYDVQQLEwdTdXBwb3J0
MR8wHQYDVQQDExZtYXJzaGFsbC51ay5vcmFjbGUuY29tMIGfMA0GCSqGSIb3DQEBA
QUAA4GNADCBiQKBgQCEopgMZp1lI6jWXxb1rM1kWIc1l8bhiV/0UTcsdKzeaSHxbO
SLO3Ed9kxNWAZgXaR9f5FBlwkaRJ+IR163e64v3SplHenxHfVRaHYWPZx4KlJz/6p
Yd1fAlF0PdQm1DNoFtKmCHVk/cRuvGRpsp38l7K2mYlyQ+GxH38llS7g3owIDAQAB
oAAwDQYJKoZIhvcNAQEFBQADgYEAD/sG1+rSI76OjihHg3WezT+VIbSRJxyly9nbx
4uwXbDHh8DGgQLAXV51C9ioaMrm+dM0eygVDDMESXFxvJiYipS/pphgYt1xDBgnEH
GcNiX3BnTaLNtzYlc5eAMsmbDlpk/qOxvQiH3bKN+UKYQlBXJZWPL6FusXu2LMTrk
zsY=
-----END NEW CERTIFICATE REQUEST-----

8. CSRファイルを任意の認証局(CA)に送信します。CAはWebLogic Server用のデジタル証明書を返します。この証明書はCAによって署名され、多くの場合、サーバー証明書としてのみ参照されます。

9. キーストア用に作成したディレクトリでは、サーバー証明書と共に、信頼できるルートCA証明書を個別のファイルに保存します。たとえば、サーバー証明書はserver.pemとして、ルートCA証明書はrootCA.pemとして保存できます。
CAに複数のルート証明書がある場合、rootCA2.pem、rootCA3.pemなどの名前を使用してキーストア・ディレクトリ内にも証明書を保存します。

10. 次のkeytoolコマンド構文を使用して、各ルートCA証明書をキーストアにインポートします。

keytool -importcert -v -noprompt -trustcacerts -alias alias -file rootca_file -keystore keystore

前の構文では:

- aliasは、ルートCA証明書の別名を表します。

- rootca_fileは、ルートCA証明書を含むファイルの名前を表します。

- keystoreは、キーストアの名前を表します。

たとえば、次のコマンドはrootcacertの別名を割り当て、rootCA.pemファイルのルートCA証明書をキーストアにインポートします。

prompt> keytool -importcert -v -noprompt -trustcacerts -alias rootcacert -file rootCA.pem -keystore keystore.jks
Enter keystore password:
Certificate was added to keystore
Storing keystore.jks

11. 次のkeytoolコマンド構文を使用して、サーバー証明書をキーストアにインポートします。

keytool -importcert -v -alias alias -file servercert_file -keystore keystore

前の構文では:

- aliasは、サーバー証明書の別名を表します。これは、手順4で割り当てた秘密鍵の別名と同一にする必要があります。

- servercert_fileは、サーバー証明書を含むファイルの名前を表します。

- keystoreは、キーストアの名前を表します。

たとえば、次のコマンドは手順4で割り当てた別名(server_cert)を使用して、サーバー証明書server.pemをキーストアにインポートします。

prompt> keytool -importcert -v -alias server_cert -file server.pem -keystore keystore.jks
Enter keystore password:
Certificate reply was installed in keystore[Storing keystore.jks
]

12. キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreはキーストア名を表します。

keytool -list -v -keystore keystore

例:

prompt> keytool -list -v -keystore keystore.jks
Enter keystore password:

Alias name: rootcacert
Creation date: Sep 13, 2010
Entry type: trustedCertEntry

Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Serial number: c47f4774c2ef014c
Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036
Certificate fingerprints:
MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC
SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26
Signature algorithm name: SHA1withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K.
0010: 72 B9 FC C1 r...
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.35 Criticality=false

[CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB]
SerialNumber: [ c47f4774 c2ef014c]
]

*******************************************
*******************************************

Alias name: server_cert
Creation date: Sep 13, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire,
C=GB
Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Serial number: e
Valid from: Mon Sep 13 14:02:00 BST 2010 until: Sat Sep 22 14:02:00 BST 2012
Certificate fingerprints:
MD5: CB:B8:07:32:22:B5:76:78:44:BB:94:D2:CE:EF:A3:CA
SHA1: 1E:3E:C6:BC:17:EB:43:50:19:01:0B:11:50:D8:23:60:21:B2:57:3E
Signature algorithm name: MD5withRSA
Version: 1
Certificate[2]:
Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB
Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Readin g, ST=Berkshire, C=GB
Serial number: c47f4774c2ef014c
Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036
Certificate fingerprints:
MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC
SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26
Signature algorithm name: SHA1withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K.
0010: 72 B9 FC C1 r...
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K.
0010: 72 B9 FC C1 r...
]

[CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB]
SerialNumber: [ c47f4774 c2ef014c]
]

*******************************************
*******************************************

証明書コールバック・ハンドラを使用したエンド・ユーザー証明書の検証

WebLogic Serverは、認証が成功/失敗したかどうかを判定するために発行されたリクエストを基に、エンド・ユーザーによって渡される情報の詳細を確認するための方法を提供します。この詳細情報には、エンド・ユーザーの証明書、件名、およびIPアドレスが含まれます。この機能は、weblogic.security.SSL.CertificateCallbackインタフェースによって提供され、これを実装して証明書コールバック・ハンドラを作成できます。WebLogic Serverで構成されている場合、セキュアなRMI接続(T3sやIIOPSプロトコルを使用するもの)を介してクライアント・リクエストを受け取ると、このコールバック・ハンドラが自動的に起動されます。

証明書コールバック・ハンドラがすべてのセキュアインバウンドRMI接続で機能するように構成するには、サーバー起動コマンドで受け渡されるWebLogic Serverシステム・プロパティとしてハンドラを定義します。

次のトピックでは、証明書コールバック・ハンドラが機能する仕組みおよびその実装と構成方法を説明します。

- エンド・ユーザー証明書コールバック・ハンドラが機能する仕組み

- 証明書コールバック実装の作成

- WebLogic Serverを使用した証明書コールバックの構成

エンド・ユーザー証明書コールバック・ハンドラが機能する仕組み

クライアントが、証明書コールバック・ハンドラを使用して構成されるWebLogic ServerインスタンスへのセキュアRMI接続を作成する場合、WebLogic Serverはコールバック・ハンドラを呼び出します。コールバックは接続リクエスト内のエンド・ユーザー情報の詳細を評価し、認証が正常に実行されたことを示すブール値を返します。

CertificateCallbackインタフェースは、CertificateCallbackInfoインスタンス上でvalidateメソッドを呼び出します。このインスタンスには、RMI接続リクエスト内にあるエンド・ユーザーからの次の情報を取得するためのメソッドが含まれます。

- クライアントのホスト名、IPアドレス、およびポート

- クライアントのドメイン名

- 宛先のホスト名、IPアドレス、およびポート

- 認証された件名

- クライアント証明書

コールバック実装には、取得されるクライアント・データを評価し、次のようにtrueまたはfalseを返すロジックが含まれます。

- コールバックがtrueを返す場合、認証は正常に実行され、WebLogic Serverへのクライアント接続が確立されます。

- コールバックがfalseを返す場合、「認証が拒否されました」というメッセージを表示してRemoteExceptionがスローされます。

注意:
WebLogic Serverで証明書コールバック実装を使用した場合、セキュア・ポート経由でリクエストが受信されると、常にコールバックが生成されます。その結果、証明書コールバックを使用すると、強制的なパフォーマンス・オーバーヘッドが発生する可能性があるため、その考慮も必要です。

証明書コールバック実装の作成

weblogic.security.SSL.CertificateCallbackインタフェースには、weblogic.security.SSL.CertificateCallbackInfoインスタンス上のvalidateメソッドで単一の呼出しが含まれます。CertificateCallbackInfoインスタンスには、セキュアRMI接続全体で受け渡されるエンド・ユーザーの詳細情報を取得するためのメソッドが含まれます。

返されるデータを評価し、trueまたはfalseを返すロジックを実装します。このロジックは、返されるデータをすべて評価する必要はありません。通常、共通名(cn)または識別名(dn)の入手など、証明書のみが評価されます。

詳細は、『Oracle WebLogic Server APIリフィレンス』にある次のJavadocを参照してください。

- weblogic.security.SSL.CertificateCallbackインタフェース

- weblogic.security.SSL.CertificateCallbackInfoクラス

WebLogic Serverを使用した証明書コールバックの構成

WebLogic Serverを使用してコールバックを構成するには、WebLogic Server起動コマンドでシステム・プロパティとしてコールバック実装を指定します。プロパティは、サーバーのクラスパス上にあるコールバック実装クラスを示す必要があります。たとえば、コールバック実装クラスがパッケージcom.mycompany.securityのMyCertificateCallback.javaで、MyCertificateCallback.classがサーバーのクラスパス内にある場合、次のコマンドがWebLogic Serverでコールバック実装プロパティを設定します。

java weblogic.Server -Dweblogic.security.SSL.CertificateCallback=com.mycompany.security.MyCertificateCallback

WebLogic Serverが一方向SSL用に構成されている場合、クライアント証明書はサーバーに送信されないことに注意します。証明書コールバック・ハンドラは、WebLogic Serverが双方向SSL用に構成されている場合にのみ使用することをお薦めします。詳細は、第12章「SSLの構成」を参照してください。

12 SSLの構成

この章では、WebLogic Server 10.3.6にSSLを構成する方法について説明します。SSLの構成は省略可能ですが、本番環境ではSSLを使用することをお薦めします。

この章の内容は以下のとおりです。

注意:
以下の節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。
すべてのマシンにおいて、オペレーティング・システム・ベンダーの最新の推奨パッチを適用しておく必要があります。

- SSLの概要

- 一方向および双方向SSL

- サポートされるJava Secure Socket Extension (JSSE) SSL実装

- SSLの設定: 主な手順

- ホスト名検証の使い方

- アウトバウンド双方向SSL接続のクライアント証明書の指定

- SSLのデバッグ

- SSLセッションの動作

- SSLを使用したRMI over IIOPの構成

- SSL証明書の検証

- WebLogic ServerでのnCipher JCEプロバイダの使い方

- SSLプロトコルのバージョンの指定

- JSSEベースSSL実装の使用

- X.509証明書失効チェック

SSLの概要

Secure Sockets Layer (SSL)は、ネットワークを介して接続する2つのアプリケーションが互いのIDを認証できるようにするとともに、アプリケーション間で交換されるデータを暗号化することで、セキュアな接続を実現します。認証を使用すると、サーバーは(場合によってはクライアントも)ネットワーク接続の相手側アプリケーションのIDを検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。

WebLogic ServerのSSLは、SSL 3.0およびTLS (Transport Layer Security) 1.0仕様の実装です。

注意:
WebLogic ServerではSSL 2.0はサポートされません。TLS V1.1プロトコルおよびTLS V1.2プロトコルのサポートを有効にするには、JDK 6 update 121またはそれ以降でWebLogic Serverを実行する必要があります。

WebLogic Serverは、専用のリスニング・ポート(デフォルトは7002)でSSLをサポートします。HTTPでSSL接続を確立するには、接続URLにSSLリスニング・ポートとHTTPSプロトコルを指定して(https://myserver:7002など)、WebブラウザからWebLogic Serverに接続します。

SSLを使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境でSSLを使用しないでください。ただし、本番環境では常にSSLを使用してください。

一方向および双方向SSL

SSLは、一方向または双方向として構成できます。

- 一方向SSLでは、サーバーはクライアントに対して証明書を提示する必要がありますが、クライアントはサーバーに対して証明書を提示する必要がありません。クライアントはサーバーを認証する必要がありますが、サーバーはどのクライアントからの接続も受け入れます。一方向SSLは、インターネット上で顧客が個人データを共有する前にセキュアな接続を実現したい場合によく使用されます。クライアントがログインするときにも、サーバーが認証できるようにSSLを使用することがよくあります。

- 双方向SSL (SSLとクライアント認証)の場合、サーバーはクライアントに証明書を提示し、クライアントはサーバーに証明書を提示します。クライアントが有効で信頼性のある証明書を発行しなければSSL接続を確立できないようにWebLogic Serverを構成できます。

サポートされるJava Secure Socket Extension (JSSE) SSL実装

このリリースのWebLogic Serverでは、Weblogic ServerのCerticom SSL実装がJava Secure Socket Extension (JSSE)ベースのSSL実装に置き換えられています。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングIO API、ノンブロッキングIO API、および複数の信頼性のあるCAを含む参照実装が含まれています。

JSSEベースSSL実装は、Certicom SSL実装を使用するWeblogic Serverバージョン8.1以上のインスタンスとSSLを介して相互運用します。つまり、JSSE SSLのWebLogic ServerがSSLクライアントまたはSSLサーバーのいずれかとして使用される場合、Certicom SSL実装を使用するWebLogic Server(バージョン8.1以上)のインスタンスとSSLで通信できます。

JSSEの使用については、「JSSEベースSSL実装の使用」を参照してください。

JSSEの詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

注意:
Certicom SSL実装のサポートは非推奨になり、今後は削除されます。このため、このリリースのWebLogic Serverでは、Certicom SSLPlus Javaバージョン4.0 SSL実装を引き続きサポートします。

SSLの設定: 主な手順

SSLを設定するには:

1. WebLogic ServerのID (秘密鍵とデジタル証明書)および信頼(信頼性のある認証局の証明書)を取得します。この手順を行うには、WebLogic Serverに付属しているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用するか、CertGenユーティリティ、keytoolユーティリティ、またはEntrustやVerisignなどの信頼できるベンダーからのものを使用します。

注意:
次の点に注意してください。

- CertGenユーティリティを使用して証明書を生成する場合は、「CertGenを使用する場合の制限事項」で使用上の制限事項について確認してください。CertGenによって生成される証明書はデモ専用ですので、本番環境では使用しないようにしてください。

- WebLogic Serverに対して発行されたID証明書がSHA-256署名アルゴリズムで署名されていて、CerticomベースのSSL実装が有効化されている場合は、SSLを構成した後にWebLogic Serverが起動しない可能性があります。この状況を回避する方法については、「SSL構成後におけるWebLogic Serverの起動の失敗」を参照してください。

2. IDと信頼を保存します。IDと信頼を指定する秘密鍵と信頼性のあるCA証明書は、キーストアに格納します。

注意:
このリリースのWebLogic Serverでは、ファイルに格納されている秘密鍵および信頼性のあるCA証明書をサポートします。また、後方互換性を保つために、WebLogicキーストア・プロバイダに格納されているものもサポートされます。

3. WebLogic Server管理コンソールで、WebLogic ServerのIDキーストアと信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

4. WebLogic管理コンソールで、秘密鍵の別名とパスワードに関するSSL構成オプションを設定します。必要な場合、クライアント証明書の提示を必須とする構成オプションを設定します(双方向SSLの場合)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: SSL」と双方向SSLの構成に関する項を参照してください。

注意:
FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。
このリリースでは、FIPSモードのJSSEはデフォルトではサポートされませんが、別途バンドルされているパッチをインストールすると使用できます。詳細は、付録A「FIPSモードの有効化」を参照してください。

WebLogic ServerのIDと信頼の構成に関する詳細は、次の項を参照してください。

- 「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得」を参照してください。

- 「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。

ホスト名検証の使い方

ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証は、SSLクライアント(SSLクライアントとして機能しているWebLogic Serverなど)がリモート・ホスト上のアプリケーション・サーバーに接続する場合に役立ちます。また、中間者攻撃を防ぐのに役立ちます。

WebLogic Serverには2つのホスト名検証があります。これらについては、次の項で説明します。

- デフォルトのWebLogic Serverホスト名検証の使用

- ワイルドカードのあるホスト名検証の使用

WebLogic Serverから使用できるホスト名検証のかわりとして、カスタムのホスト名検証を使用できます。詳細は、「カスタム・ホスト名検証の使用」を参照してください。

デフォルトでは、デフォルトのWebLogic Serverホスト名検証が有効になります。

デフォルトのWebLogic Serverホスト名検証の使用

WebLogic ServerのSSLハンドシェーク機能としての動作は、SSLサーバーのデジタル証明書のSubjectDNにある共通名と、SSL接続の許可に使用するSSLサーバーのホスト名を比較することです。これらの名前が完全に一致しない場合は、SSL接続が中断されます。名前が一致しない場合はSSLクライアントが実際にSSL接続を中断します。

デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム・ホスト名検証を構成します。ホスト名検証を無効にすると、WebLogic Serverは中間者攻撃に対して無防備な状態になります。本番環境では、ホスト名検証を有効にしておくことをお薦めします。

デフォルトのWebLogic Serverホスト名ベリファイアを使用する場合、ホスト名の検証は次の両方の条件がある場合に合格します。

- 証明書のホスト名がローカルマシンのホスト名に一致します。

- URLがlocalhost、127.0.01、またはローカル・マシンのデフォルトIPアドレスを指定します。

注意:
マルチサーバー・ドメインでデモ用のID証明書を使用している場合、管理対象サーバーを管理サーバーの完全修飾DNS名で開始すると、管理対象サーバー・インスタンスの起動に失敗します。制限事項や推奨回避策の詳細は、「CertGenを使用する場合の制限事項」を参照してください。

デフォルトでは、デフォルトのホスト名検証が構成されます。これを使用するために必要な操作はありません。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。

- 「ホスト名検証の有効化の確認」

- 「ホスト名検証の無効化」

- 「サーバー: 構成: SSL」

ワイルドカードのあるホスト名検証の使用

デフォルトのWebLogic Serverホスト名検証に加えて、WebLogic Serverには、ワイルドカードのあるホスト名検証というもう1つのホスト名検証があります。ワイルドカードのあるホスト名検証は、デフォルトのWebLogic Serverホスト名検証と同様に機能しますが、さらに次のSSLセッション証明書も受け入れます。

- 証明書のサブジェクト共通名属性(CNドメイン)から取得されるホスト名にアスタリスクのワイルドカード文字(*)が含まれる証明書

- SubjectAlternativeName dnsName (SAN)証明書

ワイルドカードのあるホスト名検証の仕組み

SSLセッション証明書のホスト名に次の条件を満たすワイルドカード文字が含まれる場合、証明書はワイルドカードのあるホスト名検証に受け入れられます。

- ホスト名に少なくとも2つのドット(.)文字が含まれる。

- ホスト名がアスタリスク(*)で始まり、他にアスタリスクを含まない。

- CN文字列からアスタリスク(*)を取ったときの残りの文字列が次のようになる場合

- ドメインを表す。

- 先頭にドット(.)文字を含む。

- 受信リクエスト・ドメインの最後の文字列と同じ。

- 他にドット(.)文字を含まない(これにより、ワイルドカードがサブドメインを表すことがなくなります。

SSLセッション証明書のホスト名が期待されるサーバー名属性と完全に一致せず、またホスト名をワイルドカードの受け入れ条件に従って正常に検証できない場合、ワイルドカードのあるホスト名検証は、SAN拡張の検証を試みます。

SAN拡張はSSLセッション証明書から取得されます。SAN拡張の値は、大文字と小文字を区別しない一致を使用して繰り返し適用されます。繰り返されるいずれかの値について、証明書内のdnsName属性がリクエストURLと一致すると、ホスト名検証は成功します。

ワイルドカードのあるホスト名検証の構成

ワイルドカードのあるホスト名検証のクラス名は、weblogic.security.utils.SSLWLSWildcardHostnameVerifierです。ワイルドカードのあるホスト名検証を構成するには、管理コンソールの「サーバー」→「構成」→「SSL」ページで、カスタムのホスト名検証としてこのクラスを指定します。ワイルドカードのあるホスト名検証には、構成が必要なパラメータはありません。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。

カスタム・ホスト名検証の使用

カスタム・ホスト名検証を実装するクラスは、WebLogic Server (SSLクライアントとして機能している場合)またはスタンドアロンのSSLクライアントのCLASSPATHに指定されている必要があります。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。

アウトバウンド双方向SSL接続のクライアント証明書の指定

アウトバウンド双方向SSL接続を行う際、デフォルトでWebLogic Serverはそのサーバー証明書を使用して、クライアントとしてアイデンティティを確立します。ただし、かわりに個別のクライアント証明書を指定して、アイデンティティを確立することもできます。この機能は、特にWebLogic Serverが双方向SSL接続を行うクライアントとして機能している場合に役立ちます。

注意:
WebLogic Serverのアイデンティティのクライアント証明書への切替えは、アウトバウンド双方向SSL接続を行う場合にのみサポートされます。WebLogic ServerがSSLサーバーとして機能するインバウンドSSL接続の場合、アイデンティティには常にサーバー証明書が使用されます。

この機能を使用するには、次の手順に従います:

1. WebLogic Serverのアイデンティティ・キーストアにクライアント証明書を追加し、秘密鍵およびパブリック証明書が保存される別名の名前を書き留めます。これは一度だけ行う必要があります。次の手順が完了すると、現在のWebLogic Serverインスタンスで、アウトバウンド双方向SSL接続を行うクライアントIDはいつでも使用できるようになります。
クライアント証明書をアイデンティティ・キーストアに追加するには、次の手順を実行します。

1. クライアント鍵ペア(公開鍵と関連する秘密鍵)および秘密鍵の別名を作成し、これをWebLogic Serverアイデンティティ・キーストアに保存します。これは、keytoolユーティリティを使用して行うことができます。

2. 証明書署名リクエスト(CSR)を生成し、これを認証局(CA)に提出すると、認証局はCAの署名のあるクライアント証明書を返します。サーバー証明書と同じCAを使用し、両方の証明書が信頼性のある同じルートCAを持つようにすることをお薦めします。

3. CA署名のあるクライアント証明書をアイデンティティ・キーストアに保存します(クライアント証明書がサーバー証明書と同じCAによって署名されている場合、ルートCA証明書はすでに信頼キーストアにあるため、これを保存する手順をスキップできます)。

2. クライアント証明書を使用してアウトバウンド双方向SSL接続を開始するには、次の操作を行うWLSTスクリプトを作成します。

1. WebLogic Serverインスタンスに接続します。

2. SSLMBean.UseServerCerts属性をtrueに設定します。これで発信接続のサーバー・アイデンティティが確立されます。

3. SSLMBean.UseClientCertForOutbound属性をtrueに設定することにより、クライアント証明書のIDに切り替えます。

4. SSLMBean.ClientCertPrivateKeyPassPhrase属性を使用してクライアント証明書の秘密鍵パスワードを指定し、SSLMBean.ClientCertAlias属性を使用してクライアント証明書のキーストア別名を指定します。

このWLSTスクリプトのサンプルは、例12-1を参照してください。

例12-1 クライアントIDを使用してアウトバウンド双方向SSL接続を開始するWLSTスクリプトのサンプル

url="t3://localhost:7001"
adminUsername="weblogic"
adminPassword="weblogic1"
connect(adminUsername, adminPassword, url)
edit()
server=cmo.lookupServer('myserver')
cd('Servers')
cd('myserver')
startEdit()
cd('SSL')
cd('myserver')
ssl = server.getSSL()
ssl.setUseServerCerts(true)
ssl.setUseClientCertForOutbound(true)
ssl.setClientCertAlias("myClientCert")
ssl.setClientCertPrivateKeyPassPhrase("myClientCertPrivateKeyPassPhrase")
save()
activate()
disconnect()
exit()

アウトバウンドSSL接続用にサーバーID証明書の使用を復元するには、SSLMBean.UseClientCertForOutbound属性をfalseに設定するWLSTコマンドを入力します。

次の点に注意してください。

- SSLMBean.ClientCertPrivateKeyPassPhrase属性およびSSLMBean.ClientCertAlias属性の値は永続化され、次にクライアントIDを使用してアウトバウンド双方向SSL接続が行われるとき(次にSSLMBean.UseClientCertForOutbound属性がtrueに設定されるとき)に使用されます。

- アウトバウンドSSL接続のクライアント証明書の指定に使用されるSSLMBean属性は、WebLogic Server管理コンソールからは使用できません。

SSLのデバッグ

SSLデバッグは、SSLハンドシェーク中に発生したSSLイベントに関する詳細な情報を提供します。SSLデバッグのトレースには、以下のものに関する情報が記載されます。

- 信頼性のある認証局

- SSLサーバーの構成情報

- サーバーのID (秘密鍵とデジタル証明書)

- 許可されている暗号化強度

- 有効になっている暗号

- SSLハンドシェーク中に渡されたSSLレコード

- WebLogic Serverによって検出されたSSL障害(妥当性と信頼性のチェックや、デフォルトのホスト名検証など)

- I/O関連の情報

SSLデバッグは、SSLプロセスでALERTが作成されるとスタック・トレースをダンプします。ALERTのタイプと重大度は、Transport Layer Security (TLS)仕様で定義されています。

スタック・トレースは、情報をALERTが発生した場所のログ・ファイルにダンプします。そのため、SSLの問題を追跡する場合は、SSL接続の両側(SSLクライアントとSSLサーバーの両方で)でデバッグを有効にしておく必要があります。ログ・ファイルには、障害が発生した場所に関する詳細な情報が記録されます。ALERTが発生した場所を判別するには、ALERTの後にトレース・メッセージがあるかどうかを確認します。トレース・メッセージの後に受信されたALERTによって、そのピアで障害が発生したことがわかります。問題を判別するには、SSL接続のそのピアでSSLデバッグを有効にしておく必要があります。

SSLの問題を追跡する場合は、ログ・ファイルの情報を調べて次のことを確認します:

- 適切なconfig.xmlファイルがロードされました

- 国内向けまたは輸出向けの設定が適切です

- 信頼性のある認証局がこのサーバーに対して有効かつ適切でした

- ホスト名チェックが成功しました

- 証明書検証が成功しました

注意:
Sev 1 type 0は、正常なクローズALERTであり、問題ではありません。

SSLデバッグを有効化するためのコマンドライン・プロパティ

次のコマンド・ライン・プロパティを使用してSSLデバッグを有効にします。

-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true

SSLデバッグ・プロパティは、SSLサーバー、SSLクライアント、およびノード・マネージャの起動スクリプトに含めることができます。ノード・マネージャによって起動される管理対象サーバーに対しては、管理対象サーバーの「サーバーの起動」ページでこのコマンド・ライン引数を指定します。

JSSE使用時のSSLデバッグ

WebLogic ServerがJSSEベースのSSL実装を使用するように構成されている場合(「JSSEベースのSSL実装の使用」を参照)、次のコマンド・ライン・プロパティを使用して追加の詳細デバッグ・ロギングを有効化できます。

-Djavax.net.debug=all

次の点に注意してください。

- -Dssl.debug=trueおよび-Dweblogic.StdoutDebugEnabled=trueコマンド・ライン・プロパティは、引き続きJSSEに適用されます。このプロパティを使用すると、Weblogic Server内でSSL呼出しコードのデバッグ・ロギングを有効化できます。

- -Djavax.net.debug=allプロパティを使用すると、JSSEベースのSSL実装内でデバッグ・ロギングを有効化できます。

JSSE SSLロギング・システムでのWebLogicロギング・プロパティの使用の詳細は、「JSSE SSLでのデバッグの使用」を参照してください。

JSSEで使用可能なユーティリティのデバッグの詳細情報は、次のURLからダウンロードできるJava (tm) Secure Socket Extension (JSSE)リファレンス・ガイドのユーティリティのデバッグに関する項を参照してください。

http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug

SSL構成後におけるWebLogic Serverの起動の失敗

SSLを構成した後にWebLogic Serverが起動せず、次のようなメッセージが表示される場合は、サーバーのID証明書と有効化されている特定のSSL実装との間に不整合がある可能性があります。

<07-Aug-2013 13:52:53 o'clock UTC> <Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias soa from the JKS keystore file /u01/app/avitek/admin/domain/dev/config/fmwconfig/soa.jks.>
<07-Aug-2013 13:52:53 o'clock UTC> <Error> <WebLogicServer> <BEA-000297> <Inconsistent security configuration, java.lang.RuntimeException: Cannot convert identity certificate>
<07-Aug-2013 13:52:53 o'clock UTC> <Error> <Server> <BEA-002618> <An invalid attempt was made to configure a channel for unconfigured protocol ”Cannot convert identity certificate”.>

この問題は、WebLogic ServerではCerticomベースのSSL実装の使用が構成されているのに、サーバーのID証明書が署名ハッシュ・アルゴリズムSHA-256で署名されている場合に発生することがあります。WebLogic ServerのCerticomベースのSSL実装では、SHA-256署名付き証明書はサポートされていません。WebLogic 10.3.3以降でSHA-256証明書を使用するには、JSSEベースのSSL実装を有効にする必要があります。

注意:
証明書レジストリを使用して、証明書の署名に使用する署名ハッシュ・アルゴリズムを決定できます。詳細は、「証明書ルックアップおよび検証フレームワークの構成」を参照してください。

WebLogic Server管理コンソールを使用してWebLogic ServerのJSSEベースのSSL実装を有効にするには、次の手順を実行します。

1. 「環境」→「サーバー」→サーバー名→「構成」→「SSL」ページに移動し、「詳細」を選択します。

2. 「JSSE SSLの使用」を選択し、「保存」をクリックします。

3. WebLogic Serverを再起動します。

注意:
WebLogic ServerがJDK 7とともにインストールされている場合、JDK 7における証明書の署名ハッシュ・アルゴリズムの要件により、WebLogic Serverが提供するCerticomベースのSSL実装は使用できません。

SSLセッションの動作

WebLogic Serverでは、SSLセッションをキャッシュできます。これらのセッションは、サーバーの稼働時間にわたって存続します。

SSLソケットを直接使用するクライアントは、SSLセッション・キャッシュの動作を制御できます。SSLセッション・キャッシュは、各SSLコンテキストに固有のものです。特定のSSLコンテキストによって返されたSSLソケット・ファクトリ・インスタンスによって作成されたすべてのSSLソケットは、SSLセッションを共有します。

クライアントは、デフォルトでは同じIPアドレスとポートでセッションを再開します。デフォルトでは、複数のSSLソケットが同じホストとポートを使用してSSLセッションを共有し、SSLソケットが共通の基底SSLコンテキストを使用していると見なします。

SSLセッションを使用するように構成されていないクライアントは、SSLソケットでsetEnableSessionCreation(false)を呼び出してSSLセッションがキャッシュされないようにする必要があります。この設定はSSLセッションがキャッシュに追加されるかどうかだけを制御します。SSLソケットで、すでにキャッシュされたSSLセッションの検索は停止されません。たとえば、SSLソケット1でセッションをキャッシュし、SSLソケット2でsetEnableSessionCreationをfalseに設定しても、SSLソケット1に由来するSSLセッションはキャッシュに格納されているため再利用されることがあります。

SSLセッションはSSLコンテキストの存続期間にわたって存在し、SSLソケットの存続期間によって制御されません。このため、新しいSSLソケットを作成して以前のセッションで使用したのと同じホストとポートに接続する場合、キャッシュ内に以前のSSLセッションを持つSSLコンテキストのSSLソケット・ファクトリを使用してSSLソケットを作成する場合に限り、以前のセッションを再開できます。

デフォルトでは、HTTPS URLを使用するクライアントは、URLごとに新しいSSLセッションを取得します。これは、各URLが異なるSSLコンテキストを使用するため、SSLセッションを共有または再利用できないからです。SSLセッションを取得するには、weblogic.net.http.HttpsClientクラスまたはweblogic.net.http.HttpsURLConnectionクラスを使用します。クライアント間でSSLソケット・ファクトリを共有することにより、クライアントでURLを再開することもできます。

セッション・キャッシングはスレッドによって共有可能なSSLコンテキストによって維持されます。1つのスレッドは1つのSSLセッションではなくセッション・キャッシュ全体にアクセスできるので、複数のSSLセッションを1つ(または複数の)スレッドで使用および共有できます。

weblogic.security.SSL.sessionCache.ttlコマンドライン引数を使用して、SSLセッション・キャッシングのデフォルトのサーバー・セッション存続時間を変更できます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のSSLに関する項を参照してください。weblogic.security.SSL.sessionCache.sizeコマンドライン引数は無視されます。

SSLを使用したRMI over IIOPの構成

SSLを使用すると、RMI (Remote Method Invocation)リモート・オブジェクトへのIIOP (Internet Interop-Orb-Protocol)接続を保護できます。SSLは、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。

SSLを使用してRMI over IIOP接続を保護するには:

1. SSLを使用するようにWebLogic Serverを構成します。

2. SSLを使用するようにクライアントObject Request Broker (ORB)を構成します。SSLの構成については、クライアントORBの製品ドキュメントを参照してください。

3. host2iorユーティリティを使用して、WebLogic Server IORをコンソールに出力します。host2iorユーティリティでは、SSL接続用と非SSL接続用に2種類のインターオペラブル・オブジェクト参照(IOR)が出力されます。IORのヘッダーは、IORがSSL接続で使用できるかどうかを示します。

4. SSL IORは、WebLogic Server JNDIツリーにアクセスするCosNamingサービスへの初期参照を取得するときに使用します。

IIOPでのRMIの使用については、『Oracle WebLogic Server RMIのプログラミング』を参照してください。

SSL証明書の検証

WebLogic Serverは証明書チェーンの各証明書が認証局によって発行されたことを保証します。WebLogic Serverで使用するすべてのX509 V3 CA証明書はCAとして定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンド・ライン引数について説明します。

注意:
次の点に注意してください。

- Weblogic Serverは、特定の証明書の処理にRSA Cert-J 3.1を使用します。

- 証明書検証に合格しない証明書チェーンを持つWebLogic Serverが起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。

証明書検証のレベルの制御

デフォルトでは、WebLogic ServerはCAとして定義される基本制御拡張を持たない証明書チェーンの証明書はすべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459標準に準拠するようにセキュリティ・レベルを強化したりすることもできます。次のコマンド・ライン引数を使用して、WebLogic Serverで実行される証明書検証のレベルを制御できます。

-Dweblogic.security.SSL.enforceConstraints=option

表12-1に、コマンド・ライン引数のオプションの説明を示します。

表12-1 -Dweblogic.security.SSL.enforceConstraintsのオプション

オプション

説明

strongまたはtrue

このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義されます。

例:

-Dweblogic.security.SSL.enforceConstraints=strong

または

-Dweblogic.security.SSL.enforceConstraints=true

デフォルトでは、WebLogic Serverはこのレベルの証明書検証を行います。

strong_nov1cas

strongオプションと同等の機能は、前述の行で説明されており、X509バージョン1 CA証明書が拒否される追加の制約があります。

例:

-Dweblogic.security.SSL.enforceConstraints=strong_nov1cas

strict

このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義され、重大(クリティカル)に設定されます。このオプションはIETF RFC 2459標準を強制します。

例:

-Dweblogic.security.SSL.enforceConstraints=strict

市販のCA証明書の一部がIETF RFC 2459標準に準拠していないため、このオプションはデフォルトではありません。

strict_nov1cas

strictオプションと同等の機能は、前述の行で説明されており、X509バージョン1 CA証明書が拒否される追加の制約があります。

例:

-Dweblogic.security.SSL.enforceConstraints=strict_nov1cas

off

このオプションを使用すると、基本制約拡張チェックが無効になります。残りの証明書は引続き検証されます。

例:

-Dweblogic.security.SSL.enforceConstraints=off

このオプションは本番環境では使用しないことをお薦めします。かわりに、IETF RFC 2459標準に準拠した新しいCA証明書を購入してください。ほとんどの商用認証局のCA証明書は、デフォルトのstrongオプションで機能するはずです。

証明書の証明書ポリシーの受け入れ

WebLogic Serverでは、X.509証明書の証明書ポリシー拡張機能に対するサポートが制限されます。weblogic.security.SSL.allowedcertificatepolicyids引数を使用すると、証明書ポリシーIDのカンマ区切りのリストが得られます。重要な証明書ポリシー拡張付きの証明書が受け取られた場合、許可されている証明書ポリシーのリストに証明書ポリシーがあるかどうか、およびサポートされていないポリシー修飾子の有無が確認されます。このリリースのWebLogic Serverでは、Certification Practice Statement (CPS)ポリシー修飾子はサポートされますが、User Notice修飾子はサポートされません。また証明書は、特別なポリシーanyPolicyを含み、ID 2.5.29.32.0が指定されている場合にも受け入れられます。これは、CAがこの証明書に対してポリシーのセットを制限しないことを示しています。

注意:
weblogic.security.SSL.allowedcertificatepolicyids引数は、JSSEベースのSSL実装が有効化されているとき、WebLogic Serverでは現在サポートされていません。

証明書ポリシーの受け入れを有効にするには、以下の引数を指定してWebLogic Serverを起動します。

-Dweblogic.security.SSL.allowedcertificatepolicyids <identifier1>,<identifier2>,...

この引数には、証明書ポリシー識別子のカンマ区切りのリストを含める必要があります。このリストは、証明書チェーンに存在し得る重要な拡張付きのすべての証明書に対応し、WebLogic Serverがそのような証明書チェーンを受け入れられるようにルート証明書まで遡るものとします。

証明書チェーンのチェック

WebLogic Server ValidateCertChainコマンド・ライン・ユーティリティを使用すると、既存の証明書チェーンがWebLogic Serverによって拒否されるかどうかを確認できます。このユーティリティは、PEMファイル、PKCS-12ファイル、PKCS-12キーストア、およびJKSキーストアの証明書チェーンを検証します。このユーティリティでは、証明書チェーン全体が使用される必要があります。以下は、ValidateCertChainコマンド・ライン・ユーティリティの構文です。

java utils.ValidateCertChain -file pemcertificatefilename
java utils.ValidateCertChain -pem pemcertificatefilename
java utils.ValidateCertChain -pkcs12store pkcs12storefilename
java utils.ValidateCertChain -pkcs12file pkcs12filename password
java utils.ValidateCertChain -jks alias storefilename [storePass]

有効な証明書チェーンの例:

java utils.ValidateCertChain -pem zippychain.pem

Cert[0]: CN=zippy,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US

Cert[1]: CN=CertGenCAB,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US

Certificate chain appears valid

無効な証明書チェーンの例:

java utils.ValidateCertChain -jks mykey mykeystore

Cert[0]: CN=corba1,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US

CA cert not marked with critical BasicConstraint indicating it is a CA
Cert[1]: CN=CACERT,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US

Certificate chain is invalid

証明書ルックアップと検証のプロバイダ

WebLogic Server SSLには組込みの証明書検証があります。信頼性のあるCAのセットがある場合、この検証では以下のことを行います。

- チェーンの最後の証明書が、信頼性のあるCAであるか、または信頼性のあるCAによって発行されたものであるかを検証します。

- 信頼性のあるCAで証明書チェーンを完成させます。

- チェーン内の署名を検証します。

- チェーンが期限切れでないことを確認します。

証明書ルックアップおよび検証(CLV)プロバイダを使用すると、証明書チェーンに対してさらに検証を行うことができます。WebLogic Serverに次の2つのCLVプロバイダが含まれます。

- WebLogic証明書パス・プロバイダ - 証明書のパスを完了させ、特定のサーバー・インスタンスのために構成された信頼性のあるCAを使用して証明書を検証します。組込みSSL証明書検証と同じ機能を備えています。これはデフォルトで構成されます。

- 証明書レジストリ - システム管理者によって作成される、サーバーへのアクセスが許可されている信頼性のあるCA証明書のリストです。目的の証明書がこのレジストリに存在すれば、その証明書は有効です。証明書レジストリから証明書を削除すると、その証明書は無効になります。証明書レジストリは、失効チェックを実行するための低コストのメカニズムです。これはデフォルトで構成されません。

また、カスタムCertPathValidatorを作成して、証明書チェーンに対してさらに検証を行うこともできます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の証明書パス・プロバイダに関する項を参照してください。

WebLogic ServerでのSSL証明書検証の動作

WebLogic ServerインスタンスのアウトバウンドSSLと双方向インバウンドSSLは、検証が必要な証明書チェーンをSSLハンドシェーク中に受け取ります。双方向インバウンドSSLの例は、HTTPSでWebアプリケーションに接続するブラウザです。この場合、ブラウザはクライアントの証明書チェーンをWebアプリケーションに送信します。インバウンド証明書検証の設定は、サーバーでのすべての双方向クライアント証明書検証のために使用されます。

アウトバウンドSSLを使用する(SSLクライアントとして動作する)WebLogic Serverの例は以下のとおりです。

- ノード・マネージャへの接続

- 管理ポートでの別のWebLogic Serverインスタンスへの接続

- 外部LDAPサーバー(LDAPAuthenticatorなど)への接続

管理コンソールまたはWLSTを使用すると、SSLMBean属性のInboundCertificateValidationとOutboundCertificateValidationでインバウンドおよびアウトバウンドSSL証明書検証を別個に構成できます。

これらの属性の有効値は以下のとおりです。

- BUILTIN_SSL_VALIDATION - 組込みSSL証明書検証コードを使用して証明書チェーンを完成および検証します。つまり、SSLは旧リリースと同じように動作します。これはデフォルトの動作です。

- BUILTIN_SSL_VALIDATION_AND_CERT_PATH_VALIDATORS - 組込みの信頼性のあるCAに基づいた検証と、構成済みの証明書パス検証プロバイダを使用して追加の検証を実行します。つまり、SSLは旧リリースの動作に加えて、追加の検証を行います。

次を参照してください:

- Oracle WebLogic Server MBeanリファレンスのSSLMBeanに関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSSLの設定に関する項

証明書検証に関する問題のトラブルシューティング

以前のリリースのWebLogic Serverでは正常に機能していたSSL通信で予期しないエラーが発生するようになった場合は、証明書チェーンが検証に失敗していることが問題になっているおそれがあります。

証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または-Dweblogic.security.SSL.enforceConstraintsコマンド・ライン引数の設定を変更するかを決定してください。

証明書の問題に対処するには、次のいずれかの解決策を使用します。

- SSL通信を使用するプロセスの証明書チェーンの場所がわかっている場合は、ValidateCertChainコマンド・ライン・ユーティリティを使用して、証明書チェーンが受け入れられるかどうかをチェックします。

- SSL通信を使用するプロセスに対してSSLデバッグのトレースを有効にします。SSLデバッグのトレースの構文は、次のとおりです。

-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true

注意:
WebLogic ServerがJSSEベースのSSL実装を使用するように構成されている場合、次のコマンドライン・プロパティを使用して追加の詳細デバッグ・ロギングを有効化できます。
-Djavax.net.debug=all

詳細は、「JSSE使用時のSSLデバッグ」を参照してください。

次のメッセージは、SSLエラーが証明書チェーンの問題によって発生していることを示します。

<CA certificate rejected. The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical>

一方向SSLを使用している場合は、クライアント・ログでこのエラーを探してください。双方向SSLを使用している場合は、クライアント・ログとサーバー・ログでこのエラーを探してください。

WebLogic ServerでのnCipher JCEプロバイダの使い方

注意:
Java Cryptography Extension (JCE)プロバイダは、JDK 6.0で入手可能なJCEのアプリケーション・プログラミング・インタフェース(API)を使用して記述されます。このタイプのプロバイダは、WebLogicセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を使用して記述されたプロバイダとは異なります。デフォルトではWebLogic ServerにはJCEプロバイダが用意されていません。

SSLは、Webサーバーで使用できるリソースの保護における重要なコンポーネントです。しかし、大量のSSLトラフィックによって、Webサーバーのパフォーマンスを低下させるボトルネックが発生することがあります。JCEプロバイダは、暗号化用ハードウェア・カードを使用するnCipherと同じように、WebサーバーのSSLプロセスの負荷を軽減し、サーバーがより多くのトランザクションを処理できるようにします。また、キーの整合性と機密性を保持するための強力な暗号化プロセスも提供します。

WebLogic Serverでは、以下のJCEプロバイダの使用がサポートされています。

- JDK 6.0のJDK JCEプロバイダ(SunJCE)。SunJCEの機能の詳細は、Java (tm) Cryptography Architecture (JCA)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html)を参照してください。
JCAフレームワークには、異なる管轄コンテキストでアプレット/アプリケーションに使用可能な暗号化アルゴリズムおよび最高暗号化強度に関する制約を強制する機能が含まれます。このような制約は、「管轄ポリシー・ファイル」で指定されます。詳細は、Java (tm) Cryptography Architecture (JCA)リファレンス・ガイドを参照してください。

WebLogic Serverアプリケーション・プログラミング・インタフェース(API)で使用される暗号化の強度は、引続きWebLogic Serverによって制御されます。クライアント・コードに適切な国内向け強度の暗号化設定がない場合は、デフォルトのJava SE輸出向け強度の暗号化しか使用できません。サーバーでは常に、輸出向け強度または国内向け強度の暗号化が有効になります。

- nCipher JCEプロバイダ。http://www.ncipher.comを参照してください。

nCipher JCEプロバイダをインストールするには:

1. 製品のドキュメントに従って、nCipher JCEプロバイダのハードウェアを設置し、構成します。

2. nCipher JCEプロバイダのファイルをインストールします。以下のファイルが必要です。

- 管轄ポリシー・ファイル - これらのファイルはJDKによってデフォルトでインストールされますが、輸出向け強度に制限されています。

- JARファイルを署名した証明書

注意:
この手順は、nCipher JCEプロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。

- JCEプロバイダJARファイル

このファイルのインストール方法は以下から選択します。

- ファイルを拡張としてインストールします。ファイルを以下のいずれかの場所にコピーします。

JAVA_HOME/jre/lib/ext

例:

MW_HOME/jdk160_14/jre/lib/ext

- サーバーのCLASSPATHにファイルを指定します。

3. Javaセキュリティ・プロパティ・ファイル(java.security)を編集して、WebLogic Serverで承認されているJCEプロバイダのリストにnCipher JCEプロバイダを追加します。Javaセキュリティ・プロパティ・ファイルは、以下の場所にあります。

JAVA_HOME/jre/lib/security/java.security

次のようにnCipher JCEプロバイダを指定します。

security.provider.n=com.ncipher.provider.km.mCipherKM

nは、特定のプロバイダが指定されていない場合に、要求されたアルゴリズムに対してプロバイダが検索される順序を決定する優先順序です。順序は1が基準になり、1が最も優先されます。その後、2、3、...と続きます。

nCipher JCEプロバイダは、セキュリティ・プロパティ・ファイルでRSA JCAプロバイダの次に来る必要があります。例:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.ncipher.provider.km.mCipherKM

4. WebLogic Serverを起動します。

5. nCipher JCEプロバイダが正常に機能していることを確認するには、nCipherの製品ドキュメントに従ってデバッグを有効にします。

SSLプロトコルのバージョンの指定

SSLハンドシェイクの開始時に、SSLピアは両方のピアがサポートする最も高いプロトコル・バージョンを判断します。ただし、SSL接続で有効なSSLとTLSの最低サポート・バージョンを制限するようWeblogic Serverを構成することもできます。

SSLハンドシェイクで有効なSSLおよびTLSのバージョンを指定するには、WebLogic Serverを起動するコマンドライン引数で次のシステム・プロパティのいずれかを設定でします。

- weblogic.security.SSL.protocolVersion

- weblogic.security.SSL.minimumProtocolVersion

WebLogic ServerでのSSLプロトコル・サポートについて、次の点に注意してください。

- JSSEベースのSSL実装が有効な場合(「JSSEベースSSL実装の使用」を参照)、SSLプロトコル・サポートはインストールされているJSSEプロバイダに依存します。

- WebLogic ServerがSSLサーバーとして動作する場合、サポートされていれば、クライアントのハロー・メッセージで指定された方のプロトコルになります。

- WebLogic ServerはSSL V2.0をサポートしていません。

次の項では、次の2つのシステム・プロパティを使用する方法について説明します。

- weblogic.security.SSL.protocolVersionシステム・プロパティの使用

- weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用

weblogic.security.SSL.protocolVersionシステム・プロパティの使用

ほとんどの場合、SSLプロトコルまたはTLSプロトコルの最新バージョンが適切ですが、ピアがこれをサポートしていない場合もあります。許容できるSSLプロトコルおよびTLSプロトコルの有効化にTLS V1プロトコルが適している状況(互換性、SSLのパフォーマンス、セキュリティ要件が最大の環境など)に基づいて、有効なSSLプロトコルまたはTLSプロトコルを指定できます。WebLogic Serverを起動するコマンドライン引数でweblogic.security.SSL.protocolVersionシステム・プロパティを指定することで、SSL接続に使用するプロトコルを指定できます。

次のコマンド・ライン引数を指定すると、WebLogic ServerはSSL V3.0またはTLS接続のみをサポートします。

- -Dweblogic.security.SSL.protocolVersion=SSL3 - SSL V3.0のメッセージのみが送信されて受理されます。クライアントが以前のバージョンのSSLで接続を確立しようとすると、WebLogic Serverによって拒否され、拒否メッセージがクライアントに返されます。

- -Dweblogic.security.SSL.protocolVersion=TLS1 - JSSEが有効な場合、このプロパティ値により、送信され受け入れられるメッセージに対し、TLSで始まるプロトコル(TLS V1.0、TLS V1.1、TLS V1.2など)が有効になります。CerticomベースのSSL実装が有効な場合、TLS V1のみが有効です。

- -Dweblogic.security.SSL.protocolVersion=ALL - デフォルトの動作です。Certicomが有効な場合は、SSL V3.0、TLS V1およびSSLv2Helloメッセージのみが送信され、受け入れられます。JSSEが有効な場合、JSSEプロバイダのインストールに応じて、さらに別のプロトコルが有効になります。

次の点に注意してください。

- SSL V3.0プロトコルとTLS V1プロトコルは入れ替えできません。すべての必要なSSLクライアントがそのプロトコルを使用できることが確かである場合は、TLS V1プロトコルのみを使用します。

- SSLバージョンのSSLv2Helloはデフォルトで有効なプロトコルの1つで、次の状況でのみ有効となります。

- weblogic.security.SSL.protocolVersionまたはweblogic.security.SSL.minimumProtocolVersionのシステム・プロパティに明示的に値を設定しない。

- weblogic.security.SSL.protocolVersion=ALLシステム・プロパティを設定する。

- weblogic.security.SSL.protocolVersionシステム・プロパティを設定しないと、SSLv2Hello、SSLv3およびTLSv1のプロトコルが有効になります。さらに、JSSEの場合、TLSで始まるすべてのバージョンも有効になります。

- weblogic.security.SSL.minimumProtocolVersionシステム・プロパティにサポートされている有効なプロトコルが設定されている場合、weblogic.security.SSL.protocolVersionで設定したプロトコル値は無視されます。

警告:
このシステム・プロパティでTLS1またはALLを指定すると、SSLプロバイダでサポートされているTLS V1の全バージョンがSSL接続で使用できるようになります。CerticomベースのSSL実装でサポートされるのはTLS V1.0のみですが、JSSEベースの実装ではTLS V1.0、TLS V1.1およびTLS V1.2がサポートされます。本番環境ではTLS V1.1以降を使用することをお薦めします。これはweblogic.security.SSL.minimumProtocolVersionシステム・プロパティにより使用可能です。詳細は、「weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用」を参照してください。

weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用

本番環境では、SSL接続でのメッセージの送受信にTLS V1.1以降をお薦めします。

SSL接続に対して有効なSSL V3.0およびTLS V1の最低バージョンを制御するには、WebLogic Serverを起動するコマンドラインでweblogic.security.SSL.minimumProtocolVersion=protocolシステム・プロパティをオプションとして設定します。このシステム・プロパティでは、protocolに次の値のいずれかを受け入れます。

値

説明

SSLv3

SSL接続で有効な最低プロトコル・バージョンとしてSSL V3.0を指定します。

TLSv1

SSL接続で有効な最低プロトコル・バージョンとしてTLS V1.0を指定します。

TLSvx.y

SSL接続で有効な最低プロトコル・バージョンとしてTLS Vx.yを指定します。ここで:

- xは1 - 9の整数です。

- yは0 - 9の整数です。

たとえば、TLSv1.2のように指定します。

weblogic.security.SSL.minimumProtocolVersionシステム・プロパティに指定できる各値により有効になる特定のプロトコルは、WebLogic Serverが構成されるSSL実装に依存します。次の項では、これらのプロトコルをWebLogic Serverで使用可能な各SSL実装について示します。

- JSSEベースのSSL実装で有効なプロトコル

- CerticomベースのSSL実装で有効なプロトコル

JSSEベースのSSL実装で有効なプロトコル

JSSEベースのSSL実装を使用するようにWebLogic Serverが構成され、weblogic.security.SSL.minimumProtocolVersionシステム・プロパティを使用してプロトコルの最低バージョンを指定する場合、有効となる特定のSSLプロトコルおよびTLSプロトコルは、次のようにSSL実装でサポートされるプロトコルに依存します。

注意:
TLS V1.1プロトコルおよびTLS V1.2プロトコルのサポートを有効にするには、JDK 6 update 121またはそれ以降でWebLogic Serverを実行する必要があります。

- 指定する特定の最低プロトコル・バージョンがサポートされている場合、WebLogic Serverはこのプロトコル・バージョンおよびサポートされるこれ以降のプロトコル・バージョンすべてを有効にします。
例:

指定するプロトコル

JSSEベースのSSL実装でサポートされるプロトコル

有効となるプロトコル

TLSv1

SSLv2HelloFoot 1
SSLv3
TLSv1
TLSv1.1
TLSv1.2

TLSv1
TLSv1.1
TLSv1.2

脚注1 1 weblogic.security.SSL.minimumProtocolVersionシステム・プロパティが使用されている場合、SSLv2Helloプロトコルは、JSSEベースのSSL実装では、サポートされていても有効にはなりません。

- 指定する特定の最低プロトコル・バージョンがサポートされていない場合、Weblogic Serverは、次に低いプロトコルおよびサポートされるこれ以降のプロトコルすべてを有効にします。最も低いプロトコル・バージョンはSSLv3に制限されます。つまり、SSLv2Helloは、次に低いプロトコル・バージョンだとしても有効にはなりません。
例:

指定するプロトコル

JSSEベースのSSL実装でサポートされるプロトコル

有効となるプロトコル

TLSv1

SSLv2HelloFootref 1
SSLv3
TLSv1.1
TLSv1.2

SSLv3
TLSv1.1
TLSv1.2

- 指定する最低プロトコル・バージョンがサポートされておらず、これより古い(低いバージョンの)プロトコル(SSLv3以降)がサポートされていない場合、WebLogic Serverは、サポートされているこれより新しい(高い)バージョンすべてを有効にします。このケースは、通常SSLv3が最低プロトコル・バージョンに設定されている場合に当てはまります。SSLv2Helloは次に低いプロトコルとして有効ではないため、使用可能なこれ以降のプロトコルのみが有効になります。
例:

指定するプロトコル

JSSEベースのSSL実装でサポートされるプロトコル

有効となるプロトコル

SSLv3

SSLv2HelloFootref 1
TLSv1
TLSv1.1
TLSv1.2

TLSv1
TLSv1.1
TLSv1.2

- 指定する特定の最低プロトコル・バージョンが無効な場合、WebLogic ServerはSSLv3とそれ以降のサポート対象プロトコル・バージョンすべてを有効にします。
例:

指定するプロトコル

JSSEベースのSSL実装でサポートされるプロトコル

有効となるプロトコル

TSLv0

SSLv2HelloFootref 1
SSLv3
TLSv1
TLSv1.1
TLSv1.2

SSLv3
TLSv1
TLSv1.1
TLSv1.2

CerticomベースのSSL実装で有効なプロトコル

CerticomベースのSSL実装を使用するようにWebLogic Serverが構成されている場合、使用する最低SSLプロトコル・バージョンを指定するweblogic.security.SSL.minimumProtocolVersionシステム・プロパティを使用する方法について、次の点に注意してください。

- サポートされるSSLプロトコル・バージョンは次の2つのみです。

- V2HELLO_SSL3_TLS1

- TLS1_ONLY

- 指定する特定の最低プロトコル・バージョンがサポートされている場合、WebLogic Serverはこのプロトコル・バージョンおよびサポートされるこれ以降のバージョンすべてを有効にします。
例:

指定するプロトコル

CerticomベースSSL実装でサポートされるプロトコル

有効となるプロトコル

TLSv1

V2HELLO_SSL3_TLS1
TLS1_ONLY

TLS1_ONLY

- 指定する特定の最低プロトコル・バージョンがサポートされていない場合、WebLogic Serverはそれより前のプロトコル・バージョンおよびサポートされるこれ以降のバージョンすべてを有効にします。
例:

指定するプロトコル

CerticomベースSSL実装でサポートされるプロトコル

有効となるプロトコル

TLSv1.1

V2HELLO_SSL3_TLS1
TLS1_ONLY

TLS1_ONLY

SSLv3

V2HELLO_SSL3_TLS1
TLS1_ONLY

V2HELLO_SSL3_TLS1

- 指定する特定の最低プロトコル・バージョンが無効な場合、WebLogic Serverは、SSL V3.0およびサポートされるこれ以降のプロトコル・バージョンすべてを有効にします。
例:

指定するプロトコル

CerticomベースSSL実装でサポートされるプロトコル

有効となるプロトコル

TSLv0

V2HELLO_SSL3_TLS1
TLS1_ONLY

V2HELLO_SSL3_TLS1

JSSEベースSSL実装の使用

Certicomは現在、Weblogic ServerのデフォルトSSL実装です。ただし、JSSEは代替のSSL実装として有効化できます。

注意:

Certicom SSL実装は、現在は非推奨となっており、将来のリリースでJSSEベース実装に置き換えられます。

このリリースでは、FIPSモードのJSSEはデフォルトではサポートされません。バンドルされている別途インストールが必要なパッチで使用可能になるRSA JSSEプロバイダが必要です。詳細は、付録A「FIPSモードの有効化」を参照してください。

次のトピックでは、JSSEベースのSSL実装の使用方法、およびCerticomベースの実装との主な違いについて説明します。

- JSSEベースSSL実装の有効化と無効化

- JSSEベース実装とCerticom SSL実装とのシステム・プロパティの相違

- 暗号スイート

- JSSE SSLでのデバッグの使用

JSSEベースSSL実装の有効化と無効化

WebLogic Server用のJSSEベースSSL実装は、次の方法で有効化/無効化できます。

- WebLogic Server管理コンソールを使用する場合

- システム・プロパティを使用する場合

- プログラムを使用する場合

スタンドアロン・クライアント用のJSSEベースSSL実装は、システム・プロパティからも有効化/無効化できます。

以降の項でこれらのオプションについて説明します。

管理コンソールからのWebLogic Server用JSSEベースSSLの有効化/無効化

管理コンソールの「環境」>「サーバー」>「サーバー名」>「構成」>「SSL」>「詳細」ページを使用して、JSSEベースSSL実装を有効化できます。これによって、出力/入力SSL接続の両方に影響が及ぼされます。

次に、「環境」>「サーバー」>「サーバー名」>「制御」>「起動と停止」ページでSSLを再起動する必要があります。

weblogic.ssl.JSSEEnabledシステム・プロパティからのWebLogic Server用
JSSEベースSSL実装の有効化/無効化

次のサーバー側システム・プロパティを使用すると、SSLMBean.JSSEEnabled属性を初期化することによって、JSSEベースSSL実装を有効化/無効化できます。

-Dweblogic.ssl.JSSEEnabled=true|false

たとえば、-Dweblogic.ssl.JSSEEnabled=trueを使用すると、JSSEベースSSL実装を有効化できます。

このプロパティによって、出力/入力SSL接続の両方に影響が及ぼされます。

プログラムによるWebLogic Server用JSSEベースSSL実装の有効化/無効化

SSLMBeanには、JSSEベースSSL実装を有効化/無効化し、すでに有効化されているかどうかを判定するための、次のsetter/getterメソッド・ペアが含まれます。これらのメソッドによって、出力/入力SSL接続の両方に影響が及ぼされます。

void setJSSEEnabled(boolean enabled);

boolean isJSSEEnabled();

変更は、次回サーバー再起動時に有効になります。

SSLMBeanの詳細は、Oracle WebLogic Server MBeanリファレンスのSSLMBeanに関する項を参照してください。

スタンドアロン・クライアント用JSSEベースSSL実装の有効化/無効化

スタンドアロン・クライアントでシステム・プロパティweblogic.security.SSL.enableJSSE=true|falseを使用して、JSSEベースSSL実装を有効および無効にします。デフォルトはfalseです。

JSSEベース実装とCerticom SSL実装とのシステム・プロパティの相違

表12-2では、JSSEベースSSL実装によるWebLogicシステム・プロパティの処理の違いを示しています。

表12-2 システム・プロパティの相違

システム・プロパティ

JSSEの適用性

説明

weblogic.security.SSL.ignoreHostnameVerification

このプロパティは引き続き機能し、JSSE統合による影響はありません。

証明書のホスト名に対してURLのホスト名を検証しません。

weblogic.ReverseDNSAllowed

このプロパティは引き続き機能し、JSSE統合による影響はありません。

trueに設定すると、逆引きDNSルックアップを使用して、urlhostnameがループバック・アドレス(localhostまたは127.0.0.1、あるいはIPV6の等価物)であるかどうかを判断します。

weblogic.security.SSL.trustedCAKeyStore

このプロパティは引き続き機能し、JSSE統合による影響はありません。

キーストアから信頼できるCA証明書をロードします。

weblogic.security.SSL.verbose

このプロパティをjavax.net.debug=allと組み合せて使用し、詳細デバッグ出力をSSL呼出しコードおよびJSSEベース実装から取得します。脚注 1

-Dssl.debug=trueが使用される場合の追加のSSLデバッグ用。

ssl.debug=true

このプロパティをjavax.net.debug=sslと組み合せて使用し、デバッグ出力をSSL呼出しコードおよびJSSEベース実装から取得します。脚注 1

SSLデバッグ情報をコンソールまたはログに表示します。このプロパティは、呼出し側のWebLogicコード用です。JSSEベースSSL実装には、javax.net.debugプロパティによってアクティブ化される独自のロギング・システムが含まれます。

注意: JSSEロギング(javax.net.debug)をWebLogic SSLロギング(ssl.debug)と別個に設定できます。

weblogic.security.SSL.disableJsseCipherSuiteAliases=true|false

デフォルトはfalseです。

必要に応じて、Certicom暗号スイート名のSunJSSE暗号スイート名への変換を無効化します。デフォルトでは、Certicom暗号スイート名は、JSSEがSSLに使用されているとき、JSSE暗号スイート名に変換されます。

Certicom暗号スイート名とそれらのSunJSSEの等価物のリストは、表12-3を参照してください。

weblogic.security.SSL.ignoreHostnameVerify

このプロパティは引き続き機能し、JSSE統合による影響はありません。

weblogic.security.SSL.ignoreHostnameVerificationを参照してください。

weblogic.security.SSL.HostnameVerifier=classname

このプロパティは引き続き機能し、JSSE統合による影響はありません。

カスタム・ホスト名検証クラスのクラス名を指定します。

weblogic.security.SSL.protocolVersion=protocol

このプロパティは引き続き機能し、JSSE統合による影響はありません。

サポートされるプロトコルの値は、JSSEでサポートされる同等のプロトコルにマップされます。

「SSLプロトコルのバージョンの指定」を参照してください。

次のうちいずれか。

- weblogic.security.SSL.allowUnencryptedNullCipher

- SSLMBean. SetAllowUnencryptedNullCipher(boolean)

- weblogic.security.disableNullCipher

SunJSSEは次の2つのNull暗号をサポートしますが、デフォルトでは有効ではありません。

- SSL_RSA_WITH_NULL_MD5

- SSL_RSA_WITH_NULL_SHA

この設定が有効な場合、この2つのNull暗号は暗号リストに追加されます。

デフォルトでは、この制御は設定されず、Null暗号の使用はサーバーで許可されません。このような構成では、SSLクライアントでNull暗号スイートを使用する場合(唯一のサポート対象暗号スイートとしてSSL_RSA_WITH_NULL_MD5を指定)、SSLハンドシェイクは失敗します。

この制御を設定した場合、Null暗号スイート(SSL_RSA_WITH_NULL_MD5など)が、サポートされる暗号スイートのリストにサーバーによって追加されます。SSL接続では、クライアントが求めた場合にNull暗号スイートが使用する場合があります。Null暗号スイートが使用される合、メッセージは暗号化されません。

注意: 設定の意味とその結果を把握しないかぎり、本番環境ではこの制御を設定しないでください。

weblogic.security.SSL.enforceConstraints=option

Offはサポートされていませんが、他のオプションはサポートされています。

CA証明書の基本制約拡張が確実にCAとして定義されることを確認します。「証明書検証のレベルの制御」を参照してください。

weblogic.security.SSL.allowedcertificatepolicyids

サポートされません。

WebLogic Serverでは、X.509証明書の証明書ポリシー拡張機能に対するサポートが制限されます。「証明書の証明書ポリシーの許可」を参照してください。

weblogic.security.SSL.nojce

サポートされません。

「SSLの設定: 主な手順」を参照してください。

脚注 1  このWebLogicシステム・プロパティは、CerticomとJSSEベースSSL実装の両方に適用できます。ただし、JSSEの場合、このプロパティはSSL呼出しコードにのみ影響を及ぼし、JSSEベース実装には影響を及ぼしません。javax.net.debugシステム・プロパティおよびJSSEベースSSL実装のデバッグに関する詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug)のユーティリティのデバッグに関する項を参照してください。

暗号スイート

このトピックには次のセクションが含まれます:

- サポートされる暗号スイートのリスト

- サポートされる暗号スイートの後方互換性

- 暗号スイート名の等価物

- WLSTを使用した暗号スイートの設定: サンプル

サポートされる暗号スイートのリスト

JDK JSSEプロバイダSunJSSEによってサポートされる暗号化スイート・セットは、JDK 6およびJDK 7用の次のURLからダウンロードできます。

http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

サポートされる暗号スイートの後方互換性

後方互換性のために、JSSEベースのSSL実装はSunJSSEと互換性のある暗号スイートのCerticom暗号スイート名を受け入れます。(Certicom暗号スイートのリストについては、『Oracle WebLogic Serverセキュリティの理解』の暗号スイートに関する項を参照してください。)Certicom暗号スイート名は、SunJSSEの対応する名前に変換され、表12-3に示すように、通常は接頭辞「TLS_」が「SSL_」で置き換えられます。

Certicom暗号スイートとの後方互換性を考慮する上で、次のことを念頭においてください。

- JSSEでは、デフォルトで選択されている暗号スイートはCerticom SSLと比較して強力ですが、パフォーマンスが低くなります。通常は、使用している環境のセキュリティ・ポリシーで、使用する必要のある暗号スイートの要件を設定します。ただし、非常にセキュアな環境の場合、許容できるパフォーマンスを提供する使用可能な最強の暗号を使用することをお薦めします。

- 有効な暗号スイートまたはサポートされる暗号スイートが返される操作では、暗号スイートのCerticom名とSunJSSE名がどちらも返されます。(表12-2で説明されるように、weblogic.security.SSL.disableJsseCipherSuiteAliases=trueプロパティはこの動作を無効にします。)

- 有効化された暗号スイートを指定する操作の場合、等価なCerticom暗号スイート名またはSunJSSE名のいずれかを使用できます。Certicom暗号スイートとそれらのSunJSSEの等価物は、表12-3にリストされています。

- _DSS_暗号スイートの場合、NIST FIPS Pub 186で定義されるDSS (Digital Signature Standard)で署名された証明書が必要です。DSAは、FIPS 186で説明されている鍵生成スキームです。

- _anon_暗号スイートはデフォルトで無効であり、WebLogic Server管理コンソールで管理できません。「WLSTを使用した暗号スイートの設定: 一例」で説明されているように、かわりにWLSTを使用する必要があります。

- Kerberos暗号スイートTLS_KRB5_***を使用するには、KDCアカウントを設定する必要があります。Kerberos要件の詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

暗号スイート名の等価物

デフォルトでは、WebLogic ServerがJSSEベースのSSL実装を使用するように構成されるとき、Certicom暗号スイート名はSunJSSE暗号スイート名に変換されます。表12-3は、WebLogic Server Certicom SSL実装とそのSunJSSEの等価物でサポートされる各暗号スイートをリストで表示します。TLS_名はCerticom暗号スイート名で、SSL_名は、等価なSunJSSEプロバイダの暗号スイート名です。

表12-3 暗号スイート名の等価物

Certicom暗号スイート

SunJSSEの等価な暗号スイート

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

SSL_DHE_DSS_WITH_DES_CBC_SHA

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_RSA_WITH_DES_CBC_SHA

SSL_DHE_RSA_WITH_DES_CBC_SHA

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

TLS_DH_anon_WITH_DES_CBC_SHA

SSL_DH_anon_WITH_DES_CBC_SHA

TLS_DH_anon_WITH_RC4_128_MD5

SSL_DH_anon_WITH_RC4_128_MD5

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5

SSL_RSA_EXPORT_WITH_RC4_40_MD5

TLS_RSA_WITH_3DES_EDE_CBC_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_DES_CBC_SHA

SSL_RSA_WITH_DES_CBC_SHA

TLS_RSA_WITH_RC4_128_MD5

SSL_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_SHA

SSL_RSA_WITH_RC4_128_SHA

WLSTを使用した暗号スイートの設定: サンプル

次のサンプルは、暗号スイートSSL_RSA_WITH_RC4_128_MD5、SSL_RSA_WITH_RC4_128_SHAおよびSSL_RSA_WITH_3DES_EDE_CBC_SHAを設定するWLSTスクリプトの使用を示しています。このスクリプトを実行すると、暗号スイートがドメイン構成(config.xmlファイル)に設定され、SSLリスナーがこの新しい暗号スイート設定で再起動されます。

url="t3://localhost:7001"
adminUsername="weblogic"
adminPassword="welcome1"
connect(adminUsername, adminPassword, url)
edit()
server=cmo.lookupServer('myserver')
cd('Servers')
cd('myserver')
startEdit()
cd('SSL')
cd('myserver')
ssl = server.getSSL()
ciphers = ['SSL_RSA_WITH_RC4_128_MD5', 'SSL_RSA_WITH_RC4_128_SHA', 'SSL_RSA_WITH_3DES_EDE_CBC_SHA']
ssl.setCiphersuites(ciphers)
save()
activate()
disconnect()
exit()

JSSE SSLでのデバッグの使用

「SSLデバッグ」で説明するように、SSLデバッグにより、SSLハンドシェイクで生じたSSLイベントに関する詳細情報が提供されます。

JSSEベースSSL実装が有効化されているときにSSLをデバッグする場合、Certicom SSL実装が有効化されているときと同じデバッグ・ロギング・プロパティを使用できます。これらのロギング・プロパティは、表12-2のリストで説明されています。ただし、JSSEベースSSL実装が有効化されているとき、一部のプロパティはSSL呼出しコードにのみ影響を及ぼし、JSSE実装には影響を及ぼしません。JSSEベースSSL実装には、javax.net.debugプロパティによってアクティブ化される独自のロギング・システムが含まれます。javax.net.debugプロパティは、出力量を超える複数の制御レベルを提供し、WebLogic SSLロギング(ssl.debug)とは別個に使用できます。

javax.net.debugプロパティの詳細は、次のURLからダウンロードできるJava Secure Socket Extension (JSSE)リファレンス・ガイドのユーティリティのデバッグに関する項を参照してください。

http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug

X.509証明書失効チェック

WebLogic ServerのJSSE実装は、X.509証明書失効(CR)チェックをサポートしています。ここでは、SSL証明書パス検証プロセスの一部として、証明書の失効ステータスがチェックされます。CRチェックでは、受け取った証明書が発行認証局によって無効にされていないことを確認することにより、証明書使用のセキュリティが向上します。

次の項では、WebLogic ServerのX.509証明書失効チェックのサポートについて説明します。

- 証明書失効チェックの概要

- デフォルトのCRチェック構成の有効化

- WebLogic Serverで使用するCRチェック方法の選択

- 失効ステータスを特定できない場合のSSL証明書パス検証の失敗

- Online Certificate Status Protocolの使用

- 証明書失効リストの使用

- 認証局オーバーライドの構成

証明書失効チェックの概要

WebLogic Serverでは、次のようないくつかの目的でCRチェックを使用できます。

- インバウンドSSL - クライアント証明書の検証

- アウトバウンドSSL - サーバー証明書の検証

WebLogic ServerのCRチェック・メカニズムには、次の機能があります。

- 次の証明書失効方法のサポート

- Online Certificate Status Protocol (OCSP)

- 証明書失効リスト(CRL)

- ドメイン規模ですべての認証局(CA)に対してCRチェックを構成できます。必要に応じて、特定のCAに対して認証局オーバーライドを構成することもできます。
認証局オーバーライドには、特定のCAにより発行された証明書に対して有効にする、ドメイン規模のCRチェック構成への変更が含まれます。たとえば、特定のOCSP応答者URLを使用するように構成したり、証明書失効ステータスを特定できない場合にSSL証明書パス検証が失敗するように指定できます。作成する各認証局オーバーライドは、特定の1つのCAにのみ適用されます。

WebLogic Serverでは、CRチェックはデフォルトで無効です。ただし、WebLogic Server管理コンソールまたはWLSTを使用して、CRチェックを有効にし、後続の項で説明するプロパティを構成できます。

注意:
WebLogic ServerインスタンスでCRチェックが使用できるのは、JSSEが有効な場合のみです。詳細は、「JSSEベースSSL実装の有効化と無効化」を参照してください。

デフォルトのCRチェック構成の有効化

WebLogic Serverでは、CRチェックはデフォルトで無効です。ただしCRチェックを有効にすると、WebLogic Serverはドメイン規模で、検証する各証明書の現在の失効ステータスを取得する包括的なメカニズムを提供します。ここでは、CRチェックを有効にした場合のWebLogic Serverのデフォルトの動作について説明します。後続の項では、ドメイン規模または選択的に特定の認証局に対して適用できるカスタマイズについて説明します。

デフォルトのCRチェック構成が有効な場合、WebLogic ServerはSSL証明書パスの検証時に自動的に次のことを行います。

1. OCSPレスポンス・ローカル・キャッシュをチェックして証明書失効ステータスを取得します。OCSPレスポンス・ローカル・キャッシュは、OCSP応答者により提供される最新の証明書ステータスを保持するインメモリー・キャッシュです。
OCSPの証明書ステータスには特定の有効期間があります。証明書ステータスの期限が切れると、WebLogic Serverは次のことを行います。

1. 証明書からOCSP応答者URIを取得します。このURIは、証明書のAuthority Information Access (AIA)値に含まれます。このAIAは、証明書の発行者から情報およびサービスにアクセスする方法を示します。

2. OCSP応答者にOCSPリクエストを送信します。
OCSP応答者はOCSPレスポンスを返します。レスポンスにはgood、revokedまたはunknownの証明書ステータスが含まれます。

3. OCSPレスポンス・ローカル・キャッシュをOCSPレスポンスで更新します。

OCSPレスポンス・ローカル・キャッシュにおいて有効で期限内のエントリのある証明書の場合、WebLogic Serverは新しいOCSPレスポンスをリクエストするかわりに、キャッシュからその失効ステータスを取得できます。これにより、パフォーマンスが向上し、ネットワーク帯域幅の使用量が削減されます。

注意:
次の点に注意してください。

- キャッシュされたエントリはOCSP有効期間に基づいて失効しますが、キャッシュ動作はカスタマイズできます。

- OCSP nonceが有効な場合、ローカルのOCSPレスポンス・キャッシュは使用されません。これにより、最新のレスポンスが保証されます。

2. 証明書のOCSPステータスがunknownの場合、WebLogic Serverは、CRLローカル・キャッシュで有効なCRLをチェックし、証明書が失効しているかどうかを判断します(OCSPでrevokedまたはnot revokedのステータスが特定されると、CRLはその証明書で使用されません)。
デフォルトで、CRLローカル・キャッシュは、WebLogicドメイン内の各サーバー・インスタンスで維持され、CRL配布ポイントから必要に応じて更新されるファイルベース・ストアです。CRL配布ポイントは、ダウンロード用にCRLを提供するネットワーク・アクセスが可能なサーバーです。

CRLローカル・キャッシュに有効なCRLがない場合、WebLogic Serverは次のことを行います。

1. 証明書のCRLDistributionPoints拡張に含まれるCRL配布ポイントURLを取得します。

2. CRL配布ポイントURLを使用して、新しいCRLをダウンロードし、キャッシュに追加します。

3. CRLでその証明書に対応するエントリを検索します。

発行者からのCRLに証明書のシリアル番号がない場合、証明書ステータスはnot revokedに設定されます。

次の点に注意してください。

- 証明書にrevokedのOCSPステータスがあるか、証明書が有効なCRLに含まれている場合、WebLogic Serverでは自動的にSSL証明書パス検証が失敗します。

- OCSPを使用して使用可能なCRLをチェックした後、失効ステータスが不明または特定できない場合、デフォルトでは証明書パス検証は失敗しません。

デフォルトのCRチェックの構成

WebLogicドメインでのデフォルトのCRチェック機能の有効化は、次のMBean属性より行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.CheckingEnabled

CRチェックがドメイン規模で有効かどうかを指定します。

False

WebLogic Server管理コンソールを使用してWebLogicドメインのCRチェックを有効にする方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。

このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。

CRチェック構成のカスタマイズ

WebLogic ServerのデフォルトのCRチェック動作は、CRチェックが望まれるが必須ではないデプロイメント環境に適しています。環境によって、CRチェックを必要としたり、特定の認証局に固有の動作をさせることが必要な場合があります。表12-4は、WebLogic ServerでCRチェックに対して行うことができるカスタマイズのタイプを一覧形式でまとめ、それらについて説明している各項へのリンクを示しています。

表12-4 CRチェック構成に対して行うことができるカスタマイズ

カスタマイズ

説明

CRチェック方法の順序

サポートされるCRチェック方法(OCSPとCRL)が使用される順序を指定します。必要に応じて、OCSPのみまたはCRLのみを使用するよう選択できます。「WebLogic Serverで使用するCRチェック方法の選択」を参照してください。

証明書失効ステータスの必要性

証明書の失効ステータスが不明または特定できない場合、SSL証明書パス検証は失敗する必要があることを指定します。「失効ステータスが特定できない場合のSSL証明書パス検証の失敗」を参照してください。

ドメイン規模のOCSP設定

次のOCSP機能または動作のうち1つ以上をドメイン規模でカスタマイズします。

- OCSPのリクエストおよびレスポンスでのNonceの使用

- OCSPレスポンス・キャッシュ。たとえば、容量、リフレッシュ期間など。

- OCSPレスポンスのタイムアウト時間設定

詳細は、「Online Certificate Status Protocolの使用」を参照してください。

ドメイン規模のCRLプロトコル設定

次のCRL機能または動作のうち1つ以上をドメイン規模でカスタマイズします。

- CRL配布ポイントの使用

- CRLキャッシュのリフレッシュ頻度

- CRL配布ポイントのダウンロード・タイムアウト時間設定

詳細は、「証明書失効リストの使用」を参照してください。

認証局オーバーライド

特定のCAにより発行された証明書に対し、CRチェック動作をカスタマイズします。例:

- これらの証明書に対する失効チェックの無効化

- CRチェック方法の順序の変更

- 失効ステータスが不明または使用できない場合の証明書パス検証の自動的な失敗

- OCSPまたはCRL設定のカスタマイズ(CRLローカル・キャッシュ設定を除く)

- 使用するOCSP応答者URLの指定

- 使用するCRL配布ポイントURLの指定

認証局オーバーライドは、常に既存のドメイン規模の設定より優先されます。詳細は、「認証局オーバーライドの構成」を参照してください。

WebLogic Serverで使用するCRチェック方法の選択

デフォルトでは、証明書の失効ステータスをチェックする際、WebLogic Serverは最初にOCSPを使用します。OCSPが証明書ステータスをunknownとして返すと、WebLogic ServerはCRLを使用します。ただし、使用するCRチェック方法やその方法の使用順序を、次のいずれかに変更できます。

- OCSPのみ

- CRLのみ

- OCSP、CRLの順 - 証明書のOCSPステータスがunknownとして返されると、CRLで証明書ステータスがチェックされます。

- CRL、OCSPの順 - 使用可能なCRLのチェックで証明書の失効ステータスが特定できない場合、OCSPのステータスがチェックされます。

WebLogicドメインのCRチェック方法および順序の構成は、次のMBean属性より行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.MethodOrder

ドメイン規模のCRチェック方法を指定します。

OCSP_THEN_CRL

このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。

WebLogic Server管理コンソールを使用してWebLogicドメインのCRチェック方法および順序を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。

失効ステータスを特定できない場合のSSL証明書パス検証の失敗

デフォルトでは、X.509証明書の失効ステータスが選択したチェック方法で特定できない場合でも、SSL証明書パス検証が成功すれば、証明書を受け入れることができます。ただし、失効ステータスを特定できない証明書については、証明書パス検証が失敗するようにWebLogic Serverを構成することもできます。

失効ステータスを特定できない場合にSSL証明書パス検証が失敗するようなWebLogicドメインの構成は、次のMBean属性より行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.FailOnUnknownRevocStatus

失効ステータスが特定できない場合に証明書のパス検証が失敗するかどうかをドメイン規模で指定します。

False

このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。

WebLogic Server管理コンソールを使用してこのMBean属性を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。

Online Certificate Status Protocolの使用

Online Certificate Status Protocol (OCSP)は、RFC 2560で定義されている自動証明書チェック・ネットワーク・プロトコルです。証明書検証の一部として、WebLogic ServerはOCSP応答者にOCSPリクエストを発行することにより、証明書の失効ステータスを問い合せます。証明書ステータスはOCSP応答者により保持されます。証明書の受入れは、証明書が今もなお発行元のCAにより信頼されているかどうかを示すOCSPレスポンスを応答者が返すまで保留されます。

OCSPは、CRLよりタイムリーな失効情報の提供という運用上の要件を満たすために使用されたり、追加のステータス情報を取得するために使用される場合があります。OCSPの詳細は、RFC 2560(http://www.ietf.org/rfc/rfc2560.txt)の説明を参照してください。

次の項では、WebLogic ServerでOCSPを構成する方法について説明します。

- OCSPリクエストでのNonceの使用

- レスポンス・タイムアウト時間の設定

- OCSPレスポンス・ローカル・キャッシュの有効化および構成

OCSPリクエストでのNonceの使用

Nonceは、OCSPリクエストに含まれている場合に新しいレスポンスを強制する(事前に署名されたレスポンスは拒否される)乱数です。Nonceを使用することで、反射攻撃を防止できます。デフォルトでは、WebLogic ServerはOCSPリクエストにNonceを含めません。

ただし、OCSPでNonceを使用するようにWebLogic Serverが構成されている場合、次のようになります。

1. WebLogic Serverは、各OCSPリクエストに対してNonceを生成し、これをリクエストの拡張内に含めます。

2. 署名されたOCSPレスポンスは、レスポンスの拡張内に含められるものと同じNonceを含む必要があります。

WebLogicドメインでOCSP Nonceを使用する構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.OcspNonceEnabled

OCSPリクエストに対してNonceを生成するかどうかを指定します。この設定はドメイン規模で行われます。

false

このMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。

WebLogic Server管理コンソールを使用してOCSP nonceを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。

レスポンス・タイムアウト時間の設定

レスポンス・タイムアウト時間は、OCSPレスポンスの待機時間を制限します。タイムアウト時間の設定により、ブロックされるスレッドを最小限に抑え、サービス拒否攻撃に対するシステムの脆弱性も軽減できます。レスポンス・タイムアウト時間の設定に加え、WebLogic ServerとOCSP応答者間のクロック・スキュー差を処理するための許容時間値も構成できます。

デフォルトのレスポンス・タイムアウト時間は10秒、許容時間は0です。レスポンス・タイムアウト時間および許容時間の値は、ドメイン規模で設定することも、必要に応じて1つ以上のCAに対してのみに設定することもできます。

WebLogicドメインのOCSPレスポンス・タイムアウト時間および許容時間値の構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.OcspResponseTimeout

OCSPレスポンスに対し、ドメイン規模のタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。

10

CertRevocMBean.OcspTimeTolerance

OCSPレスポンスに対し、ドメイン規模のOCSP許容時間値を秒単位で指定します。

0

これらのMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。

WebLogic Server管理コンソールを使用してOCSPレスポンス・タイムアウト時間および許容時間の値を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。

OCSPレスポンス・ローカル・キャッシュの有効化および構成

パフォーマンスを最適化し、ネットワークの帯域幅を削減するため、WebLogic ServerのOCSP実装はデフォルトで、OCSPレスポンス・ローカル・キャッシュと呼ばれるOCSPレスポンスを保持するためのローカル・インメモリー・キャッシュを使用するように構成されます。キャッシュされたエントリは、OCSP有効期間やその他の条件(アクセスが最も少ないエントリなど)に基づいて、自動的に失効します。Nonceが有効な場合、Nonceを使用して取得されたOCSPレスポンスはキャッシュされません。これにより、Nonceとともに最新のレスポンスが常に使用されます。

WebLogicドメインでのOCSPレスポンス・ローカル・キャッシュの構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.OcspResponseCacheEnabled

OCSPレスポンス・ローカル・キャッシュが有効かどうかをドメイン規模で指定します。

true

CertRevocMBean.OcspResponseCacheCapacity

OCSPレスポンス・ローカル・キャッシュでサポートされる最大エントリ数を指定します。

1024

CertRevocMBean.OcspResponseCacheRefreshPeriodPercent

OCSPレスポンス・ローカル・キャッシュのリフレッシュ期間をレスポンスの有効期間のパーセンテージで指定します。たとえば、有効期間が10時間の場合、10%という値は1時間後にキャッシュされたレスポンスが失効し、新しいレスポンスが必要になることを示します。

100

このMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。

WebLogic Server管理コンソールを使用してOCSPレスポンス・ローカル・キャッシュを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。

証明書失効リストの使用

証明書失効リスト(CRL)は、発行元の認証局(CA)により無効にされたデジタル証明書のタイムスタンプ付きリストです。各CRLはCAにより署名され、パブリック・リポジトリで使用可能になります。

WebLogic ServerのCRL実装には、次のサポートが含まれます。

- CRLローカル・キャッシュ。これによりCRチェックで効果的なアクセスが可能となります。

- ユーザーが提供したCRLファイルのCRLキャッシュへの自動インポート。

- 必要に応じてCRLキャッシュの移入およびリフレッシュができる配布ポイントの使用。

次の項では、WebLogic ServerでCRLの使用を構成する方法について説明します。

- 配布ポイントからの更新の有効化

- CRLローカル・キャッシュの構成

配布ポイントからの更新の有効化

配布ポイントからのCRLの更新は、デフォルトで有効です。有効化されている証明書の適切なCRLが常にローカル・キャッシュに存在しない場合、そのCRLは使用可能な配布ポイントからダウンロードされます。

WebLogic Serverでは、配布ポイントからのCRLダウンロードのタイムアウト時間を構成することもできます。タイムアウト時間は、CRLダウンロードの待機時間を制限し、ブロックされるスレッドのリスクやサービス拒否攻撃に対する脆弱性を最小限に抑えます。CRLダウンロードがタイムアウトすると、CRLメソッドでは失効ステータスが不明であると報告します。ただし、CRLダウンロードは別のスレッドで完了するまで継続され、そのCRLは将来のCRLチェックで使用可能となります。

WebLogicドメインのCRL配布ポイントの構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.CrlDpEnabled

CRL配布ポイントがドメイン規模で有効かどうかを指定します。

true

CertRevocMBean.CrlDpDownloadTimeout

配布ポイントCRLダウンロードに対し、全体のタイムアウト時間(秒単位)をドメイン規模で指定します。有効範囲は1 - 300です。

10

これらのMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのCRLプロパティの構成」を参照してください。

WebLogic Server管理コンソールを使用してWebLogicドメインのCRL配布ポイントを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のCRL設定の構成に関する項を参照してください。

CRLローカル・キャッシュの構成

WebLogic Serverでは、CRLローカル・キャッシュは自動的に有効になります。CRLの取得は時間のかかるプロセスであるため、CRLは有効な間ローカル・ファイルに格納できます。さらに、WebLogic Serverでは、ローカル・キャッシュのリフレッシュ時間をCRLの有効期間のパーセンテージで表して構成できます。

次のCRLインポート・ディレクトリにコピーすることにより、使用するCRLファイルを提供できます。ここで、server-nameはWebLogic Serverインスタンスの名前を表します。

WL_HOME/servers/server-name/security/certrevocation/crlcache/import

CRLファイルは自動的にインポートされ、内部的にキャッシュされます。このディレクトリは、存在しない場合、CRチェックが有効となりSSL接続が試みられると、自動的に作成されます。

注意:
次の点に注意してください。

- WebLogic Serverが起動された後、CRチェックが有効となり、少なくとも一度、証明書失効ステータスのチェックが試みられると、自動的にCRLファイルのインポートが開始されます。これで、リソースの使用が必要最小限に抑えられます。

- CRLファイルをインポートすると、自動的にインポート・ディレクトリから削除されます。

- CRLローカル・キャッシュ構成設定はドメイン規模で行われます。CRLローカル・キャッシュの認証局オーバーライドは構成できません。

WebLogicドメインのCRLローカル・キャッシュの構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocMBean.CrlCacheRefreshPeriodPercent

CRLローカル・キャッシュのリフレッシュ期間をCRLの有効期間のパーセンテージで指定します。

100

WebLogic Server管理コンソールを使用してWebLogicドメインのCRLローカル・キャッシュを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のCRL設定の構成に関する項を参照してください。

認証局オーバーライドの構成

認証局オーバーライドを構成すると、特定のCAにより発行された証明書に対して実行されるCRチェック動作を指定できます。認証局オーバーライドは、常に有効なドメイン規模のCRチェック構成より優先されます。次の項では、CRチェックのCAオーバーライドを構成する方法について説明します。

- 一般的な認証局オーバーライド

- 認証局オーバーライドのOCSPプロパティの構成

- 認証局オーバーライドのCRLプロパティの構成

一般的な認証局オーバーライド

特定のCAの認証局オーバーライドを作成するには、次の手順を実行します。

1. CAを識別名で識別します。これは、このオーバーライドを適用する証明書の完全な発行者識別名(RFC 2253で定義されています)にする必要があります。
たとえば、WebLogic Server DemoTrust CAの識別名は、CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=USです。

2. 必要に応じて、このCAによって発行された証明書に対してCRチェックを有効にするかどうかを指定します。

3. このCAによって発行された証明書のCRチェック方法と実行順序を指定します。

4. このCAによって発行された証明書の失効ステータスが特定できない場合に、SSL証明書のパス検証が失敗するかどうかを指定します。

5. 必要に応じて、次の項で説明するとおり、OCSPまたはCRLの追加カスタマイズを指定します。

- 認証局オーバーライドのOCSPプロパティの構成

- 認証局オーバーライドのCRLプロパティの構成

CAの一般的な認証局オーバーライドの構成は、次のMBean属性を使用して行うことができます。

MBeanの属性

説明

デフォルト値

CertRevocCaMBean.DistinguishedName

CAサブジェクトの識別名(DN)を指定します。

なし(必須フィールド)

CertRevocCaMBean.CheckingDisabled

このCAに対して、CRチェックが無効かどうかを指定します。

false

CertRevocCaMBean.FailOnUnknownRevocStatus

このCAに対して、証明書失効ステータスが使用可能などの方法でも特定できない場合、SSL証明書のパス・チェックが失敗するかどうかを指定します。

現在のCertRevocMBean.FailOnUnknownRevocStatusの設定と同じです。

CertRevocCaMBean.MethodOrder

このCAによって発行された証明書のチェックの際の証明書失効チェック方法の順序を指定します。

現在のCertRevocMBean.MethodOrderの設定と同じです。

WebLogic Server管理コンソールを使用して認証局オーバーライドを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。

認証局オーバーライドのOCSPプロパティの構成

WebLogic Serverは、そのOCSP実装で次の信頼モデルを試みます。

- Delegated Trust Model (DTM) - OCSPレスポンスは、CAよりレスポンスの署名を行うよう委任されたOCSP応答者によって署名されます。

- Explicit Trust Model (ETM) - OCSPの職責が委任されたオーソリティとCAのいずれもOCSPレスポンスに署名していない場合、明示的に信頼された署名者が指定されます。ETMは、OCSPレスポンス署名の検証に使用される可能性のある信頼性のある追加証明書を提供できる場合に使用されます。これは、オーバーライドに対応するCAとは無関係なものも含め、どの証明書でもかまいません。ETMは、信頼性はあるものの、発行者のかわりにOCSPレスポンスに署名することは許可されていないOCSP応答者に使用できます。明示的に信頼されたOCSP応答者のパブリック証明書は、OCSPサーバーが企業内で内部的に維持される場合に適している場合があります。

- CA署名の信頼モデル - OCSPレスポンスは、失効ステータスが要求されている証明書を発行したCAと同じCAによって署名されると見なされます。

認証局オーバーライドを作成する際、WebLogic Serverでは、表12-5で説明されているOCSPプロパティを構成できます。この表は、これらのオーバーライド・プロパティの構成に使用できるMBean属性も示しています。

表12-5 認証局オーバーライドで指定できるOCSPプロパティ

オーバーライド

説明

MBeanの属性

OCSP応答者URL

次のいずれかで使用されるURLを指定します。

- フェイルオーバー: 証明書のAIA値からのOCSP応答者URIが使用できないかアクセスできない場合

- オーバーライド: 証明書AIAからの応答者URIのかわりに応答者URLとして常に使用

詳細は、「OCSP応答者URLの特定」を参照してください。

CertRevocCaMBean.OcspResponderUrl

デフォルトの値はNoneです。

OCSP応答者URLの使用方法

OCSP応答者URLを、フェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。

CertRevocCaMBean.OcspResponderUrlUsage

デフォルト値はFAILOVERです。

OCSP応答者の証明書サブジェクト名

このCAに対して、明示的信頼のOCSP応答者証明書サブジェクト名を指定します。たとえば、CN=OCSP Responder, O=XYZ Corpのようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書のサブジェクト識別名に対応する必要があります。

サブジェクト名のみで証明書を一意に特定するのに十分でない場合は、かわりにCertRevocCaMBean.OcspResponderCertIssuerNameとCertRevocCaMBean.OcspResponderCertSerialNumberの両方が使用されます。

CertRevocCaMBean.OcspResponderCertSubjectName

デフォルト値はNONEです。

OCSP応答者の証明書発行者名

このCAに対して、明示的に信頼されているOCSP応答者証明書発行者名を指定します。たとえば、CN=Enterprise CA, O=XYZ Corpのようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書の発行者識別名に対応する必要があります。

この属性が設定されている場合、CertRevocCaMBean.OcspResponderCertSerialNumberも設定する必要があります。

CertRevocCaMBean.OcspResponderCertIssuerName

デフォルト値はNONEです。

OCSP応答者の証明書シリアル番号

このCAに対して、明示的に信頼されているOCSP応答者証明書シリアル番号を指定します。たとえば、2A:FF:00のようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書のシリアル番号に対応する必要があります。

この属性が設定されている場合、CertRevocCaMBean.OcspResponderCertIssuerName属性も設定する必要があります。

CertRevocCaMBean.OcspResponderCertSerialNumber

デフォルト値はNONEです。

OCSP応答者の明示的信頼方法

このCAに対して、OCSP明示的信頼モデルが有効であるかどうか、およびWebLogic Server信頼キーストアで信頼性のある証明書を指定する方法を指定します。

以下の値を指定できます。

- NONEは、明示的信頼が無効であることを示します。

- USE_SUBJECTは、信頼性のある証明書が、CertRevocCaMBean.OcspResponderCertSubjectName属性で指定されるサブジェクトDNを使用して特定されることを示します。

- USE_ISSUER_SERIAL_NUMBERは、信頼性のある証明書が、CertRevocCaMBean.OcspResponderCertIssuerNameおよびCertRevocCaMBean.OcspResponderCertSerialNumber属性でそれぞれ指定される発行者DNと証明書シリアル番号を使用して特定されることを示します。

CertRevocCaMBean.OcspResponderExplicitTrustMethod

デフォルト値はNONEです。

Nonceの有効化

このCAに対して、OCSPリクエストとともにNonce(新しい(事前署名されていない)レスポンスを強制適用します)を送信するかどうかを指定します。

CertRevocCaMBean.OcspNonceEnabled

デフォルト値は、現在のCertRevocMBean.OcspNonceEnabledの設定と同じです。

OCSPレスポンス・ローカル・キャッシュ

このCAに対して、OCSPレスポンスのローカル・キャッシュが有効かどうかを指定します。

CertRevocCaMBean.OcspResponseCacheEnabled

デフォルト値は、現在のCertRevocMBean.OcspResponseCacheEnabledの設定と同じです。

OCSPレスポンス・タイムアウト

このCAに対して、OCSPレスポンスのタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。

詳細は、「レスポンス・タイムアウト時間の設定」を参照してください。

CertRevocCaMBean.OcspResponseTimeout

デフォルト値は、現在のCertRevocMBean.OcspResponseTimeoutの設定と同じです。

OCSP許容時間

このCAに対して、WebLogic Serverと応答者間のクロック・スキュー差を処理するための許容時間を秒単位で指定します。有効範囲は0 - 900です。

レスポンスの有効期間は、指定した時間だけ、未来にも過去にも延長され、効果的に有効期間を広げられます。

CertRevocCaMBean.OcspTimeTolerance

デフォルト値は、現在のCertRevocMBean.OcspTimeToleranceの設定と同じです。

WebLogic Server管理コンソールを使用して認証局オーバーライドのOCSP設定を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。

OCSP応答者URLの特定

OCSP応答者ルックアップを使用して証明書を検証するため、WebLogic Serverは次の方法を使用してOCSP応答者URLを特定します。

- 証明書のAuthority Information Access (AIA)値。これは証明書の発行者の情報およびサービスにアクセスする方法を示します。たとえば、AIAにはOCSP応答者のURIが含まれています。

- デフォルトのOCSP応答者フェイルオーバーまたはオーバーライド。OCSP応答者URIが証明書のAIA値から使用できないまたは受け入れられない場合、デフォルトのOCSP応答者URLをCAごとに構成できます。
さらに、CAごとのデフォルトのOCSP応答者URLは、選択的にフェイルオーバーまたはオーバーライドに対して指定できます。オーバーライドに対して指定すると、このURLは証明書のAIA拡張から取得した値を常にオーバーライドします。

WebLogic Server管理コンソールを使用して認証局オーバーライドのOCSP応答者URLを設定する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。

認証局オーバーライドのCRLプロパティの構成

認証局オーバーライドを構成する際、WebLogic Serverでは、表12-6にリストされ、説明されているCRLプロパティを構成できます。この表は、これらのプロパティの構成に使用できるMBean属性も示しています。

表12-6 認証局オーバーライドで指定できるCRLプロパティ

オーバーライド

説明

MBeanの属性

ローカルCRLキャッシュの更新ための配布ポイントの使用

このCAに対して、CRL配布ポイントでローカルCRLキャッシュを更新する処理を有効にするかどうかを指定します。

CertRevocCaMBean.CrlDpEnabled

デフォルト値は、現在のCertRevocMBean.CrlDpEnabledの設定と同じです。

配布ポイントURL

このCAに対して、次の場合に使用されるCRL配布ポイントURLを指定します。

- フェイルオーバー: 証明書のCRLDistributionPoints拡張からのURLが使用できない場合

- オーバーライド: 証明書のCRLDistributionPoints拡張のかわりにCRL配信ポイントURLとして常に使用

CertRevocCaMBean.CrlDpUrl

デフォルト値はnullです。

配布ポイントURLの使用方法

配布ポイントURLをフェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。

CertRevocCaMBean.CrlDpUrlUsage

デフォルト値はFAILOVERです。

配布ポイントのCRLダウンロード・タイムアウト

このCAに対して、配布ポイントCRLダウンロードの全体のタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。

CertRevocCaMBean.CrlDpDownloadTimeout

デフォルト値は、現在のCertRevocMBean.CrlDpDownloadTimeoutの設定と同じです。

WebLogic Server管理コンソールを使用して認証局オーバーライドのCRL設定をカスタマイズする方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。

13 WebLogicドメインのセキュリティの構成

この章では、WebLogic Server 10.3.6でドメインのセキュリティ・オプションを構成する手順について概説します。

この章の内容は以下のとおりです。

- クロス・ドメイン・セキュリティのサポートに関する重要な情報

- WebLogic Serverドメイン間の信頼関係の有効化

- 接続フィルタの使用

- Java Authorization Contract for Containersの使用

- MBean属性の表示

- WebLogic Serverでのパスワードの保護の仕組み

- ユーザー・アカウントの保護

- JAAS認可を使用するドメインの構成

注意:
これらの節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。

クロス・ドメイン・セキュリティのサポートに関する重要な情報

この節では、クロス・ドメイン・セキュリティ・ソリューションのサポートに関する重要な情報について説明します。

「WebLogic Serverドメイン間の信頼の有効化」で説明するように、クロス・ドメイン・セキュリティではドメイン間の信頼関係が確立されて、一方のWebLogic Serverドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。

このリリースのWebLogic Serverでは、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでクロス・ドメイン・セキュリティを実装しています。これらのシステムはドメイン間で必要な資格証明の認証や送信を行うことができます。

ただし、EJBコンテナはクロス・ドメイン・セキュリティのソリューションを実装していません。そのため、WLSクロス・ドメイン・セキュリティ機能は以下の状況では機能しません。

- WLIドメイン

- ALSB。SBトランスポートおよびDSPトランスポートを使用するようにALSBが構成されている場合。

- ALDSPドメイン

これらのタイプのドメインでは、かわりにグローバル信頼機能を使用します。この機能では、各ドメインで同じドメイン資格証明を使用することにより、2つのドメイン間にグローバルな信頼が確立されます。WLSでグローバル信頼を使用する方法については、「グローバル信頼の有効化」を参照してください。

WebLogic Serverドメイン間の信頼関係の有効化

ドメイン間の信頼関係が確立されると、一方のWebLogicドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できます。以前のリリースのWebLogic Serverでは、現在は「グローバル信頼」と呼ばれる1つのタイプのドメイン信頼しかありませんでした。現在のWebLogic Serverでは、「クロス・ドメイン・セキュリティ」というドメイン信頼もサポートされています。次の項では、各ドメイン信頼の種類を構成する方法を説明します。

- WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化

- グローバル信頼の有効化

WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化

注意:
クロス・ドメイン・セキュリティを有効にする前に、「クロス・ドメイン・セキュリティのサポートに関する重要な情報」を参照してください。

クロス・ドメイン・セキュリティでは、資格証明マッピング・プロバイダを使用してWebLogicドメイン間の通信を構成することにより、2つのWebLogicドメイン間に信頼が確立されます。クロス・ドメイン・セキュリティの構成および使用方法については、次の項を参照してください。

- クロス・ドメイン・セキュリティの構成

- クロス・ドメイン・ユーザーの構成

- クロス・ドメイン・セキュリティ用の資格証明マッピングの構成

WebLogic Serverでは、クロス・ドメイン・セキュリティを実現する方法として、資格証明マッピング・セキュリティ・プロバイダを使用する方法だけでなく、2つ以上のドメインで同じドメイン資格証明を使用してグローバル信頼を確立する方法もサポートされています。2つ以上のドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合には、ドメインAもドメインCを信頼し、ドメインBとドメインCの両方がドメインAを信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、クロス・ドメイン・セキュリティを使用する方法です。これは、クロス・ドメイン・アクション専用のユーザー・グループとロールを使用する後者のほうが、セキュリティをより細かく設定できるためです。WebLogic Serverでグローバル信頼を使用する方法については、「グローバル信頼の有効化」を参照してください。

クロス・ドメイン・セキュリティの構成

WebLogicドメインでクロス・ドメイン・セキュリティを構成するには、SecurityConfigurationMBean.CrossDomainSecurityEnabled属性をtrueに設定します。この操作は、WebLogic Server管理コンソールで行います。

1. ホームページの「ドメイン構成」セクションでドメイン名をクリックします。

2. 「セキュリティ」→「全般」を選択します。

3. 「クロス・ドメイン・セキュリティの有効化」を選択します。

一部のWebLogicドメインでクロス・ドメイン・セキュリティを有効にしない場合は、それらのドメイン名をSecurityConfigurationMBean.ExcludedDomainNames属性の除外ドメインのリストに追加する必要があります。この操作は、WebLogic Server管理コンソールで行います。

1. ホームページの「ドメイン構成」セクションでドメイン名をクリックします。

2. 「セキュリティ」→「全般」を選択します。

3. 「除外するドメイン名」フィールドに、クロス・ドメイン・セキュリティを有効にしないドメインの名前をすべて入力します。複数のドメイン名を入力する場合は、セミコロンで区切るか、改行を挿入します。

クロス・ドメイン・ユーザーの構成

WebLogic Serverのクロス・ドメイン・セキュリティでは、CrossDomainConnectorというグローバル・セキュリティ・ロール(リソース・タイプはリモート)と、CrossDomainConnectorsというグループ(CrossDomainConnectorロールを割り当てるグループ)を使用します。リモート・ドメインからの呼出しリクエストは、CrossDomainConnectorロールのユーザーから実行する必要があります。デフォルトでは、CrossDomainConnectorsグループにユーザーは登録されていません。1つまたは複数のユーザーを作成し、CrossDomainConnectorsグループに追加する必要があります。このようなユーザーとしては、通常は仮想的なシステム・ユーザーを使用し、できればCrossDomainConnectorセキュリティ・ロールによって付与される権限のみを付与するようにしてください。

クロス・ドメイン・セキュリティ用の資格証明マッピングの構成

注意:
資格証明マッパーは、ドメインをその名前で識別します。したがって、信頼関係に関与する各ドメインに一意の名前を付けることが重要です。

各WebLogicドメインでは、各ユーザーが信頼すべき各リモート・ドメインで使用する資格証明を指定する必要があります。そのためには、接続するドメインごとに資格証明マッピングを構成します。各資格証明マッピングでは、次を指定する必要があります。

- リソース・プロトコル(cross-domain-protocol)

- ローカル・ドメインと対話する必要のあるリモート・ドメインの名前

- ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーの名前

- ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーのパスワード

クロス・ドメイン・セキュリティ用の資格証明マッピングを構成するには、WebLogic Server管理コンソールの左パネルで「セキュリティ・レルム」をクリックします。

1. セキュリティ・レルムの名前をクリックします(デフォルトはmyrealm)。

2. 「資格証明マッピング」→「デフォルト」を選択して、「新規」をクリックします。

3. 「セキュリティ資格証明マッピングのリモート・リソースを作成」ページで次の操作を行います。

- 「クロスドメイン・プロトコルの使用」を選択します。

- 「リモート・ドメイン」フィールドに、ローカル・ドメインと対話する必要のあるリモート・ドメインの名前を入力します。

4. 「次へ」をクリックします。

5. 「新しいセキュリティ資格証明マップ・エントリの作成」ページで次の内容を入力します。

- ローカル・ユーザー: cross-domain

- リモート・ユーザー: ローカル・ドメインとの対話を認可されたリモート・ドメインに構成されているユーザー。

- パスワード: リモート・ユーザーのパスワード。

6. 「終了」をクリックします。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクロス・ドメイン・セキュリティの資格証明マッピングの作成に関する項を参照してください。

グローバル信頼の有効化

警告:
WebLogicドメイン間のグローバル信頼を有効にすると、サーバーは中間者攻撃に対して無防備な状態になる可能性があります。本番環境で信頼関係を有効にする場合、十分に注意を払う必要があります。専用の通信チャネルなどの強力なネットワーク・セキュリティや、強力なファイアウォールによる保護の実施をお薦めします。

WebLogic Serverでは、2つ以上のドメインの間にグローバル信頼を確立できます。そのためには、それぞれのドメインに同じドメイン資格証明を指定します。ドメイン資格証明はデフォルトではランダムに生成されるため、2つのドメインが同じドメイン資格証明を持つことはありません。2つのWebLogicドメインを相互運用する場合は、生成された資格証明を選択した資格証明で置き換えて、同じ資格証明をそれぞれのドメインで設定する必要があります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン間のグローバル信頼の有効化に関する項を参照してください。

2つのドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合には、ドメインAもドメインCを信頼し、ドメインBとドメインCの両方がドメインAを信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」で説明した資格証明マッパーを使用する方法です。これは、後者のほうがセキュリティをより細かく制御できるためです。

ドメイン間のグローバル信頼が確立されると、一方のWebLogicドメインのサブジェクト内のプリンシパルがもう一方のドメインのプリンシパルとして受け付けられます。この機能が有効になると、2番目のドメインでは認証が要求されることなく、IDがWebLogicドメイン間をRMI接続で渡されます (たとえば、ドメイン1にJoeとしてログインして、ドメイン2に対してRMI呼出しを行うと、Joeは引き続き認証されます)。WebLogic Serverは、プリンシパルの作成時にドメイン資格証明でプリンシパルに署名します。サブジェクトがリモート・ソースから受信されると、そのプリンシパルが検証されます(署名が再作成され、それが一致するとリモート・ドメインは同じドメインの資格証明を持ちます)。検証が失敗すると、エラーが生成されます。検証が成功すると、そのプリンシパルはローカルで作成されたかのように信頼されます。

注意:
クリア・テキスト形式の資格証明は、次にconfig.xmlファイルがディスクに保存されるときに暗号化されます。

管理対象サーバー環境でドメイン間のグローバル信頼を有効にする場合は、両方のドメインの管理サーバーとすべての管理対象サーバーを停止してから、再起動する必要があります。この手順を行わないと、再起動されなかったサーバーでは、再起動されたサーバーが信頼されなくなります。

WebLogicドメイン間のグローバル信頼を有効化するときには、次の点に注意してください。

- ドメインは認証を必要とせずにリモート・プリンシパルを信頼するので、ドメインの認証データベースに定義されていない、認証済みユーザーがドメイン内に存在できることになります。この状況により、認可の問題が発生するおそれがあります。

- ドメイン内の認証済みユーザーは、元のドメインとの信頼関係が有効化されている他のドメインに再認証なしでアクセスできます。こうしたログインに対する監査はなく、グループ・メンバーシップは検証されません。そのため、Joeが、認証された元のドメインのAdministratorsグループのメンバーである場合、Joeは自動的にRMI呼出しの対象となるすべての信頼されたドメインのAdministratorsグループのメンバーになります。

- ドメイン2がドメイン1とドメイン3の両方を信頼している場合、ドメイン1とドメイン3は暗黙的にお互いを信頼するようになっています。そのため、ドメイン1のAdministratorsグループのメンバーは、ドメイン3のAdministratorsグループのメンバーになります。こうした信頼関係は、本来目的とする信頼関係ではない場合もあります。

- WLSUser PrincipalクラスおよびWLSGroup Principalクラスを拡張した場合、カスタムPrincipalクラスは、信頼を共有するすべてのドメインのサーバーのCLASSPATHにインストールされる必要があります。

これらの問題を回避するため、2つのドメイン間でグローバル信頼を有効にする方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」の説明に従って、CrossDomainConnectorロールのユーザーを構成して資格証明マッピングを使用する方法をお薦めします。

接続フィルタの使用

接続フィルタを使用すると、ネットワーク・レベルでアクセスを拒否できます。接続フィルタは、個々のサーバー、サーバー・クラスタ、または内部ネットワーク(イントラネット)にあるサーバー・リソースの保護に使用できます。たとえば、ユーザーの企業のネットワーク外部からの非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレス、およびDNSノード名に基づいてフィルタ処理するよう構成できる点において一種のファイアウォールです。

接続フィルタは、管理ポートを使用する場合に特に便利です。ネットワーク・ファイアウォール構成によっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスをドメイン内のサーバーやマシンのみに制限するために使用されることが考えられます。攻撃者がファイアウォールの内側にあるマシンにアクセスできても、それが許可されたマシンでない限り、管理操作を実行することはできません。

WebLogic Serverでは、weblogic.security.net.ConnectionFilterImplというデフォルトの接続フィルタが用意されています。この接続フィルタは、すべての着信接続を受け入れます。また、サーバーは、このクラスが提供する静的ファクトリ・メソッドを使うことで、現在の接続フィルタを取得できます。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic管理コンソールで接続フィルタ・ルールを入力するだけです。

また、weblogic.security.netパッケージのクラスを実装することで、カスタム接続フィルタを使用することもできます。接続フィルタの記述については、『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使い方に関する項を参照してください。デフォルト接続フィルタと同じように、カスタム接続フィルタもWebLogic管理コンソールで構成できます。

接続フィルタを構成するには:

1. 受信メッセージのロギングを有効にします。「接続ログを有効化」オプションを使用すると、成功した接続と接続データがサーバーの接続ログに記録されます。この情報は、サーバーの接続に関連する問題をデバッグするために使用できます。

2. ドメインで使用する接続フィルタを選択します。

- デフォルト接続フィルタを構成するには、「接続フィルタ」にweblogic.security.net.ConnectionFilterImplを指定します。

- カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを「接続フィルタ」フィールドで指定します。このクラス名は、WebLogic ServerのCLASSPATHにも指定する必要があります。

3. 接続フィルタのルールの構文を入力します。

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

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続フィルタの構成に関する項を参照してください。

- 接続フィルタのルールとカスタム接続フィルタの作成については、『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使い方に関する項およびカスタム接続フィルタの開発に関する項を参照してください。

- WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。

Java Authorization Contract for Containersの使用

Java Authorization Contract for Containers (JACC)標準は、WebLogic Serverが提供するEJBおよびサーブレット・コンテナのデプロイメントおよび認可に取ってかわることができます。WebLogicドメインでJACCを使用するように構成すると、EJBおよびサーブレット認可の決定は、JACCフレームワーク内のクラスによって行われます。WebLogic Server内における他の認可決定はすべて、引き続きWebLogicセキュリティ・フレームワークによって行われます。WebLogic JACCプロバイダについては、『Oracle WebLogic Serverセキュリティのプログラミング』のJava Authorization Contract for Containersの使用に関する項を参照してください。

WebLogic Serverを構成してJACCを使用するには、コマンドライン起動オプションを使用します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「weblogic.Serverコマンドライン・リファレンス」のDjava.security.managerオプションの説明を参照してください。

ドメインの管理サーバーと管理対象サーバーは、同じJACC構成を持つ必要があります。管理サーバーのJACC設定を変更した場合、セキュリティの低下を防ぐため、管理対象サーバーを再起動して管理サーバーと同じ設定を適用します。そうしないと、管理対象サーバーは実際にはJACCの下で動作しているのに、ドメイン内のEJBとサーブレットがWebLogicセキュリティ・フレームワークのロールとポリシーによって保護されているように見える場合があります。

MBean属性の表示

「匿名Adminのルックアップを有効化」オプションでは、MBean APIからのWebLogic Server MBeanに対する読取り専用の匿名アクセスを許可するかどうかを指定します。この匿名アクセスを使用すると、WebLogic Server MBean認可プロセスによる保護が明示的に示されていない任意のMBean属性の値を参照できます。このオプションは後方互換性を確実にするために、デフォルトで有効になっています。セキュリティを高めるには、この匿名アクセスを無効にします。

WebLogic Server管理コンソールで「匿名Adminのルックアップを有効化」オプションの設定を検証するには、「ドメイン」→「セキュリティ」→「全般」を選択するか、SecurityConfigurationMBean.AnonymousAdminLookupEnabled属性を表示します。

WebLogic Serverでのパスワードの保護の仕組み

WebLogicドメインのリソースにアクセスするためのパスワードを保護することは重要です。ユーザー名とパスワードは以前、WebLogicセキュリティ・レルムにクリア・テキストで保存されていました。現在ではWebLogicドメインのパスワードはすべてハッシュ化されています。パスワードのハッシュは、SerializedSystemIni.datファイルに格納されます。このファイルは特定のWebLogicドメインに関連付けられるため、ドメイン間で移動することはできません。

SerializedSystemIni.datファイルが破損した場合は、WebLogicドメインを再構成する必要があります。そのため、次の注意事項を考慮する必要があります。

- SerializedSystemIni.datファイルのバックアップを作成し、安全な場所に保管します。

- WebLogic Serverデプロイメントのシステム管理者が読み書き権限を持ち、その他のユーザーは何の権限も持たないように、SerializedSystemIni.datファイルに権限を設定します。

ユーザー・アカウントの保護

WebLogic Serverには、ユーザー・アカウントを侵入者から保護するための構成オプションが定義されています。デフォルト・セキュリティ構成では、これらのオプションは最高の保護レベルに設定されています。これらのオプションを変更するには、管理コンソールの「構成」→「ユーザーのロックアウト」ページを使用します。

システム管理者は、すべての構成オプションを無効にしたり、ユーザー・アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザー・アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザー・アカウントのロック時間を変更したりできます。これらの構成オプションを変更すると、セキュリティ・レベルが低下して攻撃を受けやすくなることに注意してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・ロックアウト属性の設定に関する項を参照してください。

注意:
「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルムとそのすべてのセキュリティ・プロバイダに適用されます。「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルム以外のセキュリティ・レルムにあるカスタム・セキュリティ・プロバイダでは機能しません。カスタム・セキュリティ・プロバイダで「ユーザーのロックアウト」オプションを使用するには、デフォルト・セキュリティ・レルムでカスタム・セキュリティ・プロバイダを構成します。デフォルト認証プロバイダやWebLogic IDアサーション・プロバイダの後の認証プロセスにカスタム・セキュリティ・プロバイダを含めます。この順序付けによって、パフォーマンスが若干低下することがあります。
ユーザー・アカウントを保護する独自のメカニズムを備えた認証プロバイダを使用する場合は、「ロック・アウトを有効化」オプションを無効化します。

ユーザー・アカウントがロックされたためそのユーザー・アカウントを削除して、同じ名前とパスワードを持つ別のユーザー・アカウントを追加しても、「ユーザーのロック・アウト」構成オプションはリセットされません。

ロックされたユーザー・アカウントの解除については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・アカウントのロック解除に関する項を参照してください。ロックされたユーザー・アカウントに対するロックの解除は、WebLogic管理コンソールや、UserLockoutManagerRuntimeMBeanのclearLockout属性を介して行うことができます。

JAAS認可を使用するドメインの構成

WebLogicドメインのセキュリティ構成は、JAAS認可を使用するように変更できます。JAAS認可は、WebLogicセキュリティ・サービスとは異なる方法でサブジェクトを解釈します。たとえば、OPSS (Oracle Platform Security Services)でJavaポリシー・プロバイダによって保護されるリソースへのアクセスをプリンシパルがリクエストする場合、プリンシパルは、ポリシー・ストアに含まれる名前で構築される別のプリンシパルと比較されます。(この比較は、Principal.equals()メソッドが呼び出されると行われます。)2つのプリンシパル・オブジェクトの適切な属性が一致する場合、アクセスは許可されます。

保護されたリソースへのアクセス決定を判断する場合、WebLogicセキュリティ・サービスでプリンシパルの比較は使用されません。ただし、デフォルトのWebLogicドメインでプリンシパルの比較が行われる場合、プリンシパル名の比較では大文字/小文字が区別され、プリンシパル名のみが比較されます。JAAS認可を使用するには、次のプリンシパル比較動作に適応するようにWebLogicドメインのセキュリティ構成を変更できます。

- プリンシパル名の比較では大文字/小文字は区別されません。

- WebLogicプリンシパル・オブジェクトのGUIDとDNのデータは比較に含まれます。

プリンシパル・オブジェクトをJAAS認可で使用するようにWebLogicドメインのセキュリティ構成を変更するには、次のMBean属性の設定を使用できます。

SecurityConfigurationMBean.PrincipalEqualsCaseInsensitive="true"
SecurityConfigurationMBean.PrincipalEqualsCompareDnAndGuid="true"

これらの属性を設定するには、WebLogic Server管理コンソールで次の操作を行います。

1. 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。

2. 「構成」→「セキュリティ」を選択して、「詳細」をクリックします。

3. 次の各エントリの横にあるチェック・ボックスを選択します。

- Principal Equalsの大文字/小文字を区別しない

- Principal EqualsでDNとGUIDを比較

注意:
プリンシパルでGUIDとDNのデータを使用するようにドメインが構成される場合、他のWebLogicドメイン(特に古いドメイン)との相互運用に影響があります。これは、IDエンティティを渡す方法が変更されることで生じます。

Oracle Platform Security Serviceでのプリンシパル比較については、『Oracle Fusion Middlewareセキュリティ・ガイド』のプリンシパル名の比較ロジックに関する項を参照してください。WebLogicドメインにIDを渡す場合の詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』を参照してください。

14 互換性セキュリティの使い方

この章では、WebLogic Server 10.3.6での互換性セキュリティについて説明します。互換性セキュリティとは、WebLogic Server 6.xで行ったセキュリティ構成をこのリリースのWebLogic Serverで実行するための機能です。互換性セキュリティでは、6.xのセキュリティ・レルム、ユーザー、グループ、およびACLの管理、ユーザー・アカウントの保護、レルム・アダプタ監査プロバイダの構成や、必要に応じてレルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成を行うことができます。

この章の内容は以下のとおりです。

- 互換性セキュリティの実行: 主な手順

- 互換性セキュリティMBeanの可視性制限

- CompatibilityRealmのデフォルト・セキュリティ構成

- レルム・アダプタ認証プロバイダの構成

- レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成

- レルム・アダプタ監査プロバイダの構成

- 互換性セキュリティでのユーザー・アカウントの保護

- 互換性セキュリティからの6.xセキュリティへのアクセス

注意:
互換性セキュリティはこのリリースのWebLogic Serverで非推奨になりました。今後のメジャー・リリースではサポートされなくなります。WebLogic ServerデプロイメントをこのリリースのWebLogic Serverのセキュリティ機能にアップグレードすることを強くお薦めします。互換性セキュリティは、このアップグレードの間だけ使用してください。

互換性セキュリティの実行: 主な手順

互換性セキュリティを設定するには:

1. 互換性セキュリティを使用する前に、バージョン6.xのWebLogicドメイン(config.xmlファイルを含む)のバックアップ・コピーを作成しておきます。

2. バージョン6.xのconfig.xmlファイル内に下記を追加して(存在しない場合)、ドメイン名、セキュリティ・レルム名、およびFileRealmを実際の名前に置き換えます。

<Security Name="mydomain" Realm="mysecurity"/>
<Realm Name="mysecurity" FileRealm="myrealm"/>
<FileRealm Name="myrealm"/>

3. WebLogic Serverの最新バージョンを新しいディレクトリにインストールします。既存の6.xインストール・ディレクトリには上書きしないようにします。詳細は、『Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

4. 新しいWebLogic Serverを指すように6.xサーバーの起動スクリプトを修正します。具体的には、次のとおり修正します。

- クラスパスが新しいWebLogic Serverのweblogic.jarファイルを指すようにします。

- JAVA_HOME変数が新しいWebLogic Serverを指すようにします。

5. 6.xサーバーの起動スクリプトを使用してWebLogic Serverの新しいバージョンを起動します。

互換性セキュリティを適切に実行しているかどうかを検証するには、新しいWebLogic Server管理コンソールを開きます。互換性セキュリティが実行されている場合、「ドメイン構造」ペインの左側に「互換性セキュリティ」ノードが表示されます。

互換性セキュリティMBeanの可視性制限

すべての互換性セキュリティMBeanは除外対象にされているので、WebLogic Scripting Toolでは一部しか表示されません。たとえば、次のコマンドにより、DomainMBeanの属性が示されます(FileRealmMBeanなどの互換性セキュリティ属性を除く)。

java weblogic.WLST
connect()
ls()

ただし、互換性MBeanに直接対応する場合、次のコマンドでアクセスできます。

java weblogic.WLST
connect()
cmo.getFileRealms()

CompatibilityRealmのデフォルト・セキュリティ構成

デフォルトでは、レルム・アダプタ裁決プロバイダ、レルム・アダプタ認証プロバイダ、WebLogic認可プロバイダ、レルム・アダプタ認可プロバイダ、WebLogic資格証明マッピング・プロバイダ、およびWebLogicロール・マッピング・プロバイダを備えたCompatibilityRealmが構成されています。

- CompatibilityRealmでは、レルム・アダプタ認証プロバイダに、config.xmlファイルで定義された6.xセキュリティ・レルムからのユーザーとグループが含まれます。

- 6.xセキュリティ構成でファイル・レルムを使用していた場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの互換性セキュリティに関する項にあるユーザーの定義およびグループの定義のトピックの手順に従って、レルム・アダプタ認証プロバイダにあるユーザーとグループを管理できます。

- 代替セキュリティ・レルム(LDAP、Windows NT、RDBMS、またはカスタム)を使用している場合は、そのレルムで用意されている管理ツールを使用してユーザーとグループを管理する必要があります。

レルム・アダプタ認証プロバイダの構成については、「レルム・アダプタ認証プロバイダの構成」を参照してください。

レルム・アダプタ認証プロバイダにIDアサーション・プロバイダを構成することで、互換性セキュリティでweblogic.security.acl.CertAuthenticatorクラスの実装を使用できます。詳細は、「レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成」を参照してください。

- 6.xセキュリティ・レルムのアクセス制御リスト(ACL)はレルム・アダプタ認可プロバイダに格納されるために使用されます。

- レルム・アダプタ裁決プロバイダを使用すると、互換性セキュリティでACL、およびセキュリティ・ロール/セキュリティ・ポリシーの両方を使用できます。レルム・アダプタ裁決プロバイダは、レルム・アダプタ認可プロバイダとWebLogic認可プロバイダでのみ使用できます。この裁決プロバイダは、ACLと、管理コンソールで設定された新しいセキュリティ・ポリシーの間で発生するアクセス決定の競合を解決します。一方の認可プロバイダがPERMITを支持し、もう一方の認可プロバイダがDENYを支持した場合、レルム・アダプタ裁決プロバイダはアクセスを許可します。

- WebLogic資格証明マッピング・プロバイダを使用すると、互換性セキュリティで資格証明マップを使用できます。詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』を参照してください。

- レルム・アダプタ監査プロバイダを追加することで、CompatibilityRealmからweblogic.security.audit.AuditProviderクラスの実装にアクセスできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのレルム・アダプタ監査プロバイダの構成に関する項を参照してください。

レルム・アダプタ認証プロバイダの構成

互換性セキュリティを使用する場合、レルム・アダプタ認証プロバイダはデフォルトでCompatibilityRealmに構成されます。CompatibilityRealmでレルム・アダプタ認証プロバイダを使用する方法については、「CompatibilityRealmのデフォルト・セキュリティ構成」を参照してください。

またレルム・アダプタ認証プロバイダでは、このリリースのWebLogic Serverでweblogic.security.acl.CertAuthenticatorクラスの実装を使用できます。レルム・アダプタ認証プロバイダには、X.509トークンに基づくIDアサーションを提供するIDアサーション・プロバイダが含まれています。WebLogic ServerでCertAuthenticatorを使用する方法は、「レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成」を参照してください。

認証プロバイダがすでに構成されているセキュリティ・レルムにレルム・アダプタ認証プロバイダを追加する場合、WebLogic Serverは、レルム・アダプタ認証プロバイダのJAAS 「制御フラグ」を「OPTIONAL」に設定して、ドメイン・ディレクトリにfileRealm.propertiesファイルがあるかどうかをチェックします。fileRealm.propertiesファイルが存在しない場合、WebLogic Serverはセキュリティ・レルムにレルム・アダプタ認証プロバイダを追加しません。

注意:
レルム・アダプタ認証プロバイダによって生成されるサブジェクトには、ユーザーが所属するグループのプリンシパルは含まれません。ユーザーがグループに所属しているかどうかを調べるには、weblogic.security.SubjectUtils.isUserInGroup()メソッドを使用します。レルム・アダプタ認証プロバイダによって生成されるサブジェクトを使用する場合、ユーザーが所属するグループの完全なセットを繰返し処理することはできません。

レルム・アダプタ認証プロバイダ内のIDアサーション・プロバイダの構成

レルム・アダプタ認証プロバイダには、IDアサーション・プロバイダが含まれています。IDアサーション・プロバイダは、非推奨となったweblogic.security.acl.CertAuthenticatorクラスの実装の後方互換性を提供します。IDアサーションはX.509トークンに基づいて実行されます。デフォルトでは、IDアサーション・プロバイダはレルム・アダプタ認証プロバイダで有効になっていません。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのIDアサーション・プロバイダの有効化に関する項を参照してください。

レルム・アダプタ監査プロバイダの構成

互換性セキュリティを使用する状況でレルム・アダプタ監査プロバイダを使用すると、weblogic.security.audit.AuditProviderインタフェースの実装を使用できます。レルム・アダプタ監査プロバイダが正常に動作するには、AuditProviderインタフェースの実装を定義しておく必要があります。AuditProviderクラスを定義するには、管理コンソールの「ドメイン: 互換性セキュリティ」>「全般」ページの「監査プロバイダ・クラス」フィールドを使用します。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのレルム・アダプタ監査プロバイダの構成に関する項を参照してください。

互換性セキュリティでのユーザー・アカウントの保護

パスワード推定は、セキュリティ攻撃の一般的なタイプです。このタイプの攻撃では、ハッカーは様々なユーザー名とパスワードの組合せを使用してコンピュータにログインしようとします。WebLogic Serverには、このタイプの攻撃からユーザー・アカウントを保護するためのロックアウト構成オプションが定義されています。デフォルトでは、これらのオプションは最高の保護レベルに設定されています。システム管理者は、すべてのオプションを無効にしたり、ユーザー・アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザー・アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザー・アカウントのロック時間を変更したりできます。これらの構成オプションを変更すると、セキュリティ・レベルが低下して攻撃を受けやすくなることに注意してください。

ユーザー・アカウントを保護するための構成オプション・セットは2種類あります。一方はドメインで設定し、もう一方はセキュリティ・レルムで設定します。一方の構成オプション・セット(たとえばセキュリティ・レルムのオプション)を設定している場合に、そのいずれかの値が超過しても、ユーザー・アカウントがロックされないことがあります。これは、ドメインのユーザー・アカウント・ロックアウト・オプションがセキュリティ・レルムのユーザー・アカウント・オプションをオーバーライドすることが原因です。この状況を回避するには、セキュリティ・レルムのユーザー・アカウント・ロックアウト・オプションを無効にします。

警告:
セキュリティ・レルムのユーザーのロック・アウト構成オプションを無効にした場合は、ドメインでユーザーのロック・アウト構成オプションを設定する必要があります。このようにしないと、ユーザー・アカウントが保護されません。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・アカウントの保護に関する項およびユーザー・アカウントのロック解除に関する項を参照してください。

互換性セキュリティからの6.xセキュリティへのアクセス

互換性セキュリティを使用する場合は、ユーザーおよびグループを定義するセキュリティ・レルムとWebLogicドメインのリソースを保護するACLのあるconfig.xmlファイルがすでに存在するものと想定されます。セキュリティ・レルムを構成したり、ACLを定義したりといったWebLogic Server 6.xのセキュリティ管理タスクは必須ではないので、そうした管理タスクについてこの項では説明しません。ただし、既存の6.xセキュリティ・レルムが壊れて、それを復元するしか選択肢がない場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの互換性セキュリティのトピックで次の6.xセキュリティ管理タスクの説明を参照してください。

- LDAP V1セキュリティ・レルムの構成

- LDAP V2セキュリティ・レルムの構成

- RDBMSセキュリティ・レルムの構成

- Windows NTセキュリティ・レルムの構成

- UNIXセキュリティ・レルム用のwlauthの構成

- UNIXセキュリティ・レルムの構成

- カスタム・セキュリティ・レルムの構成

- キャッシング・レルムの構成

- ファイル・レルムの構成

- ACLの定義

- グループの定義

- グループの削除

- ユーザーの定義

- ユーザーの削除

- ユーザー・パスワードの変更

- システム・パスワードの変更

- ゲスト・ユーザーの無効化

警告:
互換性セキュリティは後方互換性のみを提供するものです。長期的なセキュリティ・ソリューションとは考えないでください。

15 セキュリティ構成MBean

この章では、WebLogic Server 10.3.6でセキュリティ・フレームワークの構成に使用するMBeanについて説明します。各MBean属性は、動的である(サーバーを再起動せずに属性値を変更できる)、または動的でない(属性値を変更した場合、サーバーを再起動しなければ変更が有効にならない)のいずれかとして指定されています。また、動的でない属性を編集した場合、動的な属性に対する編集は再起動しなければ有効になりません。つまり、動的な属性と動的でない属性の編集を一度に行った場合、編集内容の一部分だけがアクティブ化されることはありません。

ここに掲載されていないセキュリティMBeanは動的ではありません(MBeanの作成または破棄、属性の変更)。

WebLogicセキュリティMBeanの詳細は、以下を参照してください。

- 『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したセキュリティ・レルムの管理に関する項

- Oracle WebLogic Server MBeanリファレンスのMBeanのセキュリティに関する項

SSLMBean

このBeanの作成または破棄は動的です。

動的な属性は以下のとおりです。

Enabled、TwoWaySSLEnabled、ClientCertificateEnforced、ListenPort

Ciphersuites、ExportKeyLifespan、SSLRejectionLoggingEnabled、LoginTimeoutMillis

ServerCertificateChainFileName、ServerKeyFileName、ServerCertificateFileName、TrustedCAFileName

ServerPrivateKeyAlias、ServerPrivateKeyPassPhrase

IdentityAndTrustLocations

InboundCertificateValidation、OutboundCertificateValidation

その他の属性は動的ではありません。

ServerMBean

このBeanの作成または破棄は動的です。

動的な属性は以下のとおりです。

KeyStores

CustomIdentityKeyStoreFileName、CustomIdentityKeyStoreType、CustomIdentityKeyStorePassPhrase

CustomTrustKeyStoreFileName、CustomTrustKeyStoreType、CustomTrustKeyStorePassPhrase

JavaStandardTrustKeyStorePassPhrase

その他の属性は動的ではありません。

EmbeddedLDAPMBean

動的な属性は以下のとおりです。

Credential

その他の属性は動的ではありません。

RDBMSSecurityStoreMBean

このMBeanの作成または破棄は動的でありません。

すべての属性は動的ではありません。

SecurityMBean

動的な属性は以下のとおりです。

ConnectionFilterRules

ConnectionLoggerEnabled

その他の属性は動的ではありません。

SecurityConfigurationMBean

動的な属性は以下のとおりです。

Credential

ConnectionFilterRules、ConnectionLoggerEnabled、CompatibilityConnectionFiltersEnabled

NodeManagerUsername、NodeManagerPassword

その他の属性は動的ではありません。

RealmMBean

このMBeanの作成または破棄は動的でありません。

動的な属性は以下のとおりです。

DeployRoleIgnored、DeployPolicyIgnored、DeployCredentialMappingIgnored

FullyDelegateAuthorization

ValidateDDSecurityData、SecurityDDModel

CombinedRoleMappingEnabled

その他の属性は動的ではありません。

WindowsNTAuthenticatorMBean

このMBeanの作成または破棄は動的でありません。

動的な属性は以下のとおりです。

BadDomainControllerRetryInterval

MapUPNNames、LogonType

MapNTDomainName

その他の属性は動的ではありません。

CustomDBMSAuthenticatorMBean

このMBeanの作成または破棄は動的でありません。ControlFlagおよび読取り専用プロバイダ属性(ProviderClassNameやDescriptionなど)は動的ではありません。その他の属性は動的です。

ReadonlySQLAuthenticatorMBean

このMBeanの作成または破棄は動的でありません。

ControlFlagおよび読取り専用プロバイダ属性(ProviderClassNameやDescriptionなど)は動的ではありません。その他の属性は動的です。

SQLAuthenticatorMBean

このMBeanの作成または破棄は動的でありません。

ControlFlagおよび読取り専用プロバイダ属性(ProviderClassNameやDescriptionなど)は動的ではありません。その他の属性は動的です。

DefaultAuditorMBean

このMBeanの作成または破棄は動的でありません。

動的な属性は以下のとおりです。

Severity

その他の属性は動的ではありません。

互換性セキュリティMBean

互換性セキュリティに使用されるすべてのMBeanはまったく動的ではありません(MBeanの作成または破棄、属性の変更)。これらのMBeanには以下のものがあります。

- RealmMBean

- FileRealmMBean

- BasicRealmMBean

- CachingRealmMBean

- PasswordPolicyMBean

- CustomRealmMBean

- LDAPRealmMBean

- NTRealmMBean

- RDBMSRealmMBean

- UnixRealmMBean

UserLockoutManagerMBean

このMBeanはまったく動的ではありません(MBeanの作成または破棄、属性の変更)。

その他のセキュリティ・プロバイダMBean

その他のセキュリティMBeanはまったく動的ではありません(MBeanの作成または破棄、属性の変更)。

A FIPSモードの有効化

この付録では、WebLogic ServerのJSSEおよびJDK 7.0に対してFIPS 140-2モードを有効化する方法について説明します。

内容は次のとおりです。

- FIPSの概要

- サポートされるFIPS標準と暗号スイート

- JavaオプションでのFIPS 140-2モードの有効化

- java.securityでのFIPS 140-2モードの有効化

- FIPS 140-2モード有効時のJCEの検証

- Webサービスを使用する際の重要な考慮事項

FIPSの概要

Federal Information Processing Standards (FIPS) 140-2は、アメリカ合衆国政府の機密でも未分類の使用に関する要件を記載した規格です。

注意:

このリリースでは、WebLogic ServerのJSSEおよびJDK 7に対してFIPS 140-2をサポートするために、バンドルされているパッチをインストールする必要があります。これはデフォルトでは使用できません。WebLogic Serverおよび他のFusion Middlewareコンポーネント用のこのパッチの詳細は、My Oracle Supportのサポート・ドキュメント2115681.1を参照してください。My Oracle Supportにはhttps://support.oracle.com/からアクセスできます。

JSSEに対するFIPS 140-2のサポートには、JDK 1.7.0_80以降が必要です。

WebLogic ServerでJSSEサポートを有効化する方法は、JSSEベースSSL実装の使用を参照してください。

WebLogic Serverでは、RSA FIPS互換(FIPS 140-2)機密モジュールを使用できます。(サポートされるバージョンは、「サポートされるFIPS標準と暗号スイート」を参照してください。)

この機密モジュールをRSA JSSEプロバイダおよびRSA JCEプロバイダと組み合せて使用すると、FIPS準拠(FIPS 140-2)実装が提供されます。

FIPSに対するOracle Fusion Middlewareのサポートの詳細は、Oracle Fusion Middlewareの管理のOracle Fusion MiddlewareでのFIPS-140サポートを参照してください。

サポートされるFIPS標準と暗号スイート

表A-1は、サポートされるFIPSバージョンと暗号スイートを示します。

表A-1 暗号スイートとサポートされるFIPS 140-2バージョン

標準

バージョン

その他の検討事項

FIPS 140-2

RSA Crypto-J V6.2.0.1

RSA SSL-J V6.2

RSA Cert-J V6.2

JSSE JDK 7用暗号スイート

優先されるネゴシエーション済の暗号の組合せは、AES + SHA2です。

JDK 7 SunJSSEによってサポートされる暗号スイートのセットは、http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProviderを参照してください。

RSA JSSE用暗号スイート

製品に依存

http://www.emc.com/security/rsa-bsafe.htmを参照してください。

(非推奨の) WebLogic Server Certicom SSL実装およびSunJSSE同等製品でサポートされる暗号スイート

製品に依存

暗号スイート名の等価物を参照してください。

Certicomを使用するとき、WebLogic ServerはSHA256ハッシング、またはSHA256を含む署名アルゴリズムをサポートしません。

JavaオプションでのFIPS 140-2モードの有効化

JavaオプションでFIPS 140-2を有効にするには、次の手順に従います。

1. 次のURLより、使用しているJDKのバージョンに対応するJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policyファイルをダウンロードおよびインストールします。これらのJavaポリシーJARファイルは、サイズが128ビットを超える暗号鍵に影響します。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

.ZIPディストリビューションを開き、JAVA_HOME/jre/lib/securityのlocal_policy.jarとUS_export_policy.jarを更新します。詳細およびインストール方法は、.ZIPディストリビューション内のREADME.txtファイルを参照してください。

2. 自らのjava.securityファイルを作成します。インストールしたJDKに含まれるファイルを見本として使用できます。
RSA JCEプロバイダとRSA JSSEプロバイダの両方を、java.securityプロパティ・ファイルに最初の2つのJavaセキュリティ・プロバイダとして追加します。

#
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider

security.provider.3=sun.security.provider.Sun
:

3. WebLogic Serverの起動コマンドラインに-Djava.security.propertiesを設定して、java.securityファイルのデフォルト構成をオーバーライドします。カスタムjava.securityファイルのフルパスを指定します。

set JAVA_OPTIONS=-Djava.security.properties=C:\Users\user\java.security

注意:
インストールされているJREセキュリティ・プロパティにjava.securityプロパティを追加する場合は、1つの等号(=)を使用してファイル名を指定します。すべてのJavaセキュリティ・プロパティをオーバーライドする場合は、2つの等号(==)を使用します(例: -Djava.security.properties==C:\Users\user\java.security)。

4. jcmFIPS.jar jarファイルおよびsslj.jar JARファイル(どちらもWL_HOME/server/lib/にある)をクラスパスの先頭に指定します。これには、PRE_CLASSPATH環境変数を使用します。
(RSA JCEプロバイダCrypto-Jはデフォルトでcryptoj.jarとクラスパスにあります。)

たとえば、jcmFIPS.jarとsslj.jarをPRE_CLASSPATH変数に設定してから、サーバー起動スクリプト(通常はstartWebLogic.cmd/sh)を呼び出すことができます。

set PRE_CLASSPATH=%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar
cd %MW_HOME%\user_projects\domains\base_domain
startWebLogic.cmd

5. WebLogic Serverを起動します。

java.securityでのFIPS 140-2モードの有効化

インストールされているJDKのjava.securityファイルを使用してFIPS 140-2モードを有効化するには、次の手順を実行します。

1. 次のURLより、使用しているJDKのバージョンに対応するJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policyファイルをダウンロードおよびインストールします。これらのJavaポリシーJARファイルは、サイズが128ビットを超える暗号鍵に影響します。
インストール方法は、.ZIPディストリビューション内のREADME.txtファイルを参照してください。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

.ZIPディストリビューションを開き、JAVA_HOME/jre/lib/securityのlocal_policy.jarとUS_export_policy.jarを更新します。詳細およびインストール方法は、.ZIPディストリビューション内のREADME.txtファイルを参照してください。

2. java.securityファイルを編集します。RSA JCEプロバイダとRSA JSSEプロバイダの両方を、java.securityプロパティ・ファイルに最初の2つのJavaセキュリティ・プロバイダとして追加します。

#
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider

security.provider.3=sun.security.provider.Sun
:

3. jcmFIPS.jar jarファイルおよびsslj.jar JARファイル(どちらもWL_HOME/server/lib/にある)をクラスパスの先頭に指定します。これには、PRE_CLASSPATH環境変数を使用します。
(RSA JCEプロバイダCrypto-Jはデフォルトでcryptoj.jarとクラスパスにあります。)

たとえば、jcmFIPS.jarとsslj.jarをPRE_CLASSPATH変数に設定してから、サーバー起動スクリプト(通常はstartWebLogic.cmd/sh)を呼び出すことができます。

set PRE_CLASSPATH=%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar
cd %MW_HOME%\user_projects\domains\base_domain
startWebLogic.cmd

または、jcmFIPS.jarとsslj.jarをサーバー起動スクリプトそのもののPRE_CLASSPATH変数に追加します。

4. WebLogic Serverを起動します。

FIPS 140-2モード有効時のJCEの検証

通常のWebLogic起動時には、パフォーマンスの理由からRSA Crypto-J JCE自己整合性テストは無効になっています。

FIPS 140-2モードのWLSを構成するときにJCE検証を有効にするには、WebLogic Serverを起動するときに-Dweblogic.security.allowCryptoJDefaultJCEVerification=true JAVA_OPTIONS環境変数を設定します。

この環境変数を設定すると、処理が追加されて、起動に時間がかかるようになることに注意してください。

Webサービスを使用する際の重要な考慮事項

FIPS 140-2モードの場合、すべての証明書の鍵サイズは2048ビットでなければなりません。

注意:
FIPSモードのインストールに含まれているデモ用証明書は、安全でないため使用しないでください。これらは開発用にのみ提供されています。

FIPS 140-2モードでWebサービスを使用するときは、次の注意事項を念頭に置いてください。

- SHA-1セキュア・ハッシュ・アルゴリズムのサポートなし

- X509PKIPathv1トークンのサポートなし

SHA-1セキュア・ハッシュ・アルゴリズムのサポートなし

SHA-1セキュア・ハッシュ・アルゴリズムはFIPS 140-2モードではサポートされません。したがって、次のWS-SP <sp:AlgorithmSuite>値はFIPS 140-2モードではサポートされません。

- Basic256

- Basic192

- Basic128

- TripleDes

- Basic256Rsa15

- Basic192Rsa15

- Basic128Rsa15

- TripleDesRsa15

Oracle WebLogic Server WebLogic Webサービスの保護のSHA-256セキュア・ハッシュ・アルゴリズムの使用で説明しているように、WebLogic Server Webサービス・セキュリティ・ポリシーでは、デジタル署名のハッシュのためにSHA-1およびより強固なSHA-2 (SHA-256)セキュア・ハッシュ・アルゴリズムの両方がサポートされています。特にSHA-256ポリシーの使用では、SHA-1セキュア・ハッシュ・アルゴリズムとSHA-2セキュア・ハッシュ・アルゴリズムを使用するポリシーを説明しています。

FIPS 140-2モードには、SHA-2セキュア・ハッシュ・アルゴリズムに加えて、拡張アルゴリズム・スイート・ポリシーでサポートされている、より強力なデジタル署名メソッドが必要です。詳細は、Oracle WebLogic Server WebLogic Webサービスの保護の拡張アルゴリズム・スイートの使用を参照してください。

FIPS 140-2モードを有効化する場合、セキュリティ・ポリシーの<sp:AlgorithmSuite要素を、次に示すサポートされている<sp:AlgorithmSuite値のいずれかに変更します。これらの値の詳細は、SHA-256セキュア・ハッシュ・アルゴリズムの使用を参照してください。

- Basic256Sha256

- Basic192Sha256

- Basic128Sha256

- Basic256Exn256

- Basic192Exn256

- Basic128Exn256

- TripleDesSha256

- TripleDesExn256

- Basic256Sha256Rsa15

- Basic192Sha256Rsa15

- Basic128Sha256Rsa15

- Basic256Exn256Rsa15

- Basic192Exn256Rsa15

- Basic128Exn256Rsa15

- TripleDesSha256Rsa15

- TripleDesExn256Rsa15

たとえば、Basic256アルゴリズム・スイートがポリシーで使用されている場合に、拡張アルゴリズム・スイートが必要な場合は、既存のポリシーを編集して、次のアルゴリズム・スイートを変更します。

<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>

これを次のように変更します。

<sp:AlgorithmSuite>
<wsp:Policy>
<orasp:Basic256Exn256xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy"/>
</wsp:Policy>
</sp:AlgorithmSuite>

X509PKIPathv1トークンのサポートなし

このリリースのWebLogic Serverでは、X509PKIPathv1トークンはFIPS 140-2モードでサポートされません。カスタム・ポリシーでX509PKIPathv1トークンを使用する場合、かわりにPKCS7トークンを使用するようにポリシーを変更します。

特に、次の2つのポリシー・アサーションは、このリリースのWebLogic ServerのFIPS 140-2モードでサポートされていません。

- <sp:WssX509PkiPathV1Token10/>

- <sp:WssX509PkiPathV1Token11/>

これら2つのポリシー・アサーションを使用する場合、かわりに次の2つのアサーションに変更してください。

- <sp:WssX509Pkcs7Token10/>

- <sp:WssX509Pkcs7Token11/>

たとえば、カスタム・ポリシーのポリシーに次のアサーションがあるとします。

<wsp:Policy>
<sp:X509Token sp:IncludeToken=". . .">
<wsp:Policy>
<sp:WssX509PkiPathV1Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>

これは次のポリシー・アサーションで置き換えてください。

<wsp:Policy>
<sp:X509Token sp:IncludeToken=". . .">
<wsp:Policy>
<sp:WssX509Pkcs7Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>

または、カスタム・ポリシーのポリシーに次のアサーションがあるとします。

<wsp:Policy>
<sp:X509Token sp:IncludeToken=". . .">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509PkiPathV1Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>

これは次のアサーションで置き換えてください。

<wsp:Policy>
<sp:X509Token sp:IncludeToken=". . .">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509Pkcs7Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。