|
|
以下の節では、Oracle Communications Converged Application Server の Id アサーション プロバイダをコンフィグレーションおよび使用する方法について説明します。
次のいずれかの ID アサーション メカニズムを使用するように SIP サーブレットをコンフィグレーションできます。
選択した Id アサーション メカニズムは sip.xml デプロイメント記述子の identity-assertion 要素に定義されています。identity-assertion-support 要素は、サーブレットに対して Id アサーションメカニズムが必要か、必要なヘッダがふくまれていない SIP メッセージに対して使用できる他の認証メカニズムが必要かを決定する。サーブレットの Id アサーションのコンフィグレーションについては、SIP サーブレット仕様 v1.1 を参照してください。
Oracle Communications Converged Application Server はセキュリティ プロバイダを使用して、Id アサーション メカニズムをサポートする。以下の節では、Oracle Communications Converged Application Server は各 ID アサーション メカニズムでメッセージを処理する方法および必要なセキュリティ プロバイダを設定する方法の詳細について説明します。
| 注意 : | Oracle Communications Converged Application Server のバージョンは SIP サーブレット v1.0 仕様に準拠しているアプリケーション用の下位互換性を提供します。P-Asserted-Identity ヘッダを持つすべての v1.0 SIP サーブレットについては、コンテナは SIP サーバ バージョン 3.1 ドキュメントの
P-Asserted-Identity アサーションのコンフィグレーションに説明された Id アサーション プロセスを使用します。 |
P-Asserted-Identity ヘッダは信頼できるドメイン内でのみ処理されます。Oracle Communications Converged Application Server システムでは、信頼できるドメインは純粋にコンフィグレーション ベースで判断されます。このヘッダの使用を有効にするには、「P-Asserted-Identity アサーション プロバイダのコンフィグレーション」で説明するように、2 つのうちどちらか 1 つの P-Asserted Identity アサーション プロバイダをコンフィグレーションする必要があります。P-Asserted-Identity アサーション プロバイダは、P-Asserted-Identity ヘッダの信頼できるドメインのコンフィグレーションを公開します。プロバイダが 1 つもコンフィグレーションされていない場合、ヘッダでは、信頼できる IP アドレスがないものとして扱われます。
プロバイダでコンフィグレーションされている信頼できるホストから、P-Asserted-Identity ヘッダが含まれるメッセージを受け取ると、Oracle Communications Converged Application Server はヘッダで指定されたユーザのログインを許可し、グループ メンバシップやその他の権限を判断します。P-Asserted-Identity ヘッダに含まれる値は、常に SIP アドレス (sipuser@oracle.com など) です。デフォルトでは、Oracle Communications Converged Application Server はアドレスのドメイン部分 (@oracle.com) が削除され、残りの部分がユーザ名として使用されます。重複するユーザ名 (sipuser@oracle.com と sipuser@cea.com など) を個別のものとして扱う必要がある場合、カスタム ユーザ名マッパーを作成および使用し、ヘッダの情報を処理して一意のユーザ名 (sipsuser_b と sipuser_c) を生成することができます。カスタム ユーザ名マッパーを使用すると、@ 文字を含む WebLogic ユーザ名 (@oracle.com など) をサポートすることもできます。
Privacy ヘッダと組み合わせた P-Asserted-Identity ヘッダを使用すると、Oracle Communications Converged Application Server が受信するリクエストをどのようにプロキシするかを判断できます。sip.xml の identity-assertion-support 要素の値も参考される。図 4-1 は、P-Asserted-Identity ヘッダに対する着信 SIP リクエストの管理方法について説明します。
図 4-2 に、指定されたユーザ名に権限がないため必要なリソースにアクセスできない場合の、Oracle Communications Converged Application Server を使用するセキュリティ チェックの標準的手順を示します。この標準的セキュリティ チェックは、当該アプリケーションの sip.xml 記述子の login-config 要素に定義されている auth-method に従って実行されます。
P-Asserted-Identity ヘッダまたは P-Preferred-Identity ヘッダを使用すると、発信 SIP リクエストの処理にも影響します。図 4-3 は、行動を説明します。
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 サーブレットのすべてのリソースを保護してください。『SIP アプリケーションの開発』の「SIP サーブレット リソースのセキュリティ」を参照してください。
匿名ユーザに権限が付与されなかった場合は、Oracle Communications Converged Application Server は、チャレンジによるユーザの認証が行われます。
P-Asserted-Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」で説明したように、2 つのうちどちらか 1 つのプロバイダを選択できます。
上記のプロバイダのどちらか 1 つのコンフィグレーションに加えて、第二のフォールバック的なログイン方法 (DIGEST 認証または CLIENT-CERT 認証の使用など) もコンフィグレーションしてください。
P-Asserted-Identity プロバイダをコンフィグレーションするには
P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出しないプロバイダをコンフィグレーションします。P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出するプロバイダをコンフィグレーションします。
詳細については、「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」を参照してください。
| 注意 : | このプロバイダは、sipserver.xml ファイルに信頼できるホストとしてコンフィグレーションされているホストは使用しません。(『コンフィグレーション リファレンス マニュアル』の「sip-security」を参照してください)。 |
P-Asserted-Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。カスタム ユーザ名マッパーは、通常、ユーザ名が複数のドメインから送られてきた場合に使用されます。この場合、ここのドメインから受け取ったユーザ名をマップするために追加のロジックが必要とされることもあります。P-Asserted-Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、Oracle WebLogic Server 10 g リリース 3 ドキュメントの「ロール マッピング プロバイダのコンフィグレーション」を参照してください。
このフィールドを空白のままにすると、デフォルトのユーザ名マッパーが使われます。デフォルトのユーザ名マッパーでは、ドメイン名を破棄し、残ったユーザ名をそのまま (何のロジックも適用せずに) 使用します。
Oracle Communications Converged Application Server は、RFC 4474 に記述されているようにIdentity および Identity-Info ヘッダを使用して、Id アサーションを実行することもできます。p-asserted-identity アサーション メカニズムと同様に、Identity ヘッダ アサーションには、Oracle Communications Converged Application Server の適当なセキュリティプロバイダ (IdentityHeaderAsserter プロバイダ) を最初にコンフィグレーションする必要があります。
Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストを確認すると、Oracle Communications Converged Application Server は sip.xml の identity-assertion と identity-assertion-support 要素の値およびコンフィグレーション済みのセキュリティ プロバイダの存在を検討します。図 4-4 では、このアサーション メカニズムを使用して着信メッセージを処理する方法について説明します。
Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。
IdentityHeaderAsserter] を選択します。Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、Oracle WebLogic Server 10 g リリース 3 ドキュメントの「ロール マッピング プロバイダのコンフィグレーション」を参照してください。
  
|