| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
以下の節では、Oracle WebLogic Communication Services のセキュリティの概要を説明します。
Oracle WebLogic Communication Services のユーザは、デプロイされた SIP サーブレット内の保護されたメソッドなど、保護されたリソースへのアクセスを要求するときは常に認証を受ける必要があります。Oracle WebLogic Communication Services では、以下のような手法を使って SIP サーブレットのユーザ認証を実装できます。
ダイジェスト認証では、単純なチャレンジ/応答メカニズムを使用して、SIP を介してユーザの身元を確認します。この手法の詳細については、節 5.7「ダイジェスト認証のコンフィグレーション」を参照してください。HTTP 経由で認証するには、アプリケーション開発者が独自の実装を提供する必要があります。
CLIENT-CERT 認証では、SIP アプリケーションに渡される X509 証明書チェーンを使用してユーザを認証します。X509 証明書チェーンは、さまざまな方法で提供することができます。最も一般的なケースでは、チェーンを送信する前に双方向 SSL ハンドシェイクを実行し、クライアントとサーバ間のセキュアな通信を確保します。CLIENT-CERT 認証の詳細については、節 5.8「Client-Cert 認証のコンフィグレーション」を参照してください。
Oracle WebLogic Communication Services 上にデプロイされる SIP サーブレットごとに、必要に応じて別々の認証メカニズムを使うことができます。必要な認証メカニズムは、SIP サーブレットの sip.xml デプロイメント記述子の auth-method 要素で指定します。デプロイメント記述子では、どのリソースを保護するかを定義し、アクセスに必要な特定のロール名を列挙することもできます。SIP サーブレット v1.1 仕様では、アプリケーションで必要なまたはサポート対象のレルム名と ID アサーション メカニズムを指定する能力を紹介します。Servlet 認証および ID アサーション メカニズムの定義については、SIP サーブレット v1.1 仕様を参照してください。
Oracle WebLogic Communication Services の認証サービスは、1 つまたは複数の認証プロバイダを使って実装されます。認証プロバイダは、ユーザやシステム プロセスの ID を証明した後、ID 情報をシステムの他のコンポーネントに送信する働きをします。
複数の認証プロバイダを使用して、別々の認証方式を使うようにコンフィグレーションすることも、連携して認証を行うようにコンフィグレーションすることもできます。たとえばダイジェスト認証を使用する場合、通常はダイジェストの有効性をアサートするダイジェスト ID アサーション プロバイダと、検証済みのユーザのグループ メンバシップを判断する LDAP または RDBMS 認証プロバイダの両方をコンフィグレーションします。
複数の認証プロバイダを連携させる場合は、プロバイダがユーザを評価する順序を指定し、さらに各プロバイダが認証プロセスをどの程度制御するかを指定する必要があります。各プロバイダは、そのユーザを有効と判断するかどうかを表明する「投票」を行うことができます。プロバイダの制御フラグは、プロバイダの投票が認証プロセスでどのように使われるかを示します。
プロバイダのコンフィグレーションの詳細については、節 5.7「ダイジェスト認証のコンフィグレーション」または節 5.8「Client-Cert 認証のコンフィグレーション」を参照してください。
Oracle WebLogic Communication Services では、システムにとって信頼できるホストを指定することもできます。信頼できるホストとは、Oracle WebLogic Communication Services が何も認証を行わないホストのことです。コンフィグレーションされている信頼できるホスト名と一致する宛先アドレスを含む SIP メッセージを受け取った場合、サーバは認証なしでメッセージを配信します。詳細については、『Oracle Fusion Middleware Security Guide』を参照してください。
Oracle WebLogic Communication Services では、RFC 3325 で規定されている P-Asserted-Identity SIP ヘッダがサポートされています。この機能では、信頼できるホストから送られてきた場合に、P-Asserted-Identity ヘッダで指定された資格を使って自動的にログインを行います。privacy ヘッダと P-Asserted-Identity の組み合わせにより、メッセージを信頼できるホストや信頼できないホストに転送できるかどうかも決まります。
Oracle WebLogic Communication Services では、RFC 4474 で規定されている Identity および Identity-Info ヘッダを使用して、ID アサーションがサポートされています。
両方の ID アサーション メカニズムでは、Oracle WebLogic Communication Services との適当なセキュリティ プロバイダをコンフィグレーションする必要があります。詳細については、節 5.9「SIP サーブレット ID アサーション メカニズムのコンフィグレーション」を参照してください。
SIP サーブレット API 仕様では、SIP サーブレットの宣言型セキュリティおよびプログラムに基づくセキュリティの提供に使用できるデプロイメント記述子要素のセットを定義します。セキュリティ制約を宣言する主な方法は、sip.xml デプロイメント記述子で 1 つまたは複数の security-constraint 要素とロール定義を指定することです。Oracle WebLogic Communication Services では、開発者が SIP サーブレットのロールを、SIP サーブレット コンテナでコンフィグレーションされた実際のプリンシパルやロールに容易にマップできるように、デプロイメント記述子の要素が追加されています。
Oracle WebLogic Communication Services に用意されている監査プロバイダをコンフィグレーションすると、セキュリティ レルム内の認証イベントをモニタすることができます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
表 5-1 は、Oracle WebLogic Communication Services のコンフィグレーション タスクと、追加情報へのリンクを示しています。
表 5-1 セキュリティ コンフィグレーション タスク
| タスク | 説明 |
|---|---|
|
|
|
|
節 5.8「Client-Cert 認証のコンフィグレーション」 |
|
|
節 5.9「SIP サーブレット ID アサーション メカニズムのコンフィグレーション」 |
|
以下の節では、ダイジェスト認証についての概要と、Oracle WebLogic Communication Services でのダイジェスト認証のサポートとコンフィグレーションについて説明します。
ダイジェスト認証とは、SIP または HTTP でユーザ認証に使用するシンプルなチャレンジ/応答メカニズムです。ダイジェスト認証の詳細は RFC 2617 で規定されています。
ダイジェスト認証を使用しているときに、保護されているサーバ リソースに対してクライアントが未認証のリクエストを行うと、サーバからクライアントに対して、nonce 値を使用してチャレンジが送信されます。クライアントは、要求されたアルゴリズム (デフォルトでは MD5) を使用して、暗号化された応答 (ダイジェスト) を生成します。その中には、ユーザ名、パスワード、およびレルムが含まれます。
サーバは、自らダイジェスト値を再作成し、クライアントから受け取ったダイジェストと比較することで、クライアントのダイジェストを検証します。サーバは、ダイジェスト値を再作成するために、A1 値 (RFC 2617 を参照) のハッシュを必要とします。この中には、nonce、ユーザ名、パスワード、およびレルム名が少なくとも必要です。サーバが A1 値のハッシュを再作成するときには、格納してある当該ユーザのクリアテキストのパスワードを取得して求めるか、または計算済みのハッシュ値を取得します。クリアテキストのパスワードまたは計算済みのハッシュ値は、LDAP ディレクトリに格納してあるか、JDBC を使用して RDBMS から利用するかのいずれかです。そしてサーバは、A1 値のハッシュを使用してダイジェストを再作成し、クライアントのダイジェストと比較して、ユーザの ID を検証します。
ダイジェスト認証では、クライアントとサーバの間でクリアテキスト パスワードが送信されないため、HTTP 上で安全な認証を実現できます。また、クライアントのチャレンジで nonce 値を使用するため、ダイジェスト認証はリプレイ攻撃への耐性があります。一般的なリクエストでのチャレンジ/応答のメカニズムの詳細については、図 5-1 を参照してください。
Oracle WebLogic Communication Services には、LDAP または RDBMS を使用してクライアントのダイジェストの有効性を確認するための LDAP ダイジェスト ID アサーション セキュリティ プロバイダが含まれています。認証プロセスを完了するためには、認可プロバイダが別途必要です (節 5.7.4.3「認証プロバイダのコンフィグレーション」を参照)。
ダイジェスト ID アサーション プロバイダが行うのは、クライアントのダイジェストを使用したユーザの資格を検証することだけです。ダイジェストを検証した後は、コンフィグレーション済みの認可プロバイダが、ユーザ名に基づいてそのユーザの存在をチェックし、結果の javax.security.auth.Subject のグループ メンバシップを設定して、認証プロセスを完了します。
ダイジェスト ID アサーション プロバイダでは、次のいずれかの形で、LDAP サーバまたは RDBMS にユーザ資格が格納されている必要があります。
暗号化されていない (クリア テキスト) パスワード。最も単純なコンフィグレーションで、ユーザの暗号化されていないパスワードをストアに格納します。この方法を使用する場合は、サーバ側のネットワーク トラフィックでクリアテキストのパスワードがそのまま流用されることのリスクを軽減するために、LDAP ストアまたはデータベースへの接続に SSL 接続を使用することをお勧めします。LDAP ストアによっては、暗号化されていないパスワードをデフォルトでサポートしていないものもあります。その場合は、パスワードを格納するための LDAP サーバで専用の資格属性を作成したり使用したりする必要があります。節 5.7.4.1「LDAP サーバまたは RDBMS のコンフィグレーション」を参照してください。
逆暗号化パスワード。Oracle WebLogic Communication Services に用意されているユーティリティを使用すると、ダイジェスト認可 ID アサーション プロバイダをコンフィグレーションするときに使用する、暗号化キー、暗号化の初期ベクタ、および暗号化パスワードの各値を計算できます。
各パスワード、ユーザ名およびレルムのあらかじめ計算したハッシュ。暗号化されていないパスワードまたは逆暗号化パスワードの格納ができない場合、その代わりに、LDAP または RDBMS の新規または既存の属性内のユーザ名、セキュリティ レルムおよびパスワードのあらかじめ計算したハッシュ値を格納できます。そして、ダイジェスト ID アサーション プロバイダは、ハッシュ値のみを取得し、クライアントが生成したダイジェストのハッシュと比較します。計算済みのハッシュ値を格納する方がセキュリティは高まります。
LDAP ダイジェスト ID アサーション プロバイダは、クリアテキストのパスワードや計算済みのハッシュ値を格納できるすべての LDAP プロバイダと互換性があります。
|
注意 : 組み込み LDAP ストアのスキーマを変更して、クリアテキストのパスワードや計算済みのハッシュ値を格納するための専用のフィールドを追加することはできません。ただし、テストやデモンストレーションの目的では、定義済みの「記述」フィールドにパスワード情報を格納できます。認証の判断に DefaultAuthenticator プロバイダを使用しない場合は、ダイジェスト認証を使用する前に、DefaultAuthenticator をオプションのプロバイダにする (制御フラグを SUFFICIENT 以下にする) 必要があります。通常、クリアテキストまたはハッシュのパスワード情報の保持に別個の LDAP ストアを使用するプロダクション インストールでは、これは必須のコンフィグレーションです。 |
図 5-1 Oracle WebLogic Communication Services でのダイジェスト認証
図 5-1 は、一般的なクライアント リクエストにおける ID アサーション プロバイダの基本的なアーキテクチャと使用法を示します。
クライアントが、保護されたアプリケーション リソースに対して、未認証のリクエストを行います (sip-xml デプロイメント記述子でセキュリティ制約を指定すると、SIP サーブレット リソースが保護されます)。
ダイジェスト ID アサーション プロバイダは、nonce 値、レルム名、および暗号アルゴリズム (MD5 または MD5-sess) で構成されるチャレンジ文字列を生成します。SIP コンテナがチャレンジ文字列をクライアントに送信します。
|
注意 : ダイジェスト ID アサーション プロバイダは、使用された nonce とタイムスタンプのキャッシュを指定の期間保持します。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonce ペアと同じタイムスタンプ/nonce ペアを使用するリクエストもすべて拒否されます。 |
クライアントは、暗号化アルゴリズムを使用したダイジェストを作成します。このダイジェストは、ユーザ名、パスワード、実際の名前、nonce、SIP メソッド、リクエストされた URI、および RFC 2617 で定められたその他の情報で構成されます。
ダイジェスト ID アサーション プロバイダは、A1 値、nonce、SIP メソッドなどの情報のハッシュを使用したダイジェスト値を再作成し、クライアントのダイジェストを検証します。ID アサーション プロバイダは、A1 値のハッシュを取得するために、クリアテキストのパスワードをストアから取得して HA1 を生成するか、または計算済みの HA1 をストアから取得します。
生成したダイジェスト文字列をクライアントのダイジェストと比較してユーザの ID を検証します。
ユーザの ID の検証が済むと、認証プロバイダは、ユーザが存在するかどうかを確認します。そして、存在する場合は、コンフィグレーションされたグループ情報を javax.security.auth.Subject に設定します。認証プロセスは以上で完了します。
|
注意 : ユーザが存在するかどうかのチェックやグループの設定が必要ない場合には、特別な「何もしない」ID アサーション認証プロバイダを使用すると、LDAP サーバに対する余分な接続を回避できます。詳細については、節 5.7.4.3「認証プロバイダのコンフィグレーション」を参照してください。 |
認証が完了した後で、SIP サーブレット コンテナは、サーブレットの sip.xml デプロイメント記述子で定義された宣言によるセキュリティ制約に照らして、ログインした javax.security.auth.Subject の認可チェックを実行します。
LDAP ダイジェスト ID アサーション プロバイダと、コンフィグレーションされた認証プロバイダは、同じ LDAP ストアを使用することも、別々のストアを使用することもできます。
|
注意 : 複数の LDAP ストアを使用する場合は、図 5-2 に示すように、ユーザ資格の追加、削除、または変更に応じて両方のストアを同期するための何らかのインフラストラクチャを構築する必要があります。LDAP ストアを同期する方法については、このドキュメントでは取り上げません。 |
ダイジェスト認証をコンフィグレーションするためには、LDAP サーバと LDAP 管理の基本を理解する必要があります。また、使用する LDAP サーバ実装の要件と制約を理解することと、LDAP のコンフィグレーションと Oracle WebLogic Communication Services のコンフィグレーションを変更する特権を持っていることも必要です。
表 5-1 は、Oracle WebLogic Communication Services と連係したダイジェスト認証を行うように LDAP サーバを完全にコンフィグレーションするために必要なすべての情報の概要です。
LDAP 認証プロバイダと、ダイジェスト認証 ID アサーション プロバイダは、複数の LDAP サーバに対してコンフィグレーションして、フェイルオーバ機能を実現できます。複数の LDAP サーバを使用したフェイルオーバ機能を実現するためには、ダイジェスト認証をコンフィグレーションするときに、各サーバに対する接続情報が必要です。節 5.7.4「ダイジェスト認証のコンフィグレーションの手順」を参照してください。
節 5.12「Oracle Internet Directory でのリソースのプロビジョニング」 は、Oracle Internet Directory の正しいリソースをプロビジョニングする方法について説明します。
表 5-2 ダイジェスト ID アサーション プロバイダのチェックリスト
| 項目 | 説明 | 値の例 |
|---|---|---|
|
Host |
LDAP サーバのホスト名。 |
MyLDAPServer |
|
Port |
LDAP サーバのポート番号。デフォルトでは 389 番のポートが使用されています。 |
389 |
|
Principal |
Oracle WebLogic Communication Services が LDAP サーバへの接続に使用できる識別名 (DN)。 |
cn=ldapadminuser |
|
Credential |
上記のプリンシパル名に対応する資格 (一般にはパスワード)。 |
ldapadminuserpassword |
|
LDAP Connection Timeout |
LDAP サーバへの接続に対してコンフィグレーションされたタイムアウト値 (秒単位)。パフォーマンスを最大限に高めるためには、LDAP サーバにタイムアウト値をコンフィグレーションしないようにします。LDAP サーバにタイムアウト値を設定した場合は、ダイジェスト ID アサーション プロバイダのタイムアウト値が LDAP サーバのタイムアウト値以下となるようにコンフィグレーションする必要があります。 |
30 秒 |
|
User From Name Filter |
Oracle WebLogic Communication Services が指定のユーザ名の検索で使用する LDAP 検索フィルタ。この属性に値を指定しない場合、ユーザ スキーマに基づくデフォルトの検索フィルタが使用されます。 |
(&(cn=%u)(objectclass=person)) |
|
User Base DN |
ユーザを格納する LDAP ディレクトリ内のツリーの基本識別名 (DN)。 |
cn=users,dc=mycompany,dc=com |
|
Credential Attribute Name |
ダイジェストの計算で使用する資格属性名。これは、暗号化されていないパスワードまたは計算済みのハッシュ値の格納に使用する属性名に対応します。節 5.7.4.1「LDAP サーバまたは RDBMS のコンフィグレーション」を参照してください。 |
hashvalue |
|
Digest Realm Name |
ダイジェスト認証で使用するレルム名。 |
mycompany.com |
|
Digest Algorithm |
暗号化されたダイジェストの作成でクライアントが使用するアルゴリズム。Oracle WebLogic Communication Services は MD5 アルゴリズムと MD5-sess アルゴリズムの両方をサポートします。デフォルトでは MD5 が使用されます。 |
MD5 |
|
Digest Timeout |
ダイジェスト認証のタイムアウトの設定。デフォルトでは 2 秒に設定されています。 |
2 |
Oracle WebLogic Communication Services でダイジェスト認証をコンフィグレーションするには、次の手順に従います。
節 5.7.4.2「DefaultAuthenticator プロバイダのコンフィグレーションの変更」
|
注意 : DefaultAuthenticator は、必須の認証プロバイダとしてデフォルトで設定されています。組み込み LDAP ストアに対して機能する DefaultAuthentication プロバイダを認証の判断に使用しない場合には、制御フラグを SUFFICIENT に変更する必要があります。 |
以下の節では、各手順について詳しく説明します。
ダイジェストの検証に使用する LDAP サーバまたは RDBMS には、暗号化されていないクリアテキストのパスワード、計算済みのハッシュ値、標準の暗号化アルゴリズム (デフォルトでは 3DES_EDE/CBC/PKCS5Padding) で暗号化されたパスワードのいずれかが格納されている必要があります。以下の節では、必要な情報を格納するための LDAP サーバまたは RDBMS の設定について、概要を示します。LDAP サーバでは、使用するスキーマや管理ツールが異なるため、以下の手順を実行する方法については、必要に応じて LDAP サーバのドキュメントを参照してください。
複数の LDAP サーバを使用したセキュリティ プロバイダのフェイルオーバ機能を有効にする場合は、各 LDAP サーバを次のようにコンフィグレーションする必要があります。
RDBMS を使用する場合、または、LDAP サーバのスキーマで、暗号化されていないパスワードをユーザのパスワード属性に格納することが認められている場合は、さらにコンフィグレーションを行う必要はありません。ダイジェスト ID アサーション プロバイダは、デフォルトでは、パスワード フィールドで、暗号化されていないパスワードを検索します。
パスワード属性に対し、暗号化されていないパスワードの格納が認められていないスキーマの場合には、次の 2 つの方法があります。
LDAP ディレクトリの既存の資格属性で未使用のものに対し、暗号化されていないパスワードを格納します。
新しい資格属性を作成して、暗号化されていないパスワードを格納します。
スキーマで利用可能な資格属性の詳細については、LDAP サーバのドキュメントを参照してください。どの方法を使用する場合も、暗号化されていないパスワードの格納に使用する正確な属性名を記録します。LDAP ダイジェスト ID アサーション プロバイダをコンフィグレーションするときに、この属性の名前を入力する必要があります。
暗号化されていないパスワードではなく、計算済みのハッシュ値を使用する場合には、LDAP ディレクトリの次の 2 つの場所のどちらかにハッシュ値を格納できます。
既存の未使用の資格属性。
ハッシュ値用に作成する新しい資格属性。
新しい資格属性の使用または作成の詳細については、LDAP サーバのドキュメントを参照してください。
RDBMS ストアの場合は、スキーマに含まれる任意のカラムにハッシュ値を格納できます。RDBMS ID アサーション プロバイダをコンフィグレーションするときに、ハッシュ値の取得に使用する SQL コマンドを定義します。
Oracle WebLogic Communication Services では、ユーザ名、レルム名、および暗号化されていないパスワードを指定して簡単なユーティリティ (PreCalculatedHash) で、A1 値のハッシュを生成できます。
また、サード パーティのユーティリティを使用したハッシュ値を生成したり、RFC 2617 の情報に基づいて独自のメソッドを作成することもできます。
ユーザ名、パスワード、またはレルム名の値が変更になったときに、格納したハッシュ値を自動的に更新するためのインフラストラクチャも構築する必要があります。パスワード情報をそのように維持する方法については、このドキュメントでは取り上げません。
Oracle WebLogic Communication Services に用意されているユーティリティを使用すると、ダイジェスト認可 ID アサーション プロバイダをコンフィグレーションするときに使用する、暗号化キー、暗号化の初期ベクタ、および暗号化パスワードの各値を計算できます。そのユーティリティの名前は JSafeEncryptionUtil で、WLSS_HOME/server/lib/wlss ディレクトリの wlss.jar ファイルにパッケージされています。
使用法の説明と構文を参照するには、次の手順に従います。
wlss.jar をクラスパスに追加します。デフォルトの場所は以下のとおりです (ただし、ユーザによるカスタマイズが可能です)。
export CLASSPATH=$CLASSPATH:WLSS_HOME=MW_HOME/wlcserver_10.3/server/lib/wlss/wlss.jar
オプションを指定せずにユーティリティを実行します。
プロダクション環境では、別個の LDAP プロバイダにパスワード情報を格納することが大半であり、したがって、組み込み LDAP ストアに対して機能する DefaultAuthenticator は認証に必須ではありません。この節の手順に従って、プロバイダの制御フラグを SUFFICIENT に変更します。
|
注意 : DefaultAuthenticator は、必須の認証プロバイダとしてデフォルトで設定されています。組み込み LDAP ストアに対して機能する DefaultAuthentication プロバイダを認証の判断に使用しない場合には、制御フラグを SUFFICIENT に変更する必要があります。 |
DefaultAuthenticator プロバイダのコンフィグレーションを変更するには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
DefaultAuthenticator プロバイダを選択します。
[コンフィグレーション｜共通] タブで、[制御フラグ] の値を [SUFFICIENT] に変更します。
[保存] をクリックして変更内容を保存します。
クライアントのダイジェストの検証のみを行うダイジェスト ID アサーション プロバイダに加えて、ユーザの存在のチェックとユーザのグループ情報の値の設定を行う認証プロバイダをコンフィグレーションする必要があります。『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の手順に従って、LDAP サーバ用の LDAP 認証プロバイダを構築します。表 5-1「Oracle WebLogic Communication Services でのダイジェスト認証」の情報を使用して、プロバイダをコンフィグレーションします。
ユーザが存在するかどうかのチェックやグループの設定が必要ない場合には、Digest Identity Asserter プロバイダに加えて、「IdentityAssertionAuthenticator」という名前でパッケージ化された特別な「何もしない」ID アサーション認証プロバイダを使用すると、LDAP サーバに対する余分な接続を回避できます。このプロバイダはユーザ検証を実行しません。ユーザに対しグループ情報が必要ない場合に使用する必要があります。
「何もしない」認可プロバイダをコンフィグレーションするには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダ名を入力し、タイプには [IdentityAssertionAuthenticator] を選択します。
[OK] をクリックします。
プロバイダのリストから新しいプロバイダ名を選択します。
[コンフィグレーション｜共通] タブで、[制御フラグ] の値を [SUFFICIENT] に設定します。
[保存] をクリックして変更内容を保存します。
以下のどちらかの節の手順に従って、ダイジェスト ID アサーション プロバイダを作成し、LDAP サーバまたは RDBMS ストアと関連付けます。
次の手順に従って、新しい LDAP ダイジェスト ID アサーション プロバイダを作成します。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダ名を入力し、タイプには [LdapDigestIdentityAsserter] を選択します。
[OK] をクリックします。
プロバイダのリストから新しいプロバイダ名を選択します。
右ペインでの [コンフィグレーション｜Provider Specific] タブを選択します。
コンフィグレーション ページで、LDAP サーバとダイジェスト認証の情報を各フィールドに次のように入力します (表 5-1 の情報を使用)。
[User From Name Filter] : Oracle WebLogic Communication Services が指定のユーザ名の検索で使用する LDAP 検索フィルタを入力します。この属性に値を指定しない場合、ユーザ スキーマに基づくデフォルトの検索フィルタが使用されます。
[User Base DN] : ユーザを格納する LDAP ディレクトリ内のツリーの基本識別名 (DN) を入力します (たとえば、cn=Users,dc=example,dc=com)。
[Credential Attribute Name] : 計算済みのハッシュ値または暗号化されていないパスワードのいずれかを格納する、LDAP ディレクトリの資格属性を入力します (たとえば、authpassword;wlss)。デフォルトでは、ユーザ エントリのパスワード属性が使用されます。暗号化されていないパスワードではなく計算済みのハッシュ値を使用する場合や、暗号化されていないパスワードが別の属性に格納されている場合は、正しい属性名をここに指定する必要があります。
[Group Attribute Name] : ユーザが属する一連のグループ名が格納された、LDAP ディレクトリのグループ属性を入力します。
[Password Encryption Type] : パスワードが格納されている形式を、[PLAINTEXT]、[PRECALCULATEDHASH]、[REVERSIBLEENCRYPTED] のいずれかから選択します。
[Encryption Algorithm] : 暗号化したパスワードを格納した場合は、ダイジェスト ID アサーション プロバイダが逆暗号化に使用する暗号化アルゴリズムを入力します。
[Encryption Key] と [Please type again to confirm] : 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 暗号化キーを入力します。
[Encryption Init Vector] と [Please type again to confirm] : 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 初期ベクタを入力します。
[Digest Realm Name] : ダイジェスト認証で使用するレルム名を入力します (たとえば、example.com)。
[Digest Algorithm] : ダイジェストの暗号化に使用するアルゴリズムとして [MD5] または [MD5-sess] を選択します。
[Digest Timeout] : ダイジェスト チャレンジの nonce タイムアウト値を定義します。クライアントから応答がないままに nonce タイムアウトに達した場合は、新しい nonce でクライアントに対して改めてチャレンジが送信されます。デフォルトでは 120 秒に設定されています。
[Host] : ダイジェスト認証に使用する LDAP サーバのホスト名を入力します。フェイルオーバ機能として複数の LDAP サーバを使用している場合は、各サーバに対応する hostname:port 値をスペース区切りで入力します。たとえば、「ldap1.mycompany.com:1050 ldap2.mycompany.com:1050」のように指定します。
フェイルオーバのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
[Port] : LDAP サーバのポート番号を入力します。
[SSL Enabled] : Oracle WebLogic Communication Services と LDAP サーバの間で、暗号化されていないパスワードを、SSL を使用して通信している場合は、このオプションをチェックします。
[Principal] : Oracle WebLogic Communication Services が LDAP サーバへのアクセスに使用するプリンシパルの名前を入力します (たとえば、orclApplicationCommonName=WLSSInstance1,cn=WLSS,cn=Products,cn=OracleContext,dc=example,dc=com)。
[Credential] と [Please type again to confirm]: 上記のプリンシパル名に対応する資格情報 (一般にはパスワード) を入力します。
[OIDSupportEnabled] : LDAP プロバイダとして Oracle Internet Directory を使用している場合は、このチェックボックスをチェックします。RFC 2307 に記述されているように Oracle Internet Directory ではハッシュ値に {SASL/MD5} のプレフィックスが付けられるため、計算済みのハッシュ値を使用する場合は、このチェックボックスが必須です。その他の LDAP プロバイダではプレフィックスが省略されます。
[保存] をクリックして変更内容を保存します。
右ペインで [パフォーマンス] タブを選択します。
[Performance] ページで、キャッシングと接続の情報を以下のフィールドに入力します。
[LDAP Connection Pool Size] : LDAP サーバへの接続に使用する接続数を入力します。この値は、Oracle WebLogic Communication Services でコンフィグレーションされた実行スレッドの総数以下にする必要があります。現在コンフィグレーションされているスレッド数を参照するには、Administration Console の左ペインで Oracle WebLogic Communication Services の名前を右クリックし、[実行キューを表示] を選択します。SIP コンテナは、sip.transport.Default という名前のキューのスレッド数の値を使用します。LDAP Connection Pool Size のデフォルト値は 10 です。
古い接続 (たとえばロード バランサによりタイム アウトとなった LDAP 接続) は接続プールから自動的に削除されます。
[Cache Enabled] : 対応する LDAP サーバでキャッシュを使用するかどうかを指定します。
[Cache Size] : LDAP サーバからの結果の格納に使用するキャッシュのサイズを KB 単位で指定します。デフォルトのキャッシュ サイズは 32KB です。
[Cache TTL] : LDAP キャッシュ用の存続時間 (TTL) の値を秒単位で指定します。デフォルトの TTL 値は 60 秒です。
[Results Time Limit] : LDAP の結果を待つ最大ミリ秒数を指定します。この時間を超えるとタイム アウトになります。タイム リミットを設定しない場合は、デフォルト値の 0 をそのまま使用します。
[Connect Timeout] : LDAP 接続が確立されるのを待つ最大ミリ秒数を指定します。この時間を超えると、接続はタイム アウトになります。タイムアウト値を設定しない場合は、デフォルト値の 0 を使用します。
[Parallel Connect Delay] : コンフィグレーション済みの複数の LDAP サーバに同時に接続を試みるときに遅延する秒数を指定します。この値を 0 に設定した場合、プロバイダは複数サーバに順次接続します。プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバへの接続を試みます。この接続が失敗した場合、プロバイダは、次のコンフィグレーション済みサーバに接続を試みます。以下同様です。
0 以外の値を設定した場合、プロバイダは、指定した秒数だけ待機したうえで、別の接続を試みるための新しいスレッドを生成します。たとえば、この値を 2 に設定した場合、プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバに接続を試みます。2 秒が経過した時点で接続がまだ確立されていない場合、プロバイダは、新しいスレッドを生成し、[Host] リストの 2 番目のコンフィグレーション済み LDAP サーバへの接続を試みます。以下同様に、コンフィグレーション済みの各 LDAP サーバに対する接続を試みます。
[Connection Retry Limit]: 接続の確立時に LDAP サーバが例外を送出した場合に、プロバイダが LDAP サーバへの接続の再確立を試行する回数を指定します。
[保存] をクリックして変更内容を保存します。
次の手順に従って、新しい RDBMS ダイジェスト ID アサーション プロバイダを作成します。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダの名前を入力し、種類として DBMSDigestIdentityAsserter を選択します。
[OK] をクリックします。
プロバイダのリストから新しいプロバイダ名を選択します。
右ペインでの [コンフィグレーション｜Provider Specific] タブを選択します。
[コンフィグレーション] タブで、RDBMS サーバとダイジェスト認証の情報を各フィールドに次のように入力します。
[Data Source Name]: パスワード情報のアクセスに使用する JDBC データ ソースの名前を入力します。
[SQLGet Users Password]: データベースからパスワードまたはハッシュ値を取得するときに使用する SQL 文を入力します。単一のレコードの結果セットを返す SQL 文であることが必要です。
[SQLList Member Groups]: 指定したユーザ名からグループ情報を取得する SQL 文を入力します。ユーザ名は SQL 文に対して変数として渡します。たとえば、「SELECT G_NAME FROM groupmembers WHERE G_MEMBER = ?」のようにします。
[Password Encryption Type]: パスワードが格納されている形式を、[PLAINTEXT]、[PRECALCULATEDHASH]、[REVERSIBLEENCRYPTED] のいずれかから選択します。
[Encryption Algorithm]: 暗号化したパスワードを格納した場合は、ダイジェスト ID アサーション プロバイダが逆暗号化に使用する暗号化アルゴリズムを入力します。
[Encryption Key] と [Please type again to confirm]: 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 暗号化キーを入力します。
[Encryption Init Vector] と [Please type again to confirm]: 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 初期ベクタを入力します。
[Digest Realm Name]: ダイジェスト認証で使用するレルム名を入力します。
[Digest Algorithm]: ダイジェストの暗号化に使用するアルゴリズムとして [MD5] または [MD5-sess] を選択します。
[Digest Timeout]: ダイジェスト チャレンジの nonce タイムアウト値を定義します。クライアントから応答がないままに nonce タイムアウトに達した場合は、新しい nonce でクライアントに対して改めてチャレンジが送信されます。デフォルトでは 120 秒に設定されています。
[保存] をクリックして変更内容を保存します。
Oracle WebLogic Communication Services の組み込み LDAP 実装を利用すると、テストまたはデモ環境でダイジェスト認証を使用できます。組み込み LDAP ストアのスキーマは変更できないので、既存の「記述」フィールドにパスワード情報を格納する必要があります。
組み込み LDAP ストアをダイジェスト認証に使用するには、以下の節の手順に従います。
新しいユーザを作成し、既存の「記述」フィールドにパスワード情報を格納するには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[ユーザおよびグループ｜ユーザ] タブを選択します。
[新規] をクリックします。
[名前] フィールドに、新しいユーザの名前を入力します。
[記述] フィールドに、このユーザのダイジェストのパスワード情報を入力します。パスワード情報は、クリアテキスト パスワード、計算済みのハッシュ値、または逆暗号化パスワードのいずれかとします。
[パスワード] フィールドと [パスワードの確認] フィールドに、8 文字のパスワードを入力します。標準のパスワード エントリを追加しないと、次へ進むことはできません。
[OK] をクリックします。
次の手順に従って、組み込み LDAP ストアのパスワードを既知のパスワードに設定します。節 5.7.4.4.1「LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション」で説明するように、ダイジェスト ID アサーション プロバイダをコンフィグレーションするときにこのパスワードを使用します。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
左ペインで、コンフィグレーションするドメイン名 （たとえば、mydomain） をクリックします。
右ペインで、[Security｜Embedded LDAP] を選択します。
使用するパスワードを、[資格] フィールドと [資格の確認] フィールドに入力します。
[保存] をクリックします。
サーバを再起動します。
例 5-1 は Oracle WebLogic Communication Services の組み込み LDAP 実装を使用するドメインの config.xml のセキュリティ プロバイダ コンフィグレーションを示します。このようなコンフィグレーションはテスティングや開発のみを目的とする場合に適しています。例 5-1 には、節 5.7.4.4.1「LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション」に示す手順にしたがってプロバイダをコンフィグレーションする時に定義する必要がある値について説明します。
例 5-1 組み込み LDAP でのセキュリティ プロバイダ コンフィグレーションのサンプル
<sec:authentication-provider xmlns:ext="http://www.bea.com/ns/weblogic/90/security/extension" xsi:type="ext:ldap-digest-identity-asserterType"> <sec:name>myrealmLdapDigestIdentityAsserter</sec:name> <ext:user-base-dn>ou=people, ou=myrealm, dc=mydomain</ext:user-base-dn> <ext:credential-attribute-name>description</ext:credential-attribute-name> <ext:digest-realm-name>wlss.oracle.com</ext:digest-realm-name> <ext:host>myserver.mycompany.com</ext:host> <ext:port>7001</ext:port> <ext:principal>cn=Admin</ext:principal> </sec:authentication-provider>
Client-Cert 認証では、証明書やその他のカスタム トークンを使用してユーザを認証します。トークンは、サーブレットがデプロイされている Oracle WebLogic Communication Services セキュリティ レルムに属するユーザに「マッピング」されています。Client-Cert 認証を使用する SIP サーブレットは、sip.xml デプロイメント記述子で auth-method 要素を CLIENT-CERT に設定する必要があります。
Client-Cert 認証に使用するトークンを取得するには、次のような方法があります。
SSL の X509 証明書 - 通常、クライアントとサーバの間の双方向の SSL ハンドシェイクの際に、クライアント トークンから X509 証明書が取得されます。SIP サーブレットでは、取得された証明書を、リクエストの javax.servlet.request.X509Certificate 属性で参照できます。この方法による Client-Cert 認証の実行は最も一般的であり、SIP Servlet 仕様 (JSR-116) でも述べられています。Oracle WebLogic Communication Services には、X509 証明書の検証に使用できるセキュリティ プロバイダが つあります。節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」を参照してください。
WL-Proxy-Client-Cert ヘッダ - Oracle WebLogic Communication Services には、Client-Cert トークンを提供する方法がもう 1 つ用意されており、こちらはクライアントとサーバの間の双方向の SSL ハンドシェイクを必要としません。この方法では、SSL ハンドシェイクは、宛先の Oracle WebLogic Communication Services に達する前に、クライアントとプロキシ サーバまたはロード バランサの間で実行されます。プロキシは、X509 証明書チェーンを生成し、Base64 エンコーディングを使用して暗号化したうえで、SIP メッセージの特別な WL-Proxy-Client-Cert ヘッダに追加します。宛先の SIP サーブレットをホストするサーバは、この WL-Proxy-Client-Cert ヘッダを使用して証明書を取得します。また、コンテナからサーブレットに対しては、リクエストの javax.servlet.request.X509Certificate 属性を通じて証明書が提供されます。
この方法を使用してクライアント トークンを提供するには、WL-Proxy-Client-Cert ヘッダを使用できるように Oracle WebLogic Communication Services をコンフィグレーションする必要があります。節 5.8.2「Oracle WebLogic Communication Services での WL-Proxy-Client-Cert のコンフィグレーション」を参照してください。また、X509 ID アサーション プロバイダもコンフィグレーションする必要があります。詳細については、節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」を参照してください。
SIP サーブレットでは、CLIENT-CERT auth-method を使用して境界認証を実装することもできます。境界認証では、カスタム トークンの名前と値、およびカスタム セキュリティ プロバイダを使用してクライアントを認証します。境界認証を実装するために必要な手順の概要については、節 5.8.3「カスタム ID アサーション プロバイダによる境界認証のサポート」を参照してください。
Oracle WebLogic Communication Services には、X509 証明書に対して使用できる ID アサーション プロバイダが 2 種類用意されています。LDAP X509 ID アサーション プロバイダは、X509 証明書を受け取り、その証明書に関連付けられたユーザの LDAP オブジェクトを別の LDAP ストアでルックアップして、LDAP オブジェクトの証明書が提示された証明書と一致することを確認したうえで、LDAP オブジェクトからユーザの名前を取得します。デフォルト ID アサーション プロバイダは、コンフィグレーションに基づいてユーザをマッピングしますが、証明書の検証は行いません。
いずれのプロバイダの場合も、Oracle WebLogic Communication Services は、双方向 SSL を使用して、クライアントから提示されたデジタル証明書を検証します。Client-Cert 認証を使用するためには、SIPS トランスポート (SSL) がコンフィグレーションされていることが必要です。セキュア伝送をまだコンフィグレーションしていない場合は、『ネットワーク リソースのコンフィグレーション』の「Oracle WebLogic Communication Services のネットワーク リソースの管理」を参照してください。
デフォルト ID アサーション プロバイダをコンフィグレーションするには、節 5.8.1.1「デフォルト ID アサーション プロバイダのコンフィグレーション」を参照してください。多くのプロダクション インストールでは、LDAP ストアが別個にあり、Client-Cert 認証を使用するように LDAP X1079724 ID アサーション プロバイダをコンフィグレーションする必要があります。詳細については節 5.8.1.2「LDAP X509 ID アサーション プロバイダのコンフィグレーション」を参照してください。
セキュリティ保護された SSL 接続を通じてクライアントから渡された X509 証明書を検証するように、デフォルト ID アサーション プロバイダをコンフィグレーションできます。デフォルト ID アサーション プロバイダには、デフォルト セキュリティ レルムでコンフィグレーションされたユーザに、対応するクライアントの「証明書」をマッピングするためのユーザ名マッパーが別個に必要です。Oracle WebLogic Communication Services に付属のデフォルト ユーザ名マッパーを使用することも、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』に説明する方法でカスタム ユーザ名マッパー クラスを作成することもできます。
次の手順に従って、デフォルト ID アサーション プロバイダをコンフィグレーションします。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
コンソールの右ペインで、コンフィグレーション済みプロバイダの表から [DefaultIdentityAsserter] を選択します。
[コンフィグレーション｜一般] ページでアクティブなタイプ テーブルの [選択可] カラムで X.509 を選択し、矢印をクリックして、[選択済み] カラムに移動します。
[保存] をクリックして変更を適用します。
カスタム Java クラスを使用して X509 証明書の名前と組み込みの LDAP ストアのユーザ名とをマッピングすることも、デフォルト ユーザ名マッパーを使用することもできます。ユーザ名のマッピングを実行するカスタム Java クラスを指定するには、次の手順に従います。
[コンフィグレーション｜Provider Specific] タブを選択します。
カスタム クラスの名前を [ユーザ名マッパーのクラス名] フィールドに入力します。
[保存] をクリックします。
デフォルト ユーザ名マッパーを使用するには、次の手順に従います。
[コンフィグレーション｜Provider Specific] タブを選択します。
[デフォルト ユーザ名マッパーを使用] を選択します。
[デフォルト ユーザ名マッパー属性タイプ] リストで、[CN （一般名）] または [E（電子メール アドレス）] のどちらかを、セキュリティ レルムに格納したユーザ名属性に応じて選択します。
[デフォルト ユーザ名マッパー属性の区切り文字] フィールドで、デフォルトの区切り文字である @ をそのまま使用します。この区切り文字は、[E（電子メール アドレス）] の属性で使用し、クライアント トークンから電子メール部分を抽出します。たとえば、「joe@mycompany.com」のトークンは、デフォルト セキュリティ レルムでコンフィグレーションされたユーザ名「joe」にマッピングされます。
[保存] をクリックします。
X509 認証プロバイダを作成およびコンフィグレーションするには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダ名を入力し、[LDAPX509IdentityAsserter] をタイプとして選択します。
[OK] をクリックします。
プロバイダのリストで、作成したプロバイダ名を選択します。
[コンフィグレーション｜Provider Specific] タブで、LDAP サーバ情報を各フィールドに以下のように入力します。
[ユーザ フィルタの属性] : Oracle WebLogic Communication Services が、指定のユーザ名の検索で使用する LDAP 検索フィルタを入力します。このフィルタは、下記の [証明書のマッピング] 属性で定義されたベース DN の下の LDAP オブジェクトに適用されます。
[ユーザ名の属性] : ユーザ名を保持する LDAP 属性を入力します。
[証明書の属性] : ユーザ名に対応する証明書を保持する LDAP 属性を入力します。
[証明書のマッピング] : ユーザの LDAP オブジェクトの検索に使用される LDAP ベース DN を構築するクエリ文字列を指定します。
[ホスト] : 受け取った証明書を検証する LDAP サーバのホスト名を入力します。フェイルオーバ機能として複数の LDAP サーバを使用している場合は、各サーバに対応する hostname:port 値をスペース区切りで入力します。たとえば、「ldap1.mycompany.com:1050 ldap2.mycompany.com:1050」のように指定します。
フェイルオーバのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
[Port] : LDAP サーバのポート番号を入力します。
[SSL Enabled] : Oracle WebLogic Communication Services と LDAP サーバの間で、暗号化されていないパスワードを、SSL を使用して通信している場合は、このオプションをチェックします。
[Principal] : Oracle WebLogic Communication Services が LDAP サーバへのアクセスに使用するプリンシパルの名前を入力します。
[Credential] : 上記のプリンシパル名に対応する資格 (一般にはパスワード) を入力します。
[Confirm Credential] : プリンシパルの資格を再入力します。
[Cache Enabled] : 対応する LDAP サーバでキャッシュを使用するかどうかを指定します。
[Cache Size] : LDAP サーバからの結果の格納に使用するキャッシュのサイズを KB 単位で指定します。デフォルトのキャッシュ サイズは 32KB です。
[Cache TTL] : LDAP キャッシュ用の存続時間 (TTL) の値を秒単位で指定します。デフォルトの TTL 値は 60 秒です。
[Follow Referrals] : LDAP X509 ID アサーション プロバイダのユーザまたはグループの検索で、他の LDAP サーバまたは LDAP ディレクトリ内のブランチの照会先に従う場合は、このボックスをチェックします。
[Bind Anonymously On Referrals] : デフォルトでは、LDAP X509 ID アサーション プロバイダは、検索時に照会先に従う場合に、LDAP サーバへの接続に使用するものと同じ DN およびパスワードを使用します。匿名ユーザとして接続する場合は、このボックスをチェックします。
[Results Time Limit] : LDAP の結果を待つ最大ミリ秒数を指定します。この時間を超えるとタイム アウトになります。タイム リミットを設定しない場合は、デフォルト値の 0 をそのまま使用します。
[Connect Timeout] : LDAP 接続が確立されるのを待つ最大ミリ秒数を指定します。この時間を超えると、接続はタイム アウトになります。タイムアウト値を設定しない場合は、デフォルト値の 0 を使用します。
[Parallel Connect Delay] : コンフィグレーション済みの複数の LDAP サーバに同時に接続を試みるときに遅延する秒数を指定します。この値を 0 に設定した場合、プロバイダは複数サーバに順次接続します。プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバへの接続を試みます。この接続が失敗した場合、プロバイダは、次のコンフィグレーション済みサーバに接続を試みます。以下同様です。
0 以外の値を設定した場合、プロバイダは、指定した秒数だけ待機したうえで、別の接続を試みるための新しいスレッドを生成します。たとえば、この値を 2 に設定した場合、プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバに接続を試みます。2 秒が経過した時点で接続がまだ確立されていない場合、プロバイダは、新しいスレッドを生成し、[Host] リストの 2 番目のコンフィグレーション済み LDAP サーバへの接続を試みます。以下同様に、コンフィグレーション済みの各 LDAP サーバに対する接続を試みます。
[Connection Retry Limit] : 接続の確立時に LDAP サーバが例外を送出した場合に、プロバイダが LDAP サーバへの接続の再確立を試行する回数を指定します。
[保存] をクリックして変更内容を保存します。
変更したセキュリティ コンフィグレーションを有効にするために、サーバを再起動します。
Oracle WebLogic Communication Services が WL-Proxy-Client-Cert ヘッダを使用するためには、プロキシ サーバまたはロード バランサがクライアント リクエストに対応する X509 証明書をまず送信し、Base-64 エンコーディングを使用して暗号化したうえで、得られたトークンを SIP メッセージの WL-Proxy-Client-Cert ヘッダに追加する必要があります。システムがそのようにコンフィグレーションされている場合には、ローカルの Oracle WebLogic Communication Services インスタンス (または個々の SIP サーブレット インスタンス) で、WL-Proxy-Client-Cert ヘッダを調べて、クライアント トークンをチェックできます。
WL-Proxy-Client-Cert ヘッダを使用するようにサーバ インスタンスをコンフィグレーションするには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
左ペインで、[環境｜サーバ] ノードを選択します。
コンフィグレーションするエンジン層サーバ名を選択します。
右ペインの [コンフィグレーション｜一般] タブを選択します。
[クライアント証明書プロキシを有効化] をチェックします。
[保存] をクリックして変更内容を保存します。
節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」の手順に従って、X509 証明書を処理するデフォルト ID アサーション プロバイダまたは LDAP ID アサーション プロバイダをコンフィグレーションします。
サーバを再起動して、変更したコンフィグレーションを有効にします。
個別の Web アプリケーションに対して WL-Proxy-Client-Cert ヘッダを有効にするには、アプリケーションの sip.xml デプロイメント記述子で com.bea.wcp.clientCertProxyEnabled コンテキスト パラメータを true に設定します。
境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します。通常このシステムでは認証エージェントを使用します。認証エージェントは、認証ユーザについての情報を後で確認するために提示が必要なアーティファクトまたはトークンを作成します。トークンの実際のフォーマットはベンダごとに異なります (たとえば SAML や SPNEGO など)。
Oracle WebLogic Communication Services では、1 つまたは複数のトークン フォーマットを認識するようにデザインされた ID アサーション プロバイダの使用による境界認証がサポートされています。SIP サーブレットの認証タイプが CLIENT-CERT に設定されている場合、Oracle WebLogic Communication Services の SIP コンテナは、リクエスト ヘッダからの値に対して ID アサーションを実行します。ヘッダの名前が、コンフィグレーションされたプロバイダのアクティブなトークンの種類に合致する場合、ID アサーション用のプロバイダに値が渡されます。
プロバイダは、ユーザ名マッパーを使用して、証明書をセキュリティ レルム内のユーザに解決します。クライアントのデジタル証明書のサブジェクトの識別名 (SubjectDN) 属性に対応するユーザが、サーバのセキュリティ レルムに定義されている必要があります。このユーザが定義されていない場合、WebLogic の保護リソースに対するクライアントからのアクセスは認められません。
境界認証用のクライアント証明書の受け渡しにカスタム トークンを使用するには、前述の LDAP X509 またはデフォルト ID アサーション プロバイダの代わりに、カスタムの ID アサーション プロバイダを作成およびコンフィグレーションする必要があります。境界認証で渡されたトークンを処理するプロバイダの作成の詳細については、WebLogic Server ドキュメントの『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
次のどちらかの ID アサーション メカニズムを使用するように SIP サーブレットをコンフィグレーションできます。
P-Asserted-Identity : このメカニズムでは、信頼できるドメインから発信される SIP メッセージの P-Asserted-Identity ヘッダを使用して ID をアサートする必要があります。この ID アサーション メカニズムについては RFC 3325 で説明されています。
Identity : このメカニズムでは、他のドメインから発生した SIP メッセージの Identity および Identity-Info ヘッダを使用して、ID をアサートする必要があります。この ID アサーションのメカニズムは RFC 4474 に記述されています。
選択した ID アサーション メカニズムは sip.xml デプロイメント記述子の identity-assertion 要素に定義されています。identity-assertion-support 要素は、サーブレットに対して ID アサーション メカニズムが必要かどうか、または、必要なヘッダが含まれていない SIP メッセージに対して別の認証メカニズムを使用できるかどうかを決定します。サーブレットの ID アサーションのコンフィグレーションについては、SIP サーブレット仕様 v1.1 を参照してください。
Oracle WebLogic Communication Services はセキュリティ プロバイダを使用して、ID アサーション メカニズムをサポートします。以下の節では、Oracle WebLogic Communication Services は各 ID アサーション メカニズムでメッセージを処理する方法および必要なセキュリティ プロバイダを設定する方法の詳細について説明します。
|
注意 : Oracle WebLogic Communication Services のバージョンは SIP サーブレット v1.0 仕様に準拠しているアプリケーション用の下位互換性を提供します。 |
P-Asserted-Identity ヘッダは信頼できるドメイン内でのみ処理されます。Oracle WebLogic Communication Services システムでは、信頼できるドメインは純粋にコンフィグレーション ベースで判断されます。このヘッダの使用を有効にするには、節 5.9.3「P-Asserted-Identity アサーション プロバイダのコンフィグレーション」で説明するように、2 つのうちどちらか 1 つの P-Asserted Identity アサーション プロバイダをコンフィグレーションする必要があります。P-Asserted-Identity アサーション プロバイダは、P-Asserted-Identity ヘッダの信頼できるドメインのコンフィグレーションを公開します。プロバイダが 1 つもコンフィグレーションされていない場合、ヘッダでは、信頼できる IP アドレスがないものとして扱われます。
プロバイダでコンフィグレーションされている信頼できるホストから、P-Asserted-Identity ヘッダが含まれるメッセージを受け取ると、Oracle WebLogic Communication Services はヘッダで指定されたユーザのログインを許可し、グループ メンバシップやその他の権限を判断します。P-Asserted-Identity ヘッダに含まれる値は、常に SIP アドレス (sipuser@oracle.com など) です。デフォルトでは、Oracle WebLogic Communication Services はアドレスのドメイン部分 (@oracle.com) が削除され、残りの部分がユーザ名として使用されます。重複するユーザ名 (sipuser@oracle.com と sipuser@cea.com など) を個別のものとして扱う必要がある場合、カスタム ユーザ名マッパーを作成および使用し、ヘッダの情報を処理して一意のユーザ名 (sipsuser_b と sipuser_c) を生成することができます。カスタム ユーザ名マッパーを使用すると、@ 文字を含む WebLogic ユーザ名 (@oracle.com など) をサポートすることもできます。
Privacy ヘッダと組み合わせた P-Asserted-Identity ヘッダを使用すると、Oracle WebLogic Communication Services が受信するリクエストをどのようにプロキシするかを判断できます。sip.xml の identity-assertion-support 要素の値も参考にされます。図 5-3 は、P-Asserted-Identity ヘッダに対する着信 SIP リクエストの管理方法について説明します。
図 5-3 P-Asserted-Identity ヘッダと Privacy ヘッダのある着信リクエストの管理
図 5-4 に、指定されたユーザ名に権限がないため必要なリソースにアクセスできない場合の、セキュリティ チェックの標準的手順を示します。この標準的セキュリティ チェックは、当該アプリケーションの sip.xml 記述子の login-config 要素に定義されている auth-method に従って実行されます。
P-Asserted-Identity ヘッダまたは P-Preferred-Identity ヘッダを使用すると、発信 SIP リクエストの処理にも影響します。図 5-5 は、行動を説明します。
図 5-5 P-Asserted-Identity ヘッダまたは P-Preferred Identity ヘッダのある発信リクエストの管理
P-Asserted-Identity ヘッダの内容が無効の場合、または信頼できないホストからヘッダを受け取った場合は、セキュリティ プロバイダが SIP サーブレット コンテナに「匿名」ユーザを返します。PAsserted Identity Strict Asserter プロバイダをコンフィグレーションした場合は、例外も送出されるので、匿名ユーザの代用を監査することができます(基本 PAsserted Identity Asserter プロバイダをコンフィグレーションした場合は、例外が送出されません)。
どちらのプロバイダでも、ID のアサーションが失敗して要求されたリソースが保護されている場合 (リクエストが sip.xml の security-constraint と一致する場合)、SIP コンテナは sip.xml デプロイメント記述子に定義されている auth-method を使用してエンド ユーザを認証します。たとえば、サーブレットでダイジェスト認証方式が指定されている場合はダイジェスト認証が使われます。
要求されたリソースが保護されていない場合は、匿名ユーザが認可なしでそのまま SIP サーブレットに渡されます。3GPP TS 24.229 仕様では、リソースが制限されていない (そして機密保護が必要とされていない) 場合でも権限を付与することが推奨されています。これに準拠するため、宣言によるセキュリティを使用して SIP サーブレットのすべてのリソースを保護してください。
匿名ユーザに権限が付与されなかった場合は、チャレンジによるユーザの認証が行われます。
P-Asserted-Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。節 5.9.2「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」で説明したように、2 つのうちどちらか 1 つのプロバイダを選択できます。
上記のプロバイダのどちらか 1 つのコンフィグレーションに加えて、第二のフォールバック的なログイン方法 (DIGEST 認証または CLIENT-CERT 認証の使用など) もコンフィグレーションしてください。
P-Asserted-Identity プロバイダをコンフィグレーションするには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[新規] をクリックします。
新しいプロバイダ名を入力し、[Type] フィールドに以下のどちらかのオプションを選択します。
[PAssertedIdentityAsserter] : P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出しないプロバイダをコンフィグレーションします。
[PAssertedIdentityStrictAsserter] : P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出するプロバイダをコンフィグレーションします。
詳細については、節 5.9.2「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」を参照してください。
[OK] をクリックします。
作成したプロバイダ名を選択します。
[コンフィグレーション｜Provider Specific] タブを選択します。
[コンフィグレーション] タブの各フィールドに以下の情報を入力します。
[Trusted Hosts]: プロバイダが信頼できるホストとして扱う 1 つまたは複数のホスト名を入力します。IP アドレスと DNS 名のどちらでも入力できます。また、ワイルドカードを使用することもできます。
|
注意 : このプロバイダは、sipserver.xml ファイルに信頼できるホストとしてコンフィグレーションされているホストは使用しません。 |
[User Name Mapper Class Name] : P-Asserted-Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。カスタム ユーザ名マッパーは、通常、ユーザ名が複数のドメインから送られてきた場合に使用されます。この場合、ここのドメインから受け取ったユーザ名をマップするために追加のロジックが必要とされることもあります。P-Asserted-Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
このフィールドを空白のままにすると、デフォルトのユーザ名マッパーが使われます。デフォルトのユーザ名マッパーでは、ドメイン名を破棄し、残ったユーザ名をそのまま (何のロジックも適用せずに) 使用します。
[保存] をクリックします。
Oracle WebLogic Communication Services は、RFC 4474 に記述されているようにIdentity および Identity-Info ヘッダを使用して、ID アサーションを実行することもできます。p-asserted-identity アサーション メカニズムと同様に、Identity ヘッダ アサーションには、Oracle WebLogic Communication Services の適当なセキュリティ プロバイダ (IdentityHeaderAsserter プロバイダ) を最初にコンフィグレーションする必要があります。
Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストを確認すると、Oracle WebLogic Communication Services は sip.xml の identity-assertion と identity-assertion-support 要素の値およびコンフィグレーション済みのセキュリティ プロバイダの存在を検討します。図 5-6 では、このアサーション メカニズムを使用して着信メッセージを処理する方法について説明します。
図 5-6 Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストの管理
Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
右ペインで [プロバイダ｜認証] タブをクリックします。
[新規] をクリックします。
新しいプロバイダ名を入力し、タイプには [IdentityHeaderAsserter] を選択します。
[OK] をクリックします。
作成したプロバイダ名を選択します。
[プロバイダ固有] タブを選択します。
[コンフィグレーション] タブの各フィールドに以下の情報を入力します。
[Date Period] : Date ヘッダのため有効な期間 (秒単位) を入力します。
[Https Channel Name] : プロバイダは HTTP クライアントの初期化に使用する HTTP チャネルの名前を入力します。HTTPS を通してリモート証明書を取得される場合、(個別にコンフィグレーションされている) HTTPS チャネルが必要です。
[User Name Mapper Class Name] (省略可能) : Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
[保存] をクリックします。
Oracle WebLogic Communication Services は、IMS ネットワーク内でアプリケーション サーバとして機能するように、「3GPP TS Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) (http://www.3gpp.org/ftp/Specs/html-info/33222.htm)」の仕様に従って XGPP-Asserted-Identity ヘッダの処理をサポートしています。このサポートは、X3gppAssertedIdentityAsserter または X3gppAssertedIdentityStrictAsserter というコンフィグレーション済みのセキュリティ プロバイダを通じて提供されます。どちらのプロバイダも使用する認証プロセスは同じですが、厳密 (Strict) なアサーション プロバイダの方は、信頼できないホストからヘッダを受け取ると例外を送出します (これにより、信頼できないホストからアサートされた ID リクエストの監査が可能になります)。
X-3GPP-Asserted-Identity ヘッダの HTTP リクエストに対する機能は、P-Asserted-Identity ヘッダの SIP に対する機能と同様です。コンテナは X-3GPP-Asserted-Identity ヘッダ付きの HTTP リクエストを受け取ると、まず、そのリクエストが信頼性できるホストから送信されたものかどうかを確認します。そのホストが信頼できる場合、コンテナはヘッダ内の情報を使用してユーザの ID をアサートして認証し、さらに、要求されているリソースへのアクセス権がそのユーザに与えられている場合はログインを許可します (リクエストが信頼できないホストから送信されたものである場合、コンテナは単にヘッダを無視します)。
X-3GPP-Asserted-Identity ヘッダには、複数の名前のリスト (user1@oracle.com、user2@oracle.com など) が含まれていることもあります。デフォルト ユーザ名マッパー クラスでコンフィグレーションされている場合、Oracle WebLogic Communication Services はアドレスのドメイン部 (@oracle.com) を取り除き、残りをユーザ名として使用します。デフォルト ユーザ名マッパーは常に、リスト内の最初のユーザ名を選択し、それを ID のアサーションに使用します。この動作は、カスタム ユーザ名マッパー クラスを作成およびコンフィグレーションすることにより、変更することができます。たとえば、重複するユーザ名 (sipuser@oracle.com と sipuser@oracle.com など) を個別のものとして扱う必要がある場合、カスタム ユーザ名マッパーを使用してヘッダの情報を処理し、一意のユーザ名 (sipsuser_b と sipuser_c) を生成することができます。カスタム ユーザ名マッパーを使用すると、@ 文字を含む WebLogic ユーザ名 (@oracle.com など) をサポートすることもできます。
SIP サーブレットで X-3GPP-Asserted-Identity ヘッダによる認証をサポートするには、web.xml デプロイメント記述子の auth-method 要素を CLIENT-CERT に設定する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
HTTP リクエストの X-3GPP-Asserted-Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、以下の手順に従います。節 5.10「3GPP HTTP ID アサーション プロバイダのコンフィグレーション」でも触れたように、2 つのプロバイダのうち、どちらか 1 つを選択することができます。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダ名を入力し、[Type] フィールドに以下のどちらかのオプションを選択します。
[X3gppAssertedIdentityAsserter] : ヘッダが無効の場合 (または信頼できないホストから送信されたものである場合) に例外を送出しないプロバイダをコンフィグレーションします。
[X3gppAssertedIdentityStrictAsserter] : ヘッダが信頼できないホストから送信されたものである場合 (このヘッダは無視されます) に例外を送出するプロバイダをコンフィグレーションします。
詳細については、節 5.10「3GPP HTTP ID アサーション プロバイダのコンフィグレーション」を参照してください。
[OK] をクリックします。
作成した新しいプロバイダ名を選択します。
[アクティブなタイプの選択] リストで [X-3GPP-Asserted-Identity] を選択し、矢印をクリックして、このタイプを [選択済み] カラムに移動します。
[保存] をクリックします。
[コンフィグレーション｜Provider Specific] タブを選択します。
コンフィグレーション ページの各フィールドに以下の情報を入力します。
[Trusted Hosts] : プロバイダが信頼できるホストとして扱う 1 つまたは複数のホスト名を入力します。このプロバイダは、sipserver.xml ファイルに信頼できるホストとしてコンフィグレーションされているホストは使用しません (『コンフィグレーション リファレンス マニュアル』の「sip-security」を参照してください)。IP アドレスと DNS 名のどちらでも入力できます。また、ワイルドカードを使用することもできます。
[User Name Mapper Class Name] : X-3GPP-Asserted-Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするために使用するカスタム Java クラス名を入力します。カスタム ユーザ名マッパーは、通常、ユーザ名が複数のドメインから送られてきた場合に使用されます。この場合、受け取ったユーザ名をマップするために、ドメインごとに別のロジックが必要とされることもあります。ユーザ名を WebLogic ユーザ名にマップする場合、または X-3GPP-Asserted-Identity ヘッダに指定されているユーザ名のうち最初のユーザ名だけを使用するのではなく、複数のユーザ名を論理的に処理する場合は、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
このフィールドを空白のままにすると、デフォルトのユーザ名マッパーが使われます。デフォルトのユーザ名マッパーでは、ドメイン名を取り除き、残った最初のユーザ名を ID のアサーションに使用します。たとえば、デフォルトのユーザ名マッパーは以下のヘッダ
X-3GPP-Asserted-Identity: "user1@oracle.com", "user2@oracle.com"
を処理し、ID "user1" をアサートします。
[保存] をクリックします。
SIP サーブレットでは基本認証の使用が非推奨となりましたが、HTTP サーブレットではこの認証メカニズムを使用することができます。基本認証は LDAPAuthenticator プロバイダを通じてサポートされます。Oracle Internet Directory でプロバイダをコンフィグレーションするには、以下の手順に従います。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。
コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)
[プロバイダ｜認証] タブを選択します。
[新規] をクリックします。
新しいプロバイダ名を入力し、タイプ フィールドで [LDAPAuthenticator] を選択します。
[OK] をクリックします。
作成した新しいプロバイダ名を選択します。
[コンフィグレーション｜Provider Specific] タブを選択します。
コンフィグレーション ページの各フィールドに以下の情報を入力します。
[Principal] : Oracle Internet Directory で Oracle WebLogic Communication Services 用にコンフィグレーションされたアプリケーション インスタンスを入力します (たとえば、orclApplicationCommonName=WLSSInstance1,cn=WLSS,cn=Products,cn=OracleContext,dc=example,dc=com)。このインスタンスは、Oracle Internet Directory をインストールした後に手動でプロビジョニングする必要があります。手順の詳細については、節 5.12「Oracle Internet Directory でのリソースのプロビジョニング」を参照してください。
[Credential] : Oracle Internet Directory でコンフィグレーションされた [Principal] のパスワードを入力します。
[Group Base DN] : Oracle Internet Directory のグループ オブジェクトの DN を入力します (たとえば、cn=groups,dc=example,dc=com)。
[User Base DN] : Oracle Internet Directory のユーザ オブジェクトの DN を入力します (たとえば、cn=Users,dc=example,dc=com)。
[保存] をクリックします。
以下の節では、Oracle Internet Directory を LPAD プロバイダとして使用するときに、Oracle WebLogic Communication Services のリソースをプロビジョニングする方法の概要について説明します。これらの手順は、ダイジェスト認証で計算済みのハッシュ値を使用する場合、または HTTP サーブレット用の基本認証をコンフィグレーションする場合に必須です。
これらの手順の詳細については、Oracle Internet Directory の『Oracle Fusion Middleware Administrator's Guide』を参照してください。
OID LDAP バックエンドの次のマッピングをコンフィグレーションする必要があります。
[JAAS Usernames to LDAP User Entries] -- Java Authentication and Authorization Service (JAAS) ユーザ名は、ノード cn=Common,cn=Products,cn=OracleContext の下の orclcommonnicknameattribute の値を基にして、LDAP ユーザにマッピングされます。たとえば、この属性を uid に設定すると、OID に対して認証を実行するユーザは、認証時に対応する LDAP uid をユーザ名として提供する必要があることを示します。この章で説明している残りのコンフィグレーションでは、orclcommonnicknameattribute が uid (デフォルト値) に設定されていることを前提としています。
[JAAS Realms to LDAP Subscribers] -- JAAS レルムは、OID デプロイメント用の cn=Common,cn=Products,cn=OracleContext ノードのルートの下の orclsubscribernicknameattribute に提供された値を基にして、LDAP レルム エントリにマッピングされます。たとえば、OID デプロイメント用の orclsubscribernicknameattribute の値を o (アルファベットの「o」) に設定すると、OID に対して認証を実行するユーザは o 属性の値によって識別された JAAS レルムに属している必要があることを示します。orclsubscribernicknameattribute の値を o に設定します。
[JAAS Roles to LDAP Groups] -- グループ メンバシップによって特定のユーザの JAAS ロールが決定されます。LDAP グループから JAAS ロールへのマッピングは、プロビジョニングされた各 LDAP レルムのノード cn=Common,cn=Products,cn=OracleContext の下の orclcommonnamingattribute に提供された値に基づいています。たとえば、ユーザが属する LDAP グループの識別名が cn=Location Service, cn=groups, dc=example, dc=com であり、orclcommonnamingattribute が cn に設定されている場合、その JAAS ユーザは「Location Service」JAAS ロールに設定されます。orclcommonnamingattribute の値を cn に設定します。
上の手順で Oracle Internet Directory をコンフィグレーションした後は、Oracle WebLogic Communication Services (OWLCS) 用の新製品エントリの作成、静的検証機能のインストール、OWLCS の各インスタンス用のエントリの作成、および新しく作成された各インスタンスへの検証権限の付与を実行する必要があります。これらの手順は OID でユーザをプロビジョニングする前に実行する必要があります。すでに OID にユーザが存在する場合は、静的検証機能を作成およびコンフィグレーションした後で、これらのユーザが正しくログインできるようにパスワードをリセットする必要があります。
Oracle Internet Directory に Oracle WebLogic Communication Services 製品を追加するには、以下の手順に従います。
$ORACLE_HOME/bin/ で oidadmin ツールを起動し、インストールされた Oracle Internet Directory サーバに接続します。Oracle Internet Directory のインストール中に選択した「orcladmin」アカウントとパスワードを使用してログインします。
[Entry Management] ツリーで、
cn=Products,cn=OracleContext,dc=example,dc=com を検索します。正確なドメイン部分 (dc=example,dc=com) は、Oracle Internet Directory のインストールで作成したドメインに依存します。
OWLCS の新しいエントリを作成する便利な方法は、既存の製品エントリをクローンすることです。[Products] の下の最初のエントリを選択します (通常は [Calendar] エントリ)。次に、[Calendar] エントリを右クリックして [Create Like] を選択します。結果のダイアログで、以下の手順に従います。
dn の [Calendar] エントリを WLCS と置き換えます。
cn に WLCS と入力します。
[OK] をクリックします。
[Products] エントリを右クリックし、[Refresh SubTree Entries] を選択します。[Products] の下に新しい製品名 WLCS が表示されていることを確認してください。
静的検証機能をインストールするには、ldapadd コマンドライン ツールを使用します。以下の手順を実行します。
環境変数 ORACLE_HOME を、OID がインストールされた ORACLE_HOME を指すように設定します。
以下の行を含む ldif ファイルを作成します (ここでも、ドメインの部分をユーザのドメインと置き換えます)。
dn: cn=WLCSVerifierProfileEntry,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com
objectclass:top
objectclass:orclpwdverifierprofile
cn:WLCSVerifierProfileEntry
orclappid:wlcs
orclpwdverifierparams;authpassword: crypto:SASL/MD5 $ realm:example.com $ usernameattribute:uid
cd $ORACLE_HOME
次のコマンドを実行します。/bin/ldapadd -D cn=orcladmin -w <password of orcladmin user> -f <yourfile>.ldif
oidadmin で、WLCS 製品エントリを右クリックし、[Refresh SubTree Entries] を選択して、WLCS 製品エントリを更新します。WLCSVerifierProfileEntry が表示されます。
新しい Oracle WebLogic Communication Services インスタンスを追加するには、以下の手順に従います。
作成した WLCS 製品エントリを右クリックし、[作成] を選択します。
[Distinguished Name (dn)] フィールドで、以下のように入力します。
orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com" (ドメインの部分をユーザのドメインと置き換えます)
[Object Classes] で、[Add] をクリックします。
[orclApplicationEntity] を選択します。[Select] をクリックします。
[Optional Properties] をクリックし、以下の属性の値を設定します。
userpassword (authpassword ではない) - 任意のパスワードを入力します
orclappfullname - 「Oracle Weblogic Communication Services」と入力します
description - 「Oracle Weblogic Communication Services インスタンスのエントリ」と入力します
[OK] をクリックします。
エントリを右クリックし、[Refresh SubTree Entries] を選択して、WLCS 製品エントリを更新します。作成した新しいエントリが表示されていることを確認してください。
Oracle WebLogic Communication Services インスタンスに検証権限を付与するには、以下の手順に従います。
cn=verifierServices,cn=Groups,cn=OracleContext,dc=example,dc=com エントリに移動します (ドメインの部分をユーザのドメインと置き換えます)。
[cn=verifierServices] をクリックします。
右ペインで、uniquemember 属性まで下にスクロールします。属性の値に 1 つまたは 2 つのエントリがある場合があります。uniquemember 属性の既存の値に「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」を追加します (ドメインの部分をユーザのドメインと置き換えます)。
[適用] をクリックします。
上の 2 つの手順を各 OWLCS インスタンスで繰り返します。
OID と通信する必要がある OWLCS の各インスタンスで、上の 2 つの手順を繰り返す必要があります (新しい OWLCS インスタンスの追加とインスタンスへの検証権限の付与)。
ユーザをプロビジョニングするには、以下の手順に従って、ユーザの作成、ユーザの必須属性の設定、グループの作成、および新しいユーザのグループ メンバーとしての割り当てを行う必要があります。
oiddas を通じてユーザを管理するには、OID のマニュアルを参照してください。
また、テスト ユーザをすばやく作成する必要がある場合は、oidadmin を使用して、次のように orcladmin ユーザをクローンできます。# cn=Users,dc=example,dc=com に移動します (ドメインの部分をユーザのドメインと置き換えます)。
[cn=orcladmin] を右クリックし、[Create Like] を選択します。
結果のダイアログで、以下の手順に従います。
識別名の属性値の orcladmin を 「test.user1」に変更します。
cn に test.user1 と入力します
sn に test.user1 と入力します
[Optional Properties] タブをクリックします。
givenName に test.user1 と入力します
mail に test.user1@example.com と入力します (この電子メール アドレスはユーザの SIP アドレスとなるため、username@your-domain の形式で入力してください)
description を「OWLCS のテスト ユーザ」に変更します
orclSAMAccountName を test.user1 に変更します
uid に test.user1 と入力します
このテスト ユーザの任意のパスワードを入力します
orclIsVisible プロパティに true と入力します (重要)
[OK] をクリックします。
ProxyRegistrar を実行するには、すべてのユーザが「Location Service」グループのメンバである必要があります。そのグループを作成するには、以下の手順に従います。
OIDDAS Web インタフェースを通してグループを追加およびグループへメンバを追加するのが最も簡単な方法です。グループを作成する方法については、OID のドキュメントを参照してください。また、oidadmin ツールを使用して、既存のグループのクローンによって新しいグループを作成できます。以下の手順に従います。
[Entry Management] ツリーで、cn=Groups,dc=example,dc=com を検索します (ドメインの部分をユーザのドメインと置き換えます)
既存のグループ (「OCS_Portal_Users」など) を右クリックし、[Create Like] を選択します。
識別名 (dn) を cn=Location Service,cn=Groups,dc=example,dc=com に設定します (OCS_Portal_Users を Location Service に変更します)
cn に Location Service と入力します。
[Optional Properties] をクリックします。
description に「OWLCS の Location Service ロール」と入力します。
displayName に Location Service と入力します。
[OK] をクリックします。
[cn=Groups] をクリックし、[Refresh SubTree Entries] を選択します。新しいグループが表示されていることを確認してください。
前に述べたとおり、ProxyRegistrar を実行するには、すべての OWLCS ユーザが上で作成した「Location Service」グループのメンバである必要があります。新しい Location Service グループにユーザを追加するには、以下の手順に従います。
作成した新しい Location Service をクリックします。新しいグループは、[Entry Management] ツリーの cn=Location Service,cn=Groups,dc=example,dc=com にあります (ドメインの部分をユーザのドメインと置き換えます)
右ペインで、uniquemember 属性まで下にスクロールして、任意の既存のエントリに cn=test.user1,cn=Users,dc=example,dc=com を追加します (ドメインの部分をユーザのドメインと置き換えます)。
[適用] をクリックします。
OID のサポートで LDAPIdentityAssertionProvider を追加します。
WLS 管理コンソールで、ユーザのセキュリティ レルムに移動して [プロバイダ] タブをクリックします。
DigestIdentityAsserter がプロバイダのリストにある場合は、これを削除して OWLCS サーバを再起動します (これは用意されている OWLCS のインストールで、デフォルトで作成されます)。
サーバを再起動したら、WLS 管理コンソールで [プロバイダ] タブをクリックします。
[新規] ボタンをクリックし、[種類] ドロップ ダウンから [LDAPDigestAssertionProvider] を選択して、新しい LDAP ダイジェスト ID アサーション プロバイダを追加します。名前に LDAPDigestAssertionProvider と入力します。[OK] をクリックします。
[プロバイダ固有] タブをクリックします。
[UserBaseDN] を「cn=Users,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。
[CredentialAttributeName] を [authpassword;wlcs] に設定します。
[PaswordEncryptionType] を [PRECALCULATEDHASH] に設定します。
[DigestRealmName] を「example.com」に設定します (これは、静的検証機能をインストールするときに使用した ldif ファイル内のレルム値と一致します)。
[Host] と [Port] を OID サーバと同じように設定します。
[Principal] を「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。
[Credential] を上でコンフィグレーションしたインスタンスの userPassword に設定します。認証を確認します。
[OIDSupportEnabled] チェックボックスにチェックを入れ、[保存] をクリックします。
手順 1 で説明されている [プロバイダ] タブに戻ります。DefaultAuthenticator エントリがある場合はこれをクリックし、[制御フラグ] を [SUFFICIENT] に設定して [保存] をクリックします。
LDAPAuthenticator を追加するには、以下の手順に従います。
WLS 管理コンソールで、ユーザのセキュリティ レルムに移動し、[プロバイダ] タブで新しい LDAPAuthenticator を追加します。
[共通] タブで、[制御フラグ] を [SUFFICIENT] に変更します。
[プロバイダ固有] タブをクリックします。
OID サーバのホストとポートを設定します。
[プリンシパル] を「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。
[資格] を前の手順と同じようにコンフィグレーションし、[資格の確認] を設定します。
[ユーザ ベース DN] を「cn=Users,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。
[取得したユーザ名をプリンシパルとして使用する] を有効にします。
[グループ ベース DN] を「cn=Groups,example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。
[保存] をクリックします。
LDAP 認証のパフォーマンスを向上させることができます。
ユーザがフラット構造の場合 (通常はこのケース)、[User Search Scope] を [onelevel] に設定します。
ロールのグループのフラット構造の場合 (こちらも通常のケース)、つまり、グループ内にグループがない場合、[Group Search Scope] を [onelevel] に設定し、[Group Membership Searching] を [limited] に設定します。
変更を保存してください。
OID で使用する Userservice をコンフィグレーションする必要があります。
subscriberdataservices ear ファイル ($MW_HOME/as11gr1wlcs1/communications/applications にある subscriberdataservices-11.1.1.1.0.ear) にパッケージされた ejb-jar.xml を、jdbc の代わりに LDAP を使用するようコンフィグレーションする必要があります。
userservice jar 内のファイルに続けて、subscriberdataservices ear 内のファイルを展開します。
META-INF の下の ejb-jar.xml で、UserServiceDSN と UserDAOImpl グループをコメント アウトします。LDAP セクションのコメントを解除し、適切な値でコンフィグレーションします。
java.naming.security.principal を orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com に設定します (ドメインの部分をユーザのドメインと置き換えます)
前に定義したパスワードを設定します。プレーン テキスト パスワードの先頭に「!」を追加します。たとえば、パスワードを myPassword に設定する場合、<env-entry-value><![CDATA[!myPassword]]></env-entry-value> とコンフィグレーションします。
プロバイダ LDAP URL を設定します。デフォルトのポートは 389 です (非 SSL 接続)。
上の変更を加えた ejb-jar.xml ファイルを保存し、ear ファイルの後に jar ファイルを再パッケージします。$MW_HOME/as11gr1wlcs1/communications/applications の下の既存の subscriberdataservices ear ファイルを、変更したファイルと置き換えます。
OWLCS を再起動します。これで Oracle Communicator を使用して OWLCS に test.user1 としてサインインできます。
