この付録では、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操作エラー<ターゲットURL>に対するユーザー<OblixAnonymousユーザーDN>のアクセスが拒否されました。
また、次のエラー・メッセージがOBACCESS_INSTALL/access/oblix/config/logs/authz_attribute_plugin_log.txt
ファイルに書き込まれます。
SubjectDNヘッダーObNullString
および
SubjectDNがありません。ローカル・ユーザーを使用し、続行に戻ります。
解決方法
この問題を回避するには、Oracle HTTP ServerやSun One Web Serverなどの別のWebサーバーの使用してください。
問題
Oracle Identity FederationがOracle Access Managerユーザー・データ・ストアとともにアイデンティティ・プロバイダとして使用されている場合、ユーザーが新しくSAML 1.xまたはWS-Federationシングル・サインオンを開始すると、ブラウザでリダイレクション・ループが発生する場合があります。
これは、Oracle Identity Federation用に構成されたOracle Access Managerアクセス・ゲートのアイドル・セッション・タイムアウトが最大ユーザー・セッション時間より短い場合に発生します。この場合、アイドル・セッション・タイムアウトが経過するのを待ち、別のSSOを開始すると、リダイレクション・ループが発生します。
解決方法
これを回避するには、Oracle Identity Federationアクセス・ゲートのアイドル・セッション・タイムアウトを最大ユーザー・セッション・タイムアウト以上(デフォルト設定)に設定します。
日本語のインストール・セッション中、次の問題が発生します。
Oracle Universal Installerを起動します。
Oracle Identity Federation 10gインストール・オプションを選択します。
「インストール方法の選択」ページに進みます。
最初のラジオ・ボタン(「基本」)を説明するテキストが切り捨てられます。
問題
Oracle Identity FederationがRDBMSユーザー・データ・ストアとともにアイデンティティ・プロバイダとして使用されている場合、存在しないユーザー属性を使用して構成されたSAML 1.xアサーション・プロファイルによって、SAML 1.xおよびWS-Federationプロファイルを使用するすべてのシングル・サインオン(SSO)は失敗します。無効なプロファイルが使用されていなくても同じです。
RDBMSユーザー・データ・ストアを使用するOracle Identity Federationアイデンティティ・プロバイダにユーザーがログインすると、Oracle Identity Federationはすべての構成済アサーション・プロファイル内のすべてのユーザー属性を取得しようとします。これらの属性のいずれかが無効である場合、SSOが失敗します。
ユーザーは「500 内部サーバー・エラー」
を受け取ります。デバッグ・ロギングが有効になっている場合、federation.log
ファイルに次のエラーが表示されます。
RDBMSBridge.authenticate(): エラー - SQL例外がJDBCにより返されました。: java.sql.SQL例外: ORA-00904: "<属性名>": 識別子が無効です。
解決方法
回避策は、原因となっているアサーション・プロファイル内の無効なユーザー属性を訂正するか、原因となっているアサーション・プロファイルを削除することです。
問題
SAML 1.0ではXML署名標準の使用方法が完全に指定されていないため、SAMLレスポンスのコンテキスト内では、Oracle Identity Federationは署名付きSAML 1.0アサーションを適切に生成できず、受け取った署名付きSAML 1.0アサーションの検証もできません。したがって、アーティファクト・プロファイルおよびPOST SSOプロファイルに使用されているSAML 1.0アサーションの署名は正しくありません。アサーション署名が有効なSAML 1.xアサーション・プロファイルを使用してシングル・サインオン(SSO)をするとします。SAML 1.1がMyDomainまたは宛先ドメインに対して有効になっていない場合、サービス・プロバイダ/宛先サイトは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管理コンソールにアクセスできないことがあります。
一時データ・ストアに使用されている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から取得できます。
問題
SAML 1.xアーティファクト・モードを使用していて、「ドメイン」ページのリクエスタIDにコロン(:)が含まれると、アーティファクト・プロファイルを使用したシングル・サインオンに失敗し、サービス・プロバイダ側で次のエラーが表示されます。
エラー - レスポンダ: エラー、不明なリクエスタ<ドメイン名>
この問題の原因はコロンの使用です。このコンテキストではコロンは無効です。
解決方法
各ドメインのリクエスタIDを指定する際、文字列に「:」が含まれていないことを確認します。
問題
Oracle Identity FederationログアウトURLを呼び出すと、サインオフ処理は実行されますが、サーバーは結果ページを表示せず、かわりにブラウザが最後に訪問したページを表示するため、ログアウトが成功していても、処理が中断したように見えます。
解決方法
ログアウト・サービスはreturnurl
パラメータを取ります。正常な処理のためにはこのパラメータが必須です。Oracle Identity FederationのログアウトURLを呼び出す際にreturnurl
パラメータが指定されていないと、この問題が発生します。この問題を回避するには、結果ページを示すようreturnurl
パラメータを指定します。
問題
IdPに、2つのロード・バランシングされたOracle Identity Federationインスタンスがあります。
このタイプのSAML 1.x SSOリクエストが発行されます。
http://stitiasfw2.us.oracle.com:80/shareid/saml/ObSAMLTransferService?TARGET=http://target.us.oracle.com:80/test.html&DOMAIN=some-host.us.oracle.com&METHOD=POST
有効なユーザー資格証明を使用してログインします。
次のエラーが発生します。
エラー - ローカル・ログイン: エラー: POSTリクエストにJSESSIONID Cookieがありません。
解決方法
ロード・バランシングされたプロバイダのMyDomainにあるURLと、その他のプロバイダのロード・バランシングされたドメイン内のURLが、ロード・バランサのホスト名とアドレスを持っていて、ロード・バランシングされたOracle Identity Federationインスタンスの1つのホスト名とアドレスではないことを確認します。
問題
フェデレーション・データ・ストアがLDAPサーバーにある状態で、Liberty 1.x / SAML 2.0シングル・サインオン操作を実行するとスキーマ違反エラーが発生します。$Oracle_Home/fed/log/federation.log
に次のエラー・メッセージが表示されます。
javax.naming.directory.SchemaViolationException: [LDAP: エラー・コード65 - orclfednamevalueが必須またはオプションの属性リストで見つかりません。]
この問題は、フェデレーション・データ・ストアのLDAPサーバーのスキーマがOracle Identity Federation属性とオブジェクト・クラスを含めるためアップグレードされていない場合に発生します。
解決方法
LDAPスキーマのアップグレードは、インストール時(拡張インストール・モードを使用)またはインストール後に行います。
インストール時のスキーマのアップグレード
インストール時にアップグレードするには、次の手順を実行します。
「拡張インストール」モードを選択します。
「構成オプションの選択」ページで、「LDAPサーバー内のフェデレーション・データ」ボックスを選択します。これにより、フェデレーション・レコードが、スキーマのアップグレードが必要なLDAPサーバーに格納されるように指定されます。
「フェデレーション・データ・ストアの指定」ページで、LDAP接続情報を入力します。これで、スキーマがインストール・プロセスの一部としてアップグレードされます。
インストール後のスキーマのアップグレード
インストール後にアップグレードを行うには、Oracle Identity Federationのインストールに、ldapmodify
ツールを使用してLDAPサーバーのスキーマをアップグレードできるLDIF
ファイルが含まれていることを確認してください。
使用するLDIF
ファイルは、使用するLDAPサーバーの種類によって異なります。
Oracle Internet Directoryを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif
です。
Sun One Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaIPlanet.ldif
です。
Microsoft Active Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldif
です。この場合、LDIFファイルを編集して%DOMAIN_DN%
という文字列を使用中のActive Directoryのドメインの接尾辞と置き換える必要があります。
たとえば、接尾辞はdc=mydomain,dc=mycompany,dc=com
です。
ldapmodify
を使用して、LDAPスキーマをLDIFファイルでアップグレードできます。次に例を示します。
ldapmodify -c -D BIND_DN_USERNAME -w PASSWORD -f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif -h LDAP_HOSTNAME -p LDAP_PORT -x
この項では、Oracle Identity Federationがサービス・プロバイダ(SP)で、Oracle Single Sign-Onがバックエンドのアイデンティティ・プロバイダ(IdP)として設定されているときに発生する問題を説明します。内容は次のとおりです。
問題
Oracle Identity Federationがサービス・プロバイダとして構成されています。
パートナ・アプリケーションがOracle Identity Federationによって保護されるように構成されています。
保護されたリソースにユーザーがアクセスしようとすると、意図したOracle Identity Federationログイン・ページでなく、Oracle Single Sign-Onログイン・ページが表示されます。
パートナ・アプリケーションがmod_osso
に対して誤って構成されている場合にこの問題が発生し、ユーザーにローカル認証を求めます。
解決方法
パートナ・アプリケーションがmod_osso
に対して正しく構成されていることを確認するために必要な手順の概要を次に示します。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。
Oracle HTTP ServerとOC4J_SECURITYをシャットダウンします。
Oracle Application Server InfrastructureディレクトリにあるOracle HTTP Serverの構成ファイル、ORACLE_HOME/Apache/Apache/conf/httpd.conf
を次のように編集します。
AddModule
(Windows)ディレクティブおよびLoadModule
(Windows、Linux)ディレクティブを使用して、サーバーのロード済モジュールにosso_moduleを追加します。『Oracle Application Server Single Sign-On管理者ガイド』に記載された例を参照してください。
仮想ホストを追加して、mod_osso
により保護される新しいパートナ・アプリケーション・リスナーを作成します。仮想ホストに対するmod_osso
の構成の詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。
ssoreg
を実行して、手動でmod_osso
とOracle Single Sign-Onサーバーを構成します。
注意:
|
Oracle HTTP Server(OHS)とOC4J_SECURITYを再起動します。
Oracle Identity FederationとOracle Single Sign-Onの統合についての追加情報は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。
問題
ブックマークしたログイン・ページを使用してログインしようするとエラーが返されます。これは、ユーザーが次の手順に従った場合に発生します。
SAML 2.0、LibertyまたはWS-Federationプロトコルを使用してシングル・サインオン(SSO)処理を実行します。
ログイン・ページで、ページにブックマークします。
新しいブラウザ・インスタンスを開いて、ブックマークしたログイン・ページに移動します。有効なユーザー資格証明を使用してログインします。
ユーザーはエラーを受け取り、SSOは失敗します。
解決方法
ログイン・ページはブックマークしないでください。Oracle Identity Federationでは、ブックマークしたログイン・ページの使用はサポートされません。
問題
この問題は、サービス・プロバイダのバックエンドでOracleAS Single Sign-Onを使用する場合に発生します。次の状況で発生します。
SAML 1.x転送URLが発行されます。
SP側でセッション・タイムアウト(OracleAS Single Sign-OnやOracle Identity Federation管理コンソールで設定)に相当する時間だけ待機した後で、同一のブラウザ・インスタンスで同一の転送URLを再発行して、再びログインします。
内部サーバー・エラーが発生するか、異常なリダイレクション動作が見られることがあります。
リソースがOracleAS Single Sign-Onによって保護され、Oracle Identity Federation認証を使用するように構成されている場合、認証のためにOracleAS Single Sign-Onサーバーが開始できるプロトコルはLiberty 1.xとSAML 2.0だけです。SAML 1.xまたはWS-Federationプロトコルを使用して認証されて、その種のリソースへのアクセスを取得するユーザーを考えます。セッションがタイムアウトすると、ユーザーはLiberty 1.xまたはSAML 2.0を使用する認証のためにOracleAS Single Sign-OnによってOracle Identity Federationにリダイレクトされます。このとき、プロトコルが未構成であればサーバー・エラーが発生し、そうでない場合でも、ユーザーがSAML 1.xまたはWS-Federationログインと異なるIdPにリダイレクトされるため、予期しないリダイレクションになります。
解決方法
すぐに可能な回避策は、ブラウザ・インスタンスを閉じ、新しいブラウザ・インスタンスでSAML 1.x SSOリクエストを再発行することです。
根本的な解決方法はOracleAS Single Sign-Onを構成しなおすことです。ユーザーがSAML 1.x/WS-Fedプロトコルによって認証された場合にはOracleAS Single Sign-Onによって保護されているリソースにアクセスし、セッションがタイムアウトした場合にはOracleAS Single Sign-Onによってリダイレクトされてローカル認証を受けるようにします。
Oracle_Home/sso/conf/policy.properties
ファイルを開きます。
すべてのパートナ・アプリケーションを、デフォルトのOracleAS Single Sign-Onサーバー認証プラグインで保護します。
SASSO認証プラグインを構成して、OracleAS Single Sign-Onサーバー・プラグインより高いセキュリティ・レベルを持つようにします。
この項では、バックエンドでOracle Access Managerコンポーネントを構成する場合に発生することがある問題について説明します。内容は次のとおりです。
問題
アクセス・サーバーSDKが、アクセス・ゲートの実行権限を持つ特定のユーザーを指定します。
Oracle Identity Federationは別のユーザーの権限下にあるLinuxまたはSolarisプラットフォームにインストールされています。
アクセス・ゲート構成ページをOracle Access Managerユーザー・データ・ストアに適用すると、次のエラーを受け取ります。
AccessGate構成が失敗しました。理由: アクセス・サーバーへの接続を準備をしています。お待ちください。
エラー: 許可されません。
このエラーの原因はOracle Identity Federationとアクセス・サーバーSDKのインストールが、異なった所有者を持っていることです。
解決方法
Oracle Identity FederationがLinuxまたはSolarisにインストールされている場合は、ORACLE_HOME/fed/shareid
にインストールされたアクセス・サーバーSDKの各ファイルが、Oracle Identity Federationインストールと同一の所有者およびグループを持っていることを確認します。
問題
アクセス・ゲートを使用してOracle Access Managerユーザー・データ・ストアの構成を試みると、アクセス・ゲートIDに非ラテン文字(たとえば、「ÆÖ2」)が含まれると、エラーになります。
AccessGate構成が失敗しました。理由: アクセス・サーバーへの接続を準備をしています。お待ちください。クライアント認証に失敗しました。アクセス・ゲートIDを確認してください。
この問題は、アクセス・ゲートIDに、ASCII Latin-1以外の文字(「Ådmïn」)が含まれる場合にも発生します。
解決方法
Oracle Identity Federationアクセス・ゲートではアクセス・ゲートIDにASCII文字のみを使用するようにします。
問題
Oracle Identity Federationインスタンス(OC4J_FED
)は、Oracle Access Managerバックエンドとともに動作するとクラッシュします。
この問題は、LD_ASSUME_KERNEL
環境変数の設定が正しくないことが原因の可能性があります。アクセス・サーバーSDKはLinuxスレッド・モデルをサポートし、Native POSIX Thread Library(NPTL)をサポートしていないため、この変数は2.4.19
に設定する必要があります。
たとえば、LD_ASSUME_KERNEL
が設定されていない場合は、Oracle Identity Federationのfederation.log
ファイルおよびfederation-error.log
ファイルに、このタイプのエラーが記録されます。
06/06/15 10:05:22: ERROR ShareIDLogger - ObRareqService: EXCEPTION during initialization: (SVX001) com.oblix.access.ObAccessException: Env variable LD_ASSUME_KERNEL not set to 2.4.19. at com.oblix.access.ObConfig.jni_initialize(Native Method) ...
ユーザーのブラウザに、内部サーバー・エラーであるというメッセージが表示されることもあります。
解決方法
「Oracle Identity FederationとOracle Access Managerの統合」を参照してください。手順3に、AccessServerSDKインストーラを使用してLD_ASSUME_KERNEL
を設定する方法が説明されています。
問題
Oracle Access Managerバックエンドを持つ2つのプロバイダ(たとえばIdPとSP2)が構成に含まれ、両方のインスタンスが同一のCookieドメインを使用している場合、シングル・サインオンを試みるとエラーが発生することがあります。ログ・ファイルには次のようなエラー・メッセージが記録されます。
06/05/21 01:24:40: エラー - COREIDブリッジ: エラー、セッション・トークンloggedoutcontinueが無効です: com.oblix.access.ObAccessException: ObUserSessionコンストラクタに渡されたセッション・トークンがNULLまたは無効です。(NBE006)
この問題が発生するのは、複数のOracle Access Managerプロバイダが同一のCookieドメインを使用している場合です。
解決方法
Oracle Access Managerインスタンスが異なるCookieドメインを使用するように変更するか、IdP側で異なるバックエンド(LDAPバックエンドなど)を使用することで、問題を解決できます。
この項では、Oracle Identity Federationがインストールされたマシンのオペレーティング・システムの構成に関する問題を説明します。
注意: この項に示した問題の中には、Oracle Identity Federationサーバーのシステム全体に影響がある問題もあれば、特定のフェデレーション・パートナなど特定のコンポーネントにのみ影響がある問題もあります。 |
問題
Oracle Identity Federationサーバーが断続的にクラッシュし、federation-error.log
ファイルに次のエラー・メッセージが記録されることがあります。
java.net.SocketException: Too many open files
このエラーは、ファイル記述子の上限に達している場合に発生します。
解決方法
/etc/security/limits.conf
構成ファイルで指定されているファイル記述子の上限値を増やします。
注意: ファイル記述子の上限が定義されていない場合、サーバーはデフォルト値の1024を使用します。 |
この例では、ファイル記述子の上限値が16Kの値に設定されます。
soft nofile 16384
hard nofile 16384
値を変更したら、マシンを再起動します。
LDAP参照用に構成されているActive Directory環境で情報を検索するときに、参照先のホストがActive Directoryサーバーと異なるドメインにある場合、参照は失敗します。
問題
ユーザーがリソースをリクエストすると、ディレクトリでユーザーのIDを検証できないため、ユーザーのIDの検証時に失敗する場合があります。このエラーは、ユーザーのブラウザがWindows以外のコンピュータで実行されている場合のActive Directory環境またはユーザーのブラウザがActive DirectoryサーバーのドメインにないWindowsコンピュータで実行されている場合に発生する可能性があります。
この問題は、LDAP参照の追跡により発生します。ドメイン・コントローラにリクエストされたオブジェクトがあるディレクトリ・ツリーのセクションがない場合にLDAP参照が発生します。ドメイン・コントローラにより、クライアントが別のドメイン・コントローラのDNS検索を実行できるよう、別の宛先へのクライアントが参照されます。クライアントが参照を追跡するよう構成されている場合は、継続して検索できます。
Windows対応コンピュータを使用している場合、クライアントのドメイン・コントローラとActive Directoryのドメイン・コントローラ間で信頼関係がない場合に、LDAP参照で問題が発生します。
解決方法
この問題が発生したら、次のリストにあるActive Directoryホストのアドレスのエントリを追加します。
WINDOWS_HOME_DIRECTORY
\system32\drivers\etc\hosts
Windows XP上では、リストは次の場所にあります。
C:\WINDOWS\system32\drivers\etc\host
Unix対応システムでは、次のフォーマットを使用してこのエントリを/etc/hosts
ファイルに追加します。
IP_address_of_AD_host AD_host_name
AD_host_name
は、参照で指定されたホスト名です。たとえば、次のようになります。
123.123.123.123 my2003ad.com
この項では、Oracle Identity Federationの使用時に発生することがある、各種の実行時およびシングル・サインオンに関する問題について説明します。
問題
次のような構成の場合、Oracle SmartMarksを使用すると404エラーになります。
ソース・サイトおよび宛先サイトにOracle SmartMarksを構成します。つまり、ドメイン・エントリでOracle SmartMarksを有効化し、宛先サイトでソース・ドメインに転送問合せ文字列を入力します。
SAML 1.x転送URLを発行します。次に例を示します。
http://ref1.refcompany.com:80/shareid/saml/ObSAMLTransferService?DOMAIN=titanium.refcompany.com&TARGET=https://sometarget.refcompany.com:2008/test.html&METHOD=POST
ブラウザを閉じて新しいブラウザ・インスタンスを開きます。
保護されたリソースへの直接アクセスを試みます。
https://sometarget.refcompany.com:2008/test.html
認証のためにソース・サイトにリダイレクトされたら、有効な資格証明(ユーザー名とパスワード)を入力します。
ログインすると、保護されたリソースにアクセスできず、404
エラーを受け取ります。
この問題は、正しくない転送問合せ文字列を使用したために発生することがあります。
解決方法
転送問合せ文字列の「TARGET=
」キーワードの後に、実際のターゲットが含まれていないことを確認します。
たとえば、次に示すのは正しくない転送問合せ文字列です。
DOMAIN=platinumob.refcompany.com&METHOD=POST&TARGET=https://sometarget.refcompany.com:2008/test.html
正しい転送問合せ文字列は次のようになります。
DOMAIN=titanium.refcompany.com&METHOD=POST&TARGET=
問題
ユーザーがアイデンティティ・プロバイダを変更した(たとえば、Company Aを退職してCompany Bに入社した)のに、SAML 1.xまたはWS-Federationを使用してSPが開始するSSOで、古いアイデンティティ・プロバイダにリダイレクトされます。
解決方法
ユーザーのブラウザに設定されたObSAMLDomainのCookieをすべて消去します。
問題
ユーザーがWS-Federationにより保護されているリソースにブックマークし、サービス・プロバイダがOracleAS Single Sign-Onバックエンドを使用している場合、後でブックマークにアクセスしようとすると、ユーザーはエラーを受け取ります。
解決方法
SPがOracleAS Single Sign-Onバックエンドを使用している場合、WS-Federationにより保護されたリソースへの直接アクセスはサポートされません。このシナリオの場合、リソースにブックマークして、後でアクセスしようとしないでください。
この項には、Oracle Identity Federation管理コンソールに関する問題が含まれます。
問題
この問題は、Oracle Identity FederationサーバーがOracle Single Sign-Onと統合されている場合に発生します。
Oracle Identity Federationを使用してフェデレーテッド・シングル・サインオンを実行し、ユーザーがOracleAS Single Sign-Onを使用して認証される場合、Oracle Identity Federationの管理コンソールや監視コンソールにアクセスできません。アクセスが拒否され、認証が失敗します。
Oracle Identity FederationコンソールはJAZNモジュールによって保護されています。この問題は、OracleAS Single Sign-OnとJAZNモジュールの間のロールの競合が原因となっていることがあります。
解決方法
2つの可能な解決策があります。すぐに可能な回避策としては、クリーンなブラウザ・インスタンスで管理コンソールや監視コンソールにアクセスします。長期的な解決方法としては、管理コンソールや監視コンソールが、OracleAS Single Sign-Onによって保護されるように構成します。
OracleAS Single Sign-Onを使用してコンソールを保護するには、次の手順に従います。
Oracle Enterprise Manager 10g Application Server Controlコンソールにログオンします。
コンソールで、「OC4J_FED」→「アプリケーション」→「fed」、または「fedmon」→「一般」とナビゲートします。
Oracle Internet Directoryの場所を含む「JAZN LDAPユーザー・マネージャを使用」を選択します。
「適用」をクリックします。
「OC4J_FED」→「アプリケーション」→「fed」、または「fedmon」→「セキュリティ」とナビゲートします。
「ロールをプリンシパルにマップ」をクリックします。
コンソールにアクセスできるようにするユーザーまたはグループをLDAPサーバーから選択します。
「適用」をクリックします。
OC4J_FEDインスタンスを再起動します。
これで、コンソールへのアクセスを試みているユーザーが、OracleAS Single Sign-Onサーバーにリダイレクトされ、認証されるようになります。