| Oracle Application Serverリリース・ノート 10g（10.1.4.0.1） for Linux x86 B31483-05 |
|
 戻る |
 次へ |
この章では、Oracle Identity Federationに関連する問題について説明します。内容は次のとおりです。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
このリリースからは、資格証明を入力してSiteMinderで保護されているリソースにアクセスした後、Oracle Identity Federationでサポートされているプロトコルを使用して同じブラウザでシングル・サインオンを実行しようとすると、ユーザーは再び資格証明を入力するように要求されます。
この問題は、Oracle Identity Federationがサービス・プロバイダとして使用され、OracleAS Single Sign-Onがユーザー・データ・ストアであり、SAML 1.xまたはWS-Federationを使用してフェデレーテッド・ユーザーにOracleAS Single Sign-Onセッションが作成されている場合に関連します。そのセッションが期限切れになると、サービス・プロバイダのOracle Identity Federationサーバーは、SAML 2.0を使用してセッションの再認証を試行します。サービス・プロバイダおよびアイデンティティ・プロバイダ上でSAML 2.0が有効になっていない場合、通常は「500 内部サーバー・エラー」で再認証が失敗します。
この問題を回避するには、OracleAS Single Sign-Onを構成します。ORACLE_HOME/sso/conf/policy.propertiesファイルを開き、デフォルトのSSOサーバー認証プラグインを持つすべてのパートナ・アプリケーションを保護します。SASSO認証プラグインのセキュリティ・レベルを、OracleAS Single Sign-Onサーバー・プラグインのセキュリティ・レベルより高くなるように構成します。
この構成では、SAML 1.xまたはWS-Federationプロトコルによって認証されたユーザーがOracleAS Single Sign-Onで保護されているリソースにアクセスした場合、セッションがタイムアウトになると、そのユーザーはローカル認証のためにOracleAS Single Sign-Onサーバーにリダイレクトされます。Oracle Identity Federationでエラーが発生したり、間違ったIdPが表示されることはありません。
Oracle Access Manager WebGateエージェントがインストールされている場合、Microsoft Internet Information Servers（IIS）で属性共有機能を使用することはできません。この機能では、認証プラグインがクライアントのX.509証明書からSubjectDNを持つHTTPヘッダーを設定し、認可プラグインがそのヘッダーを取得してSAML属性問合せを開始します。しかし、IIS WebGateがSSLクライアント証明書の認証を実行する方法が原因で、認可プラグインはSubjectDNヘッダーを取得できません。この場合、ユーザーのブラウザで次のエラーが報告されます。
Oracle Access Managerの操作エラー: ユーザー<OblixAnonymous user DN>に対してURL <targetURL>へのアクセスが拒否されました。
また、次のエラー・メッセージがOBACCESS_INSTALL/access/oblix/config/logs/authz_attribute_plugin_log.txtファイルに書き込まれます。
SubjectDNヘッダーObNullString
および
SubjectDNがありません。ローカル・ユーザーを使用し、「続行」を押してください
Oracle Identity FederationがOracle Access Managerユーザー・データ・ストアとともにアイデンティティ・プロバイダとして使用されている場合、ユーザーが新しくSAML 1.xまたはWS-Federationシングル・サインオンを開始すると、ブラウザでリダイレクション・ループが発生することがあります。
これは、Oracle Identity Federation用に構成されているOracle Access Manager AccessGateのアイドル・セッション・タイムアウトが最大ユーザー・セッション時間よりも少ない場合に発生します。この場合、ユーザーがアイドル・セッションのタイムアウトが経過するのを待ってから別のSSOを開始すると、リダイレクション・ループが発生します。
これを回避するには、Oracle Identity Federation AccessGateのアイドル・セッション・タイムアウトを最大ユーザー・セッション・タイムアウト以上（デフォルト設定）に設定します。
日本語のインストール・セッション中、次の問題が発生します。
Oracle Universal Installerを起動します。
Oracle Identity Federation 10gインストール・オプションを選択します。
「インストール方法の選択」ページに進みます。
最初のラジオ・ボタン（「基本」）を説明するテキストが切り捨てられます。
Oracle Identity FederationがLDAPまたはRDBMSユーザー・データ・ストアとともにアイデンティティ・プロバイダとして使用されている場合、存在しないユーザー属性を使用して構成されたSAML 1.xアサーション・プロファイルによって、SAML 1.xおよびWS-Federationプロファイルを使用するすべてのシングル・サインオン（SSO）は失敗します。無効なプロファイルが使用されていなくても同じです。
LDAPまたはRDBMSユーザー・データ・ストアを使用するOracle Identity Federationアイデンティティ・プロバイダにユーザーがログインすると、Oracle Identity Federationはすべての構成済アサーション・プロファイル内のすべてのユーザー属性を取得しようとします。これらの属性のいずれかが無効である場合、SSOは失敗します。
RDBMSデータ・ストアを使用している場合、ユーザーは「500 内部サーバー・エラー」を受け取ります。デバッグ・ロギングが有効になっている場合は、federation.logファイルに次のエラーが示されます。
RDBMSBridge.authenticate(): エラー - JDBCによってスローされたSQL例外: java.sql.SQLException: ORA-00904: "<attribute name>": 無効な識別子
LDAPデータ・ストアを使用している場合、ユーザーはID TSE007のIdentity Federationエラーを受け取り、federation.logファイルに次のエラーが示されます。
レスポンダ: エラー、<userDN>のユーザー・ディレクトリは<assertion attribute>属性<user attribute>を持っていません。（RSE027）
回避方法は、原因となっているアサーション・プロファイル内の無効なユーザー属性を訂正するか、原因となっているアサーション・プロセスを削除することです。
SAML 1.0ではXML署名標準の使用方法が完全には指定されていないため、SAMLレスポンスのコンテキスト内では、Oracle Identity Federationは署名付きSAML 1.0アサーションを適切に生成することも、受け取った署名付きSAML 1.0アサーションを検証することもできません。このため、ArtifactプロファイルおよびPOST SSOプロファイルに使用されるSAML 1.0アサーションの署名は正しくありません。SAML 1.1がMyDomainでも宛先ドメインでも有効になっていない場合、アサーション署名が有効になったSAML 1.xアサーション・プロファイルを使用してシングル・サインオン（SSO）を実行しようとすると、サービス・プロバイダまたは宛先サイトはSSOアサーションの署名を検証できず、SSOが失敗することがあります。宛先サイトがOracle Identity Federationを使用している場合、federation.logファイルに次のメッセージが示されます。
受信者: エラー: 無効なSAMLレスポンスが受信されました: XML署名者: エラー: 署名が無効か、内容が変更されています
回避方法は、SAML 1.0ではなくSAML 1.1プロトコルを使用することです。（実際、SAML 1.1が改訂された理由の1つは、XML署名の使用方法を改善することにありました。）
|
注意: SAML 1.x SSOプロファイルでは、署名付きアサーションは必須でなく、一般には使用されていません。 |
デフォルトでは、JDBCはOracle Identity FederationとOracle9i Database Serverの間のネットワーク接続を暗号化しません。オプションで、サイトはOracle Advanced Securityを使用してこれらの接続を暗号化できます。
Oracle Internet Directoryまたはその他のLDAPサーバーを使用してユーザーを認証するようにOracle Identity Federationを構成する場合、サイトはSSLを使用してLDAPサーバーに接続するかどうかを選択できます。SSLを使用しない場合、Oracle Identity FederationとLDAPサーバーの間のネットワーク接続を介して、暗号化されていないパスワードを送信できます。
サード・パーティの認証局で発行された署名証明書が、Oracle Identity FederationのSAML 1.xまたはWS-Federation部分のキーストアにインストールされており、デバッグ・ロギングが有効になっていると、次のようにエラーが誤って報告されます。
XML SIGNATURE: cert verify check: FAILED - java.security.SignatureException: Signature does not match.
実行される証明書検証は自己署名証明書のみに対応します。このエラーはOracle Identity Federationの処理には影響しません。このログ・メッセージは無視することができます。
OracleAS Single Sign-Onと統合した場合、Oracle Identity Federationでは資格証明をユーザーに再要求する機能がサポートされません。したがって、Oracle Identity Federationでは、再認証を実行する必要があるユースケースをサポートできません。
たとえば、SPがForceAuthn="true"が指定されたAuthnRequestをOracle Identity Federation IdPに送信し、Oracle Identity FederationがOracleAS Single Sign-Onと統合している場合、ForceAuthnフラグは無視されます。
この項では、構成の問題および回避方法について説明します。内容は次のとおりです。
次のような場合、Oracle Identity Federation管理コンソールにアクセスできないことがあります。
一時データ・ストア用のRDBMSデータベースを変更するために、コマンドライン・コンフィギュレーション・アシスタントが実行されています。コマンドの書式は次のとおりです。
java -jar install.jar -transient rdbms <parameters>
コマンドの実行後、Oracle Identity Federation管理コンソールがアクセス不能になり、フェデレーション・ログまたはOPMNログに次のようなエラーが示されます。
ユーザー名またはパスワードが正しくありません。
この問題は、ユーザー名とパスワードの組合せを変えて使用して、Oracle Identity Federation一時ストアのデータベースを別のデータベースに切り替えた場合、または同じデータベースを別の資格証明で使用した場合に発生します。
この問題の原因は、RDBMS一時データ・ストア用にOracle Identity Federationがすでに設定されているにもかかわらず、コマンドライン・コンフィギュレーション・アシスタントの実行時にデータベース・パスワードがリセットされていないために、Oracle Identity Federation操作を実行しようとすると無効なユーザー名とパスワードのエラーが発生することにあります。
この問題を回避するには、次の手順を実行します。
Oracle Enterprise Manager 10g Grid Controlコンソールにログオンします。
「OC4J_FED」→「管理」→「セキュリティ」へナビゲートします。
「ユーザー」リストでjazn.com/oif_dbエントリをクリックします。
適切なパスワードを入力してRDBMSにアクセスします。
OC4J_FEDインスタンスを適用し、再起動します。
レスポンス・メッセージとアサーションの両方を署名付きで送信するようにOracle Identity Federation IdPが構成されている場合は、アサーションのみが署名されます。
これによって、Liberty 1.xおよびSAML 2.0プロトコルに対するプロファイルを共有するSSOおよび属性が影響を受けます。レスポンス・メッセージにアサーションが含まれていないプロファイルは、この影響を受けません。
日本語ロケールにおいては、SAML 1.x POSTメソッドを使用するアサーションは次のエラーで失敗します。
受信者: エラー: SAMLレスポンスが、予想された権限により署名されませんでした（RVE013）
この問題の原因は、署名証明書サブジェクトDNおよび署名証明書発行者DN内のOUおよびSTに対応する文字列が変換されることにあります。
この問題の回避方法として、OUおよびSTの値を同等の英語文字列で置換する必要があります。英語の文字列の値は、MyDomain構成内の発行者DNおよびサブジェクトDNから取得できます。
『Oracle Identity Federation管理者ガイド』のOracleデータベースをユーザー・データ・ストア用のリポジトリとして使用する手順（5.4.2.1項「ユーザー・データ・ストアとしてのRDBMSの構成」）では、データベース表にCHAR型の「ログイン」ID列が存在する場合に必要な追加手順は省略されています。Oracle RDBMS内でCHARデータに対して適用される自動パディング（VARCHAR2データに対しては行われない）を構成するには、これらの手順が必要です。
「ログイン」ID列がCHAR型のとき、Oracleデータベース表に対するデータソースを作成するには、次の手順を実行します。
Oracle Identity FederationインスタンスのEnterprise Managerコンソールにログインし、「OC4J_FED」→「管理」→「データソース」へナビゲートします。
次の例を参考にして、新しいデータソースを作成します。
Name: myDS Data Source Class: oracle.jdbc.pool.OracleDataSource JDBC URL: jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL JDBC Driver: oracle.jdbc.driver.OracleDriver Username: CUSTDATA Password: PASSWORD Location: jdbc/RDBMSUserDataSource
変更を適用します。
OC4J_FEDインスタンスを再起動します。
|
注意: 「トランザクション(XA)ロケーション」フィールドおよび「EJBロケーション」フィールドには何も入力しないでください。 |
管理コンソール（「サーバー構成」→「トラスト・サークル」ページおよび「Identity Federation」→「信頼できるプロバイダ」ページ）では、次の3種類のエンティティのみが表示されます。
アイデンティティ・プロバイダ
サービス・プロバイダ
アフィリエーション
プロバイダのSAML 2.0メタデータにSPSSODescriptor、IdPSSODescriptorまたはAffiliationDescriptorが含まれない場合、メタデータはこれら3つのどの種類にも分類されません。
たとえば、ピア・プロバイダのメタデータにAttributeAuthorityDescriptorしか含まれない場合は、ロードしても「トラスト・サークル」ページに表示されません。ただし、このようなプロバイダも、メタデータでパブリッシュしたプロトコルがサポートされるかぎり、実行時には正常に機能します。
AttributeRequesterDescriptor要素を含むSAML 2.0メタデータがロードされると、XML解析エラーが発生します。
この結果、管理コンソールに「500 内部サーバー・エラー」が表示されます。
この問題の回避方法はありません。
管理コンソールでプロトコル・プロファイルを無効にしても（たとえば、「サーバー構成」→「アイデンティティ・プロバイダ」→「SAML 2.0」→「プロトコル・プロファイルの有効化」）、生成されるメタデータでどのプロファイルをパブリッシュするかが制御されるだけです。実行時には、これらのプロファイルに対するリクエストは通常どおりに処理されます。
この問題の回避方法はありません。
ピア・プロバイダに対してロードされたメタデータに、問合せパラメータを含むサービスURL（たとえばAssertionConsumerService）が含まれる場合、プロトコル・プロファイルの実行時に、Oracle Identity FederationはそのURLに正しくリダイレクトできません。
この項では、ドキュメントの訂正箇所を示します。内容は次のとおりです。
Oracle Identity Federationのオンライン・ヘルプ・ページのタイトル「Web 2.0 BetaのOracleヘルプ」は間違っています。正しいタイトルは、管理コンソールの場合は「Oracle Identity Federation管理ヘルプ」で、監視コンソールの場合は「Oracle Identity Federation監視ヘルプ」です。
この注意書きは、『Oracle Identity Federation管理者ガイド』の次の項に関連しています。
8.2.2項「一時データ・ストアを変更するためのコマンドライン・コンフィギュレーション・アシスタント」
8.2.3項「アンインストール用のコマンドライン・コンフィギュレーション・アシスタント」
ドキュメントでは、これらのコンフィギュレーション・アシスタントがコマンドラインでパラメータとしてパスワードをとると説明されています。この方法は安全でないので、実施しないでください。
これらのツールではいずれも、コマンドラインにLDAPおよびRDBMSパスワードが入力されていない場合、ユーザーにLDAPまたはRDBMSパスワード（あるいはその両方）を入力するように要求されます。たとえば、uninstallツールは次のようなパラメータを使用して実行できます。
jdk/bin/java -jar fed/lib/uninstall.jar -uninstall -oh $ORACLE_HOME -removefed true -ldap false -ldaptype oid -ldapurl ldap://my.ldap.com -ldapusername USERNAME -db false
この場合、次のメッセージが表示され、LDAPパスワードを入力するように要求されます。
Parsing parameters Verifying parameters Enter password for LDAP Username "USERNAME":
一時データ・ストアの変更（ドキュメントの8.2.2.1項）を行う場合、コマンドライン・コンフィギュレーション・アシスタントの次のパラメータは必要ありませんので注意してください。
-dbpwd <PASSWORD>: これはRDBMSパスワードです。RDBMSが一時データ・ストア用に使用されている場合にのみ必要です。
アンインストール（ドキュメントの8.2.3.1項）を行う場合、コマンドライン・コンフィギュレーション・アシスタントの次のパラメータは必要ありません。
-ldappwd: これはLDAPユーザーのパスワードです。
-dbpwd password: RDBMSパスワード。dbがtrueの場合にのみ必要です。
どちらのツールでも、ユーザーはコマンドラインでパスワードを指定できますが、この方法はお薦めできません。コマンドラインでパラメータとしてパスワードを渡すと、警告メッセージが表示されます。
|
注意: コマンドラインでパスワードを入力することは安全ではありません。このユーティリティの安全な使用方法については、最新の製品ドキュメントを参照してください。 |
Oracle Identity Federationの今後のリリースでは、コマンドラインでパスワードは入力できなくなり、パスワードのプロンプトのみ表示されるようになります。
『Oracle Identity Federation管理者ガイド』の「アイデンティティ・プロバイダ: グローバル設定」および「サービス・プロバイダ: グローバル設定」の項に、共通ドメインCookieを使用したIdP検出プロファイルのアイデンティティ・プロバイダ（IdP）またはサービス・プロバイダ（SP）の構成方法に関する説明が記載されています。
リリース10.1.4.0.1のドキュメント（部品番号: B25355-01）では、次の項で説明されています。
5.3.3.1項「アイデンティティ・プロバイダ: グローバル設定」
5.3.3.4項「サービス・プロバイダ: グローバル設定」
ここのプロバイダの構成に関する説明は十分ではありません。次の内容に読み替えてください。
5.3.3.1項「アイデンティティ・プロバイダ: グローバル設定」
...
共通ドメインURL
トラスト・サークル内のプロバイダがIdP導入Cookieの共通ドメインについて合意済みの場合、サークルに加入している各アイデンティティ・プロバイダに対して、共通ドメインでCookie書込みサービスがホストされる必要があります。
Oracle Identity FederationのIdPはこのサービスをfed/idp/introパスで実行します。HTTPサーバーは共通ドメインのホスト:ポートをリスニングするよう構成されている必要があります。これを実行すると、共通ドメインURLを構成できます。
たとえば、合意済みの共通ドメインが.cdc.example.orgで、Oracle Identity FederationのIdPがidp.mycorp.comでホストされている場合、IdPのHTTPサーバーはmycorpidp.cdc.example.org:7778でリスニングするよう構成できます。IdPのCookie書込みサービスの共通ドメインURLは次のようになります。
http://mycorpidp.cdc.example.org:7778/fed/idp/intro
この値は、「共通ドメイン有効」を選択した場合のみ設定します。
5.3.3.4項「サービス・プロバイダ: グローバル設定」
...
共通ドメイン有効
アイデンティティ・フェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれている場合、サービス・プロバイダは、プリンシパルが使用するアイデンティティ・プロバイダを決定する方法を必要とします。これを実現するには、フェデレーション・ネットワーク内のすべてのIdPとSPがCookieドメインについて合意し、このドメインで書かれたCookieをユーザーのブラウザに送信します。このCookieにはユーザーがログインしているすべてのIdPのリストが含まれます。このようなドメインは共通ドメインと呼ばれ、IdPを識別するCookieは共通ドメインCookieまたはIdP導入Cookieと呼ばれます。
「共通ドメイン有効」を選択すると、このSPは導入Cookieを読み取り、認証に使用するIdPを検出するように指定されます。
共通ドメインURL
トラスト・サークル内のプロバイダがIdP導入Cookieの共通ドメインについて合意済みの場合、サークルに加入している各サービス・プロバイダに対して、共通ドメインでCookie読込みサービスがホストされる必要があります。
Oracle Identity FederationのSPはこのサービスを/fed/sp/introssoパスで実行します。HTTPサーバーは共通ドメインのホスト:ポートをリスニングするよう構成されている必要があります。これを実行すると、共通ドメインURLを構成できます。
たとえば、合意済みの共通ドメインが.cdc.example.orgで、Oracle Identity FederationのSPがsp.mycorp.comでホストされている場合、SPのHTTPサーバーはmycorpsp.cdc.example.org:7778でリスニングするよう構成できます。SPのCookie読込みサービスの共通ドメインURLは次のようになります。
http://mycorpsp.cdc.example.org:7778/fed/sp/introsso
この値は、「共通ドメイン有効」を選択した場合のみ設定します。
