5 認証プロバイダの構成

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

以下の節では、WebLogic Serverで提供されている認証セキュリティ・プロバイダを構成する方法について説明します。

• 認証プロバイダの選択

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

• 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 Securityフレームワークは、さまざまな要素からなる認証向けに、複数の認証プロバイダ(したがって、複数の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認証プロバイダのフェイルオーバーの構成

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

• WebLogic認証プロバイダと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

• 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認証プロバイダのフェイルオーバーの構成

• 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サーバーのディレクトリ・スキーマと他の属性に合わせて既存の構成をカスタマイズします。

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認証プロバイダに、構成可能な対応属性はありません。

^脚注2Oracle 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のマッピングについて」を参照してください。

^脚注3Active 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))

^脚注1LDAP検索フィルタをユーザーやグループで指定する際、ワイルドカードが指定可能です。ただし、ワイルドカードで複数のアスタリスクを使用すると(特にユーザー名やグループ名の属性)、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

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によるグループ・ルックアップのキャッシングの有効化」属性の両方が有効になっている場合にのみ適用されます。

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社製のクライアントでシングル・サインオン(single sign-on : SSO)を利用できます。このIDアサーション・プロバイダでは、SPNEGO (Simple and Protected Negotiate)のトークンをデコードしてKerberosのトークンを取得し、そのKerberosトークンを検証した後でWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。

ネゴシエーションIDアサーション・プロバイダは、WebLogic Securityフレームワークに定義されているようにセキュリティ・サービス・プロバイダ・インタフェース(Security Service Provider Interface : 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の電子メール属性([e-mail])にあるユーザーを、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管理コンソール・オンライン・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。