| Oracle® Fusion Middleware Oracle Identity Federation管理者ガイド 11g リリース1(11.1.1) B66693-01 |
|
 前 |
 次 |
この章では、IDおよびアクセス管理システム、Webサーバーおよびバックエンド・データ・ストアとの統合など、主なデプロイ・シナリオについて説明します。内容は次のとおりです。
Oracle Identity Federationは、異機種間システム環境で動作し、様々な種類のプラットフォームやアプリケーションと連携できます。また、データ・ストアおよび認証プロバイダのための多様なオプションをサポートしています。
デプロイメントの問題および質問を解決するには、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。この章では、デプロイメントの計画に役立つ広範なバックグラウンド情報が説明されています。
第2.1項「アーキテクチャ・オプション」では、サポートされているプロトコルおよびプロファイルに関する詳細と、デプロイメント・オプションを評価する際の考慮事項について説明しています。
第2.6項「サイジングのガイドライン」では、パフォーマンスに影響を与える要因と、トポロジに関する推奨事項について説明しています。
第2.7項「実装チェックリスト」は、デプロイメント用のチェックリストです。
次の項では、様々なデプロイ・シナリオについて説明した後で、フェデレーション環境の主要なコンポーネントと連携するようにOracle Identity Federationを構成する手順について段階的に説明します。
この項では、一般的なOracle Identity Federationのデプロイ・シナリオを実装するために必要な手順について説明します。これらの項目が含まれます。
HTTPサーバーはWeb層にデプロイされます。
大半のアイデンティティ管理コンポーネントはWeb層なしで動作できますが、大半のエンタープライズ・デプロイメントではWeb層が望ましいです。Oracle Single Sign-OnやOracle Access Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。
この項では、Oracle HTTP Server (OHS)と統合されるようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。
|
注意: Oracle HTTP Serverのインストール時に有効になるのはHTTPプロトコルのみです。Oracle HTTP Serverと、Oracle Identity Federationが実行されている管理対象サーバーの間でSSLを有効にするには、インストール後にHTTPSを構成する必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
IdMスイートのインストール時に、「コンポーネントの選択」画面で「Oracle HTTP Server」を選択します。これによりOracle HTTP Serverがインストールされます。
インストール後に、次のコマンドライン命令を発行してインスタンスを作成します。
$AS_INST/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME
$AS_INSTはアプリケーション・サーバー・インスタンス・ホームを、$OHS_NAMEは新しいOHSコンポーネントの名前を示しています。
Oracle HTTP Serverを開始、停止および再起動するためのコマンドは、それぞれ次のとおりです。
$AS_INST/bin/opmnctl startproc process-type=OHS $AS_INST/bin/opmnctl stopproc process-type=OHS $AS_INST/bin/opmnctl restartproc process-type=OHS
AS_INSTはアプリケーション・サーバー・インスタンス・ホームを示しています。
次に、次の手順を実行してOracle Identity Federationが実行されている管理対象サーバーにOracle HTTP Serverを関連付けます。
$AS_INST/config/OHS/$OHS_NAME/moduleconf/oif.confを開きます。
$AS_INSTはアプリケーション・サーバー・インスタンス・ホームを示しています。
Oracle Identity Managementがスタンドアロン・モードでインストールされている場合は、Oracle Identity Federationが実行されているWebLogic管理対象サーバーを参照するようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: myhost.us.mycorp.comと7499)。
Oracle Identity Managementがクラスタ・モードでインストールされている場合は、Oracle Identity Federationが実行されているOracle WebLogic Server管理対象サーバーを参照するようにWebLogicCluster変数を非コメント化して設定します(例: myhost1.us.mycorp.com:7499、myhost2.us.mycorp.com:7499)。
ファイルを保存して終了します。
Oracle HTTP Serverを再起動します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項 |
次に、次の手順を実行してOracle Identity Federationの構成を更新します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サーバー・プロパティ」の順に移動します。
OHSで構成されているホスト名が反映されるようにホスト名を変更します(ホスト名が異なる場合)。
「ポート - SSL有効」および「SOAPポート - SSL有効」の情報を変更してOHSの構成を反映させます。
変更を保存します。
Oracle Identity Federationメタデータが変更されるため、メタデータをリモート・パートナに再分配して、変更をリモート・パートナに通知します。
この項では、Oracle Single Sign-Onと統合するようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。
この方法でデプロイすると、Oracle Identity Federationは、ローカル・ユーザー認証が必要な場合に、Oracle Single Sign-Onが提供する認証機能を利用することができます。Oracle Identity Federationは次のことが可能です。
OHSおよびOracle Single Sign-Onと統合し、認証エンジンとして動作します。
Oracle Single Sign-Onと統合し、SP統合モジュールとして動作します。
このデプロイを実行する手順を簡単にまとめると、次のようになります。
Oracle Single Sign-Onを認証エンジンとして使用する場合のOracle Identity Federationの構成
Oracle Single Sign-On SP統合を使用する場合のOracle Identity Federationの構成
次に、これらの手順の詳細を説明します。
OHSを構成するには、第3.2.1項「Oracle Identity FederationとOracle HTTP Serverのデプロイ」の手順を実行します。
Oracle Identity FederationとOracle Single Sign-Onをデプロイするにはこの統合が必要です。
パートナ・アプリケーションの登録
まず11gリリース1(11.1.1) OHSのmod_ossoモジュールを10g Oracle Single Sign-Onサーバーにパートナ・アプリケーションとして登録します。
この手順の詳細は、『Oracle Application Server Single Sign-On管理者ガイド 10g』のパートナ・アプリケーションの構成および管理に関する項を参照してください。
Oracle Single Sign-Onサーバーからssoregを実行してosso.confファイルを生成し、パートナ・アプリケーション(Oracle Identity FederationインスタンスのAS_INST)に手動でコピーする必要があります。
リモート・パートナ・アプリケーションをOracle Single Sign-Onサーバーに登録する場合の例を次に示します。
$ORACLE_HOME/sso/bin/ssoreg.sh -site_name oif.server.com:7499 -config_mod_osso TRUE -mod_osso_url http://oif.server.com:7499 -remote_midtier -config_file oif.server.com.osso.conf
Oracle Single Sign-OnサーバーのOC4J_SECURITYインスタンスを再起動します。
このコマンドを実行すると、コマンドを起動したディレクトリにoif.server.com.osso.confというファイルが作成されます。そのファイルを$AS_INST/config/OHS/$OHS_NAME/にコピーします。
mod_ossoの設定
次の手順ではmod_ossoを設定します。
$AS_INST/config/OHS/$OHS_NAME/disabled/mod_osso.confを$AS_INST/config/OHS/$OHS_NAME/moduleconfにコピーします。OHSの起動時に、moduleconfディレクトリ内のすべてのファイルが読み込まれます。
$AS_INST/config/OHS/$OHS_NAME/moduleconf/mod_osso.confファイルを開きます。作成後に次のOHS configディレクトリにコピーされたOracle Single Sign-On構成ファイルを参照するように、OssoConfigFileディレクティブを設定します。
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/oif.server.com.osso.conf
Location要素を介して、Oracle SSOサーバーで保護する/fed/user/authnosso URLを追加します。
mod_osso.confの例は次のようになります。
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/
${COMPONENT_NAME}/oif.server.com.osso.conf
<Location /fed/user/authnosso>
require valid-user
AuthType Osso
</Location>
</IfModule>
|
注意: SSLが有効でない場合は、OssoSecureCookiesディレクティブを追加して、offに設定する必要があります。これを行わないと、mod_ossoはCookieが保護されていると見なして、HTTPSでCookieを送信するようにブラウザに指示します。
詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのmod_osso Cookieのセキュアな伝送に関する項を参照してください。 |
mod_osso.confは次のようになります。
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/oif.server.com.osso.conf
</IfModule>
#
# If you would like to have short hostnames redirected to
# fully qualified hostnames to allow clients that need
# authentication via mod_osso to be able to enter short
# hostnames into their browsers uncomment out the following
# lines
#
#PerlModule Apache::ShortHostnameRedirect
#PerlHeaderParserHandler Apache::ShortHostnameRedirect
OHSを再起動して、mod_ossoおよびmod_wlの構成の変更を有効にします。
このタスクでは、Oracle Single Sign-On認証エンジンを使用するようにサーバーを構成します。詳細は、第2.3.1項「Oracle Identity Federationのエンジン」を参照してください。
まず次の手順を実行してOracle Single Sign-On認証エンジンを有効にします。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証エンジン」→Oracle SSOの順に移動します。
エンジンを有効にします。
変更を保存します。
Oracle Single Sign-OnがOracle Identity Federationの認証エンジンとして統合のみが行われている場合は、Oracle Single Sign-OnサーバーでOracle Single Sign-Onのログアウト用の構成を設定し、Oracle Identity FederationサーバーでOracle Identity Federationのログアウト用の構成を設定する必要があります。
Oracle Single Sign-Onを設定するには、次の手順を実行します。
$ORACLE_HOME/sso/conf/policy.propertiesを開きます。
SASSOLogoutUrlを非コメント化します。
Oracle Identity Federationのホスト名/ポート情報を次のように設定します。
SASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/authnsloosso
変更を保存して終了します。
OC4J_SECURITYインスタンスを再起動します。
Oracle Identity Federationを設定するには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証エンジン」→Oracle SSOの順に移動します。
ログアウトを有効にします。
Oracle Single Sign-Onサーバーの「ログアウトURL」で次のように入力します。
http://osso-hostname:osso-port/sso/logout
変更を保存します。
このタスクでは、Oracle Single Sign-Onをサービス・プロバイダ統合モジュールとして有効にし、必要に応じてOracle Single Sign-On認証エンジンのログアウトを無効にします。
まず次の手順を実行してOracle Single Sign-On SPモジュールをOracle Identity Federationで有効にします。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ統合モジュール」→Oracle SSOの順に移動します。
SPモジュールを有効にします。
フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合は、ユーザーをローカルに認証するために使用する認証メカニズムを選択します。
Oracle SSOに対してOracle Identity Federationが提供する必要のあるユーザー名属性を入力します。デフォルトはuidです。
Oracle Single Sign-Onサーバーの「ログインURL」を次のように入力します。
http://osso-hostname:osso-port/sso/auth
Oracle Single Sign-Onサーバーの「ログアウトURL」を次のように入力します。
http://osso-hostname:osso-port/sso/logout
「ログアウト有効」を選択します。
「OSSOシークレットの再生成」をクリックして暗号化鍵を作成します。この暗号化鍵はファイルに保存され、Oracle Single Sign-Onに渡されます。キーストアをローカルに保存します。
変更を保存します。
Oracle Single Sign-OnがOracle Identity Federationの認証エンジンおよびSP統合モジュールとして統合されている場合は、SP統合モジュールでログアウトが管理されるため、Oracle Single Sign-On認証エンジンのログアウトを無効にする必要があります。Oracle Single Sign-On認証エンジンのログアウトをOracle Identity Federationで無効にする手順は次のとおりです。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証エンジン」→Oracle SSOの順に移動します。
ログアウトを無効にします。
変更を保存します。
ここでの設定では、Oracle Single Sign-Onサーバーでの設定とパートナの構成が必要です。
|
注意: パートナ・アプリケーションは、Oracle Application ServerベースのアプリケーションまたはOracle Single Sign-Onサーバーに認証機能を委任しているOracle以外のアプリケーションです。Oracle Single Sign-Onで認証済のユーザーがアプリケーションの使用を認可されるかどうかは、パートナ・アプリケーションで決定されます。 |
Oracle Single Sign-Onを設定するには、次の手順を実行します。
前に生成したキーストア・ファイルを$ORACLE_HOME/sso/confにコピーし、キーストアとして保存します。
$ORACLE_HOME/sso/conf/policy.propertiesを開きます。
SASSOAuthnUrl、SASSOLogoutUrl、SASSOAuthLevelおよびMediumHighSecurity_AuthPluginを非コメント化します。
Oracle Identity Federationのホスト名/ポート情報にSASSOAuthnUrl= http\://oif-hostname\:oif-port/fed/user/spossoを設定します。
Oracle Identity Federationのホスト名/ポート情報にSASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/spsloossoを設定します。
Oracle Identity Federationプラグインの認証レベルにSASSOAuthLevel = MediumHighSecurityを設定します。
MediumHighSecurity_AuthPluginを設定します。これによりOracle Identity FederationプラグインがMediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuthのように定義されます。
変更を保存して終了します。
OC4J_SECURITYインスタンスを再起動します。
Oracle Identity Federationを認証プラグインとして使用するようにパートナを構成するには、次の手順を実行します。
$ORACLE_HOME/sso/conf/policy.propertiesを開きます。
パートナ・アプリケーションを追加して、Oracle Identity Federationプラグインにマップされている認証レベルで保護されるようにします。次に例を示します。
content.example.com\:8888 = MediumHighSecurity
変更を保存して終了します。
OC4J_SECURITYインスタンスを再起動します。
次の手順に従って、フェデレーテッド・シングル・サインオン構成をテストします。
Webブラウザを使用して保護されたリソースにアクセスします。アイデンティティ・プロバイダに求められたら、IdPのドメインでの資格証明を使用してログインします。サービス・プロバイダに求められたら、SPのドメインでの資格証明を使用してログインします。これで保護されたリソースにリダイレクトされます。
パートナ・アプリケーションおよびリソースの保護の詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドを参照してください。
ログアウトし、もう一度保護されたリソースへのアクセスを試みます。ここでログインを求めてくるのはアイデンティティ・プロバイダだけです。
この項では、Oracle Access Manager 10gと統合されるようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。この統合では、認証ユーザー・セッションを作成するためにOracle Identity FederationとOracle Access Managerを相互運用することが可能になります。この手順では、2つのノードから構成されるデプロイ・シナリオを説明します。
この項は、インストールするコンポーネントおよびデプロイメント・タスクの違いに応じて、別々の手順に別れています。
|
注意: Oracle Identity Federationによって作成されるOracle Access Managerポリシー・オブジェクトは、Oracle Access Manager Policy/Access Manager管理インタフェースからは変更しないでください。これらのオブジェクトは次の記述によって識別できます:「OIFが作成しました。変更しないでください」。このようなオブジェクトをOracle Access Managerから変更すると、同期上の問題を引き起こす場合があります。したがって、これらのポリシー・オブジェクトは必ずFusion Middleware Controlから更新してください。 |
|
注意: Oracle Access Manager 10g認証エンジンと統合した場合、Oracle Identity Federationでは、ユーザーの資格証明を再要求する機能がサポートされません。このため、Oracle Identity Federationでは、再認証を要求する必要があるユース・ケースをサポートできません。たとえば、 |
11gリリース1(11.1.1)OHSコンポーネントのインスタンスを作成および管理する手順は次のとおりです。
OHSインスタンスを作成します。
Oracle Identity Federationが実行されているOracle WebLogic Server管理対象サーバーにOHSインスタンスを関連付けます。
Oracle Identity Federationの構成を更新します。
OHSインスタンスを管理します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項 |
Oracle HTTP Serverインスタンスの作成
|
注意: $OHS_NAMEはOHSコンポーネントの名前を示しています。 |
次のコマンドを実行してインスタンスを作成します。
$AS_ISNT/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME
管理対象サーバーへのOracle HTTP Serverインスタンスの関連付け
OHSから、Oracle Identity Federationが実行されている管理対象サーバーへの接続を有効にするには次の手順を実行します。
$AS_ISNT/config/OHS/$OHS_NAME/moduleconf/oif.confを開きます。
Idmインストールがスタンドアロン・モードの場合は、Oracle Identity Federationが実行されているWLS管理対象サーバーを参照するようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: myhost.mycorp.comと7499)。
Idmインストールがクラスタ・モードの場合は、Oracle Identity Federationが実行されているWLS管理対象サーバーを参照するようにWebLogicCluster変数を非コメント化して設定します(例: myhost1.mycorp.com:7499、myhost2.mycorp.com:7499)。
変更を保存して終了し、OHSを再起動します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項 |
Oracle Identity FederationにおけるOHSの構成の更新
Oracle Identity FederationサーバーがOHSを認識できるようにするには次の手順を実行します。
Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。
「管理」→「サーバー・プロパティ」の順に移動します。
OHSで構成されているホスト名が反映されるようにホスト名を変更します(ホスト名が異なる場合)。
「ポート - SSL有効」および「SOAPポート - SSL有効」の情報を変更してOHSの構成を反映させます。
変更を保存します。
Oracle Identity Federationメタデータが変更されるため、メタデータをリモート・パートナに再分配して、変更をリモート・パートナに通知します。
Oracle HTTP Serverインスタンスの管理
OHSを起動するには、次のようにします。
$AS_ISNT/bin/opmnctl startproc process-type=OHS
$AS_INSTはアプリケーション・サーバー・インスタンス・ホームです。
OHSを停止するには、次のようにします。
$AS_ISNT/bin/opmnctl stopproc process-type=OHS
OHSを再起動するには、次のようにします。
$AS_ISNT/bin/opmnctl restartproc process-type=OHS
認証エンジンとしてのOracle Access Managerは、/fed/user/authnoam URLを保護します。
この機能を構成するには、次の手順を実行します。
要件の確認およびOHSのデフォルト構成の更新
OHSとOracle Access Managerの統合
Oracle Access Managerの構成
Oracle Identity Federationの構成
要件の確認
コンポーネントのバージョンを確認するには、次の手順を実行します。
Oracle Access Managerサーバーのバージョンが10.1.4.3であることを確認します。
11gR1 OHS (2.2)に対応するOracle Access Manager WebGateがインストールされていることを確認します。
OHSで次の手順を実行します。
$AS_ISNT/config/OHS/$OHS_NAME/httpd.confファイルを編集します。
httpd.confファイルでUserおよびGroupディレクティブを非コメント化するか追加します。
nobodyのデフォルト値を、OHS 11gリリース1(11.1.1)をインストールしたユーザーとユーザー・グループに置き換えるか、UserおよびGroupディレクティブがない場合はユーザーとユーザー・グループを追加します。
次に例を示します。
User oracle Group dba
Oracle HTTP ServerとOracle Access Managerの統合
Oracle Access Managerコンソールを使用して新しいアクセス・ゲートを作成し、アクセス・サーバー・インスタンスに関連付けます。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
|
関連項目: WebGateのインストールの詳細は、『Oracle Access Managerインストレーション・ガイド 10g』を参照してください。 |
OHSがインストールされているマシンで、次の手順を使用してWebGateをインストールします。
インストール・ウィザードを起動して、Oracle HTTP Server11gにWebGateをインストールします。
アクセス・ゲートの詳細とアクセス・サーバーの接続情報を入力します。
WebGateとOracle HTTP Serverを統合するには、Oracle HTTP Serverのhttpd.confファイルの場所($AS_ISNT/config/OHS/$OHS_NAME/httpd.confにあります)を入力します。
Oracle Access Managerの構成
Oracle Access Managerは、WebGateを使用してOracle Identity Federationのリソースを保護する必要があります。WebGateはすでにインストールされているため、Oracle Access Managerを認証エンジンとして使用するには、Oracle Identity Federationサーバーを保護するポリシーをOracle Access Managerで使用するだけで済みます。Oracle Access Managerで認証を行う場合、Oracle Identity Federationに対してユーザー識別子をHTTPヘッダーとして渡す必要があります。
Oracle Access Managerを構成するには、次の手順を実行します。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
Oracle Access Managerコンソールに移動し、「ポリシー・マネージャ」に移動します。
ドメインの/fed/user/authnoamリソースを認証スキームと認証ルールで保護します。
「認可ルール」で、「アクション」タブに移動して「変更」をクリックし、「認可成功」セクションで「戻り」プロパティを追加して、値にユーザーIDを設定します。このプロパティはHTTPヘッダーになります。(たとえば、「タイプ」にheadervar、「名前」にuserid、「戻り属性」にuidを設定します。)
|
関連項目: Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g |
Oracle Identity Federationの構成
次の手順を実行します。
Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。
「管理」→「認証エンジン」→「Oracle Access Manager」の順に移動します。
エンジンを有効にします。
ユーザーIDを含むHTTPヘッダーを入力します。
認証エンジン・フレームワークのみを使用してOracle Identity FederationとOracle Access Managerの統合が行われている場合は、次のログアウト構成手順を実行します。それ以外の場合は、ここではOracle Access Manager認証エンジンのログアウトを無効にします。ログアウト処理を構成する場合は、第3.2.3.3項「SP統合モジュールとしてのOracle Access Managerの統合」を参照してください。
ログアウトを有効にするには、「ログアウト有効」ボックスを選択します。
Oracle Access Managerドメインからユーザーがログアウトする際に、Oracle Identity FederationによってOracle Access ManagerのCookieをリセットする場合、「Cookieのクリア」ボックスを選択します。
Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択して、URLを入力します。詳細は、次の注意を参照してください。
変更を保存します。
|
注意: ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。Oracle Access ManageのログアウトURLに追加される問合せパラメータは、 |
|
注意: /fed/user/authnoam URLをHTTP Basic認証で保護する場合は、Oracle Access ManagerのBug 5736326の修正が必要です。 |
HTTPヘッダーでの代替戻り属性の使用
Oracle Identity FederationとOracle Access Managerを統合して認証を行う場合、WebGateが/fed/user/authnoam URLを保護し、Oracle Access Managerはユーザー識別子をHTTPヘッダーとしてOracle Identity Federationに渡すように構成されます。/fed/user/authnoam URLを保護するポリシーには認可ルールとアクションが含まれており、このアクションによって、LDAPユーザー・レコードのユーザーIDを参照する戻り属性を含むHTTPヘッダーが追加されます。この戻り属性は、「管理」→「データ・ストア」→「ユーザー・データ・ストア」セクションの順でOracle Identity Federationインスタンスに移動する場合にFusion Middleware Controlに設定される一意ユーザーIDと同じです。
不具合により、ユーザー識別子を含むHTTPヘッダーの戻り属性としてorclguidを使用することができません。回避策として、一意ユーザー識別子を別の属性に変更する必要があります。変更するには次の手順を実行します。
Oracle Access Managerコンソールで、戻り属性を新しい属性(uidなど)に変更します。
Fusion Middleware Controlで、Oracle Identity Federation管理→「データ・ストア」→「ユーザー・データ・ストア」の順に移動し、一意ユーザーIDを新しい属性(uidなど)に変更します。
他の認証エンジンを使用している場合は、その一意ユーザーID属性が正しく更新されていることを確認します。
Oracle Access Manager SP統合モジュールを使用してOracle Identity FederationとOracle Access Managerを統合している場合は、次の手順を実行して統合を更新します。まず前述の変更を行ってからFusion Middleware ControlでOracle Identity Federationインスタンスに移動し、「管理」→「SP統合モジュール」→OAM SPエンジンの順に移動します。Oracle Access Managerの管理者資格証明を入力して、更新対象の作成済認証スキームを選択し、「Oracle Access Managerの構成」をクリックします。これにより、Oracle Access Managerのマッピング・ルールが新しい属性を反映するように更新されます。
このタスクによりSP統合モジュールとOracle Access Managerの相互作用が可能になります。
基本の手順は次のとおりです。
要件の確認
Oracle Access Server SDKのインストール
Oracle Access ManagerとOracle Access Server SDKの統合
Oracle WebLogic Serverのクラスパスの更新
Oracle Identity Federationの構成
Oracle Identity FederationとOracle Access Managerの統合
Oracle Identity FederationによるOracle Access Managerリソースの保護
要件の確認
次の手順を実行します。
Access Server SDK 10gがインストールされていることを確認します。
高可用性(HA)環境では、Access Server SDKを別個のマシンにインストールして、異なるアクセス・ゲートとしてOracle Access Managerと統合する必要があります。
|
注意: HA環境にデプロイする場合は、必ず『Oracle Fusion Middleware高可用性ガイド』のOracle Access Managerとの統合における高可用性の考慮事項に関する項に記載されている手順に目を通し、実行するようにしてください。必ず、Access Server SDKのインストール先ディレクトリに関する指示に従い、すべての管理対象サーバーを再起動してください。 |
Oracle Access Server SDKのインストール
SDKがインストールされているディレクトリを参照するようにOracle Identity Federationを構成します。
SDKがドメイン・ホーム・ディレクトリにインストールされている場合は、ドメイン・ホーム・フォルダからの相対パスSDKを参照できます。SDKが別の場所にインストールされている場合は、絶対パスを使用してSDKフォルダを参照する必要があります。
HA環境でOracle Identity Federationを使用する場合は、Oracle Identity Federationがインストールされているそれぞれのマシンで同じディレクトリ名の相対パスを使用して、Access Server SDKをドメイン・ホーム・フォルダにインストールすることをお薦めします。このように、異なるOracle Identity Federationインスタンスが同じ構成を共有します。具体的にはAccess Server SDKがインストールされているディレクトリは、すべてのOracle Identity Federationインスタンスで同じ値になります。
Oracle Access ManagerとOracle Access Server SDKの統合
このタスクでは、新しいアクセス・ゲートをアクセス・サーバー・インスタンスに関連付けることができます。
Oracle Access Managerコンソールで、アクセス管理サービスを有効にして新しいアクセス・ゲートを作成し、アクセス・サーバー・インスタンスに関連付けます。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
configureアクセス・ゲートスクリプトを次のように呼び出して、Access Server SDKを統合します。
$ACCESS_SERVER_SDK/oblix/tools/configureAccessGate -i $ACCESS_SERVER_SDK -t AccessGate -w $ACCESS_GATE_ID -m open -h $ACCESS_SERVER_HOST -p $ACCESS_SERVER_PORT
次のように置き換えます。
$ACCESS_SERVER_SDK: Access Server SDKディレクトリの絶対パス
$ACCESS_GATE_ID: このAcccess Gateの識別子
$ACCESS_SERVER_HOST: アクセス・サーバーがインストールされているマシンのホスト名
$ACCESS_SERVER_PORT: アクセス・サーバーのポート
Oracle WebLogic Server環境の更新
Oracle Identity Federationが実行されている管理対象サーバーは、Oracle Access Managerとの統合に必要なJARファイルと共有ライブラリにアクセスできる必要があります。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項 |
環境を更新する手順は次のとおりです。
管理対象サーバーを停止します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のWebLogic Serverの起動と停止に関する項。 |
jobaccess.jarファイルを$ASDK_DIR/oblix/libフォルダから$DOMAIN/libフォルダにコピーします。
次の手順は、実行されているOracle Access Managerのバージョンによって異なります。
実行されているOracle Access Managerのバージョンが10.1.4.3以降で、管理対象サーバーをWebLogic管理コンソールから起動する場合は、次の手順に従います。
WebLogic管理コンソールを開きます。
「サーバー」→「管理対象サーバー」→「構成」→「サーバーの起動」の順に移動します。
「引数」のテキスト・ボックスで、-Djava.library.pathを追加してASDK_DIR/oblix/libを含めます。
変更を保存します。
管理対象サーバーをコンソールから起動します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項 |
実行されているOracle Access Managerのバージョンが10.1.4.2以前、またはOracle Access Managerのバージョンが10.1.4.3で管理対象サーバーをコマンドラインから起動する場合は次の手順を実行します。
jobaccess.jarファイルを$ASDK_DIR/oblix/libフォルダから$DOMAIN/libフォルダにコピーします。
管理対象サーバーを停止します。
Linuxの場合は、ファイル$DOMAIN/bin/startManagedWebLogic.shを開きます。
次の行を追加します。
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:accessSDK installdir/oblix/lib
export LD_LIBRARY_PATH
Oracle Access Managerのバージョンが10.1.4.2以前の場合は、次の2行も追加します。
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
Windowsの場合は、ファイル$DOMAIN/bin/startManagedWebLogic.cmdを開きます。
次の行を追加します。
set PATH=%PATH%;AccessSDK_InstallDir/oblix/lib
(管理コンソールではなく)コマンドラインから管理対象サーバーを起動します。
Oracle Identity Federationの構成
次の手順を実行します。
Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。
「管理」→「サービス・プロバイダ統合モジュール」→「Oracle Access Manager」の順に移動します。
SPモジュールを有効にします。
SAMLアサーション(ユーザーに対してローカル・フェデレーション・レコードの作成が必要な場合などに必要)の処理時に使用する認証メカニズムを選択します。
Access Server SDKがインストールされているディレクトリを入力します。SDKが$DOMAIN_HOMEディレクトリにインストールされている場合は、そのフォルダへのパスを$DOMAIN_HOMEからの相対パスにできます。別のディレクトリにインストールされている場合は、絶対パスにする必要があります。
Oracle Identity Federationにユーザー・セッションを作成する際に、Oracle Identity Federationが使用するデフォルトの認証スキームを入力します。
Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインを入力します。
Oracle Identity Federationでは、Oracle Access ManagerのCookieを永続CookieまたはセッションCookieとして設定できます。永続Cookieの場合は、Cookieが有効になる時間を分単位で入力します。セッションCookieの場合は、0を入力します。
Cookieを保護するようにマークする必要があるかどうかを確認します。マークすると、ブラウザはCookieをHTTPS接続経由で送信します。
ログアウトを有効にする必要がある場合は、「ログアウト有効」ボックスを選択します(推奨)。
Oracle Access Managerドメインからユーザーがログアウトする際に、Oracle Identity FederationによってOracle Access ManagerのCookieをリセットする場合、「Cookieのクリア」ボックスを選択します。
Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択して、URLを入力します。
|
注意: ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。Oracle Access ManageのログアウトURLに追加される問合せパラメータは、 |
変更を保存します。
|
注意:
|
Oracle Identity FederationとOracle Access Managerの統合
Oracle Identity Federationは着信SSOアサーションの処理およびユーザーの識別を行った後で、そのユーザーのOracle Access ManagerセッションをOracle Access Managerドメイン内に作成します。その際、Oracle Identity Federationは次のことを行います。
構成時にOracle Identity Federationが作成したポリシー・ドメインを使用します。
Oracle Identity Federation認証メカニズム(ユーザーのチャレンジを行うためにIdPで使用される認証方式)を、構成時にOracle Identity Federationによって作成されたOracle Access Manager認証スキームにマップします。マップ先のOracle Access Manager認証スキームが存在しない場合は、Oracle Identity Federationの構成のセクションで入力したデフォルトの認証スキームが使用されます。
Oracle Access Managerと連携して、ユーザー・セッションを作成します。その際に、ユーザー・セッションのポリシー・ドメインと認証スキームを指定します。
Oracle Identity Federationに入力するポリシー・ドメイン名は、Oracle Identity Federationによって作成されていない既存のポリシー・ドメインを参照することはできません。Oracle Identity Federationによって作成されたドメインにする必要があります。
ユーザーのブラウザでOracle Access ManagerのCookieを設定します。
統合を正しく行うためには、ポリシー・オブジェクトと認証スキームをOracle Access Managerに作成する必要があります。次の操作を実行します。
|
注意: このタスクでは、Oracle Access Managerに対して適切な管理者資格証明を所有しているとことが前提になります。ポリシー・オブジェクトの作成時には、必ずOracle Access Managerのマスター管理者アカウントを使用してください。 |
|
関連項目: Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g |
Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。
「管理」→「サービス・プロバイダ統合モジュール」→「Oracle Access Manager」の順に移動します。
「Oracle Access Managerプロパティ」セクションを開きます。
Oracle Access Managerの資格証明を入力してOracle Access Managerを構成します。
|
注意: 資格証明が使用されるのは、「Oracle Access Managerの構成」ボタンをクリックしてOracle Access Managerサーバーに接続し、構成を行うときのみです。これらの資格証明はOracle Identity Federationの構成ファイルには保存されません。 |
ポリシー・ドメインの構成時にOracle Identity Federationが使用するホストIDを入力します。このホストIDは、Oracle Access Managerサーバーで定義します。ホストIDには、Oracle Identity Federationサーバーが使用するように構成されたホスト名:ポート情報とそのバリエーションを含める必要があります。
|
注意: これは必須パラメータです。 |
ポリシー・ドメインの作成時に使用されるデフォルトの認証ルールを入力します。
使用可能なOracle Identity Federation認証メカニズムは表にリストされています。それぞれの認証メカニズムにマップされている認証スキーム名と認証スキーム・レベルが表に記載されています。これらのマッピングは、デフォルトではOracle Identity Federationのみに保存されているため、Oracle Access Managerで作成、更新または削除するメカニズムとスキームを選択する必要があります。
作成するスキームを選択して、「Oracle Access Managerの構成」をクリックすると、指定されている名前とレベルでスキームが作成され、Oracle Identity Federationの構成の対応する認証メカニズムにマップされます。作成したスキームのいずれかを、Oracle Identity Federationで使用されるデフォルトのOracle Access Manager認証スキームとして選択する必要があります。デフォルトでは、この値はOracle Identity Federationによってパスワードで保護されます。そのため、デフォルトとして何も選択されてない場合は、パスワードで保護された認証スキームを選択して作成する必要があります。スキームを選択して削除すると、同様に、Oracle Access Managerからそのスキームが削除されます。スキームを選択して更新すると、Oracle Identity Federationで使用されるデフォルトのOracle Access Manager認証スキームとその名前がOracle Access Managerで更新されます。
|
注意: ドメインで使用されている認証スキームは、サーバーで更新/削除できません。 |
「Oracle Access Managerの構成」をクリックします。
Oracle Identity FederationによるOracle Access Managerリソースの保護
|
関連項目: Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g |
Oracle Identity FederationとOracle Access Managerを統合して認証スキームを作成すると、作成したスキームを使用してリソースを保護できるようになります。特定のスキームによってリソースを保護すると、次のように作用します。
認証されていないユーザー(またはスキームの認証レベルよりも低いレベルの認証ユーザー)が、Oracle Identity Federation認証スキームで保護されているリソースにアクセスしようとすると、Oracle Access ManagerサーバーがそのユーザーをOracle Identity Federationにリダイレクトし、フェデレーションSSOが行われます。
Oracle Access Managerは、リクエストされたリソースと使用するOracle Identity Federation認証スキーム名をOracle Identity Federationに渡します。
Oracle Identity Federationは、その認証スキームを認証メカニズムにマップしてから、SAML/WS-Fed認証方式にマップします。
Oracle Identity Federationは、アイデンティティ・プロバイダにユーザーを送信し、ユーザーに認証を要求するために使用する認証方式を指定して、フェデレーションSSOフローを開始します。
IdPは、ユーザーの正当性を確認してアサーションを作成し、アサーションとともにユーザーをOracle Identity Federationに送り戻します。
Oracle Identity Federationは、このアサーションを処理する際に、ユーザーの認証に使用する方式をアサーションから抽出して認証メカニズムにマップします。
処理が成功すると、Oracle Identity Federationが認証メカニズムを認証スキームにマップし、ユーザーのOracle Access Managerセッションを作成します。
Oracle Identity Federationが、リクエストされたリソースにユーザーをリダイレクトします。
最後に、Oracle Access Managerが、認証ユーザーに対してリソースへのアクセスを許可します。
Oracle Identity Federationがサービス・プロバイダとして動作する場合、Oracle Access Managerユーザー・セッションの作成時に、Oracle Access Managerサーバーに対してOracle Identity Federation自身の認証を行うように構成できます。
このセクションの内容は次のとおりです。
この認証操作は、Oracle Identity FederationがOracle Access Managerフェデレーション認証スキームを使用してユーザー・セッションを作成する際に、Oracle Identity Federationをホストするマシンにインストールされているアクセス・ゲートを介して行われます。
この操作では、スキームを呼び出すモジュールが確実にOracle Identity Federationサーバーであること、またそれ以外のプロセスによってそのスキームが使用されないことが保証されます。
操作フロー
デプロイメントおよび実行時のフローは次のとおりです。
Oracle Identity Federation管理者がFusion Middleware Controlを使用して、Oracle Access Managerフェデレーション・スキームを作成または既存のOracle Access Managerフェデレーション・スキームを更新し、2つの新しいプラグインを追加します。
Oracle Identity Federation管理者がFusion Middleware Controlを使用して、必要な資格証明をOIFに指定します。
実行時に、Oracle Identity Federationがこの資格証明とともに、Oracle Access Managerユーザー・セッションの作成に使用されるデータを渡します。
Oracle Access Managerサーバーが、LDAPユーザー・リポジトリに対してOracle Identity Federation資格証明の検証を行います。
Oracle Identity Federation資格証明の検証後に、Oracle Access Managerユーザー・セッションが作成されます。
LDAPアカウントのカスタマイズ
管理者は次の内容を選択することにより、Oracle Identity Federation資格証明の検証に使用されるLDAPアカウントをカスタマイズできます。
エントリの場所(つまり、ユーザーのブランチとは異なる場所)
エントリのオブジェクト・クラス
認可されたサーバーによる認証の呼出し
セキュリティ上の理由により、フェデレーション・スキームのcredential_mappingプラグインにOracle Identity Federationのユーザー名を設定できます。これにより、このスキームの呼出し時にそのアカウントに対応するユーザーのみが使用されることが保証されます。
この機能はオプションですが、有効にすることで認可されたOracle Identity Federationサーバーに限定してフェデレーション認証スキームを呼び出すことができます。
ここでの前提は次のとおりです。
Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。
Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされていません。
アクセス・サーバーに作成されているフェデレーション・スキームはすべて、Oracle Identity FederationがOracle Access Managerの認証を行うようには構成されていません。
構成には次の操作が必要です。
Oracle Identity Federation認証に使用するアカウントをLDAPディレクトリに作成します。
Fusion Middleware Controlを使用して、Oracle Identity Federationアカウント情報を設定し、認証を有効にします。
Fusion Middleware Controlを使用して、既存のすべてのフェデレーション・スキームを更新し、新しいOracle Access Managerプラグインを定義します。
Oracle Access Managerコンソールを使用して、既存のすべてのフェデレーション・スキームを更新し、新しいプラグインに対する新しい認証フローを定義します。
LDAPエントリの作成
フェデレーション・スキームを使用する場合に、Oracle Identity FederationからOracle Access Managerへの認証を可能にするために、Oracle Identity Federation資格証明の検証時に使用するエントリをLDAPディレクトリに含める必要があります。そのようなエントリが存在しない場合は、識別子に基づいて双方からの検索が可能で、パスワード属性を持つエントリを作成します。Fusion Middleware Controlを使用して、次のものを設定します。
識別子
パスワード
エントリのベースDN
エントリのオブジェクト・クラス
識別子を格納する属性
次の選択が可能です。
すべてのユーザー・レコードが位置するブランチとは異なるエントリの場所
ユーザー・レコード・タイプとは異なるオブジェクト・クラス
Oracle Identity Federationアカウント情報の設定
フェデレーション・スキームの呼出し時に、資格証明を示すようにOracle Identity Federationを構成するには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
チェック・ボックスを選択してOracle Identity Federation認証を有効にします。
Oracle Identity Federation認証に使用するアカウントのユーザー名とパスワードを入力します。
Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを入力します。
Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを入力します。
ユーザー名を含める、検索可能なLDAPエントリ属性を入力します(LDAPエントリで定義されている場合は、uidなど)。
新しいプラグインの定義
次に、既存のフェデレーション・スキームを更新して、認証操作に使用する2つの新しいプラグインを組み込みます。次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
Oracle Access Managerに作成されているすべてのフェデレーション・スキームを選択して「更新」をクリックします。
Oracle Access Manager管理者資格証明を入力して、Oracle Access Managerサーバーで管理用更新処理を実行できるようにします。
「Oracle Access Managerの構成」をクリックします。
これによりスキームが更新され、次の2つの新しいプラグインが組み込まれます。
credential_mappingプラグイン。Oracle Identity Federationアカウントを検索する際に使用されます。
validate_passwordプラグイン。Oracle Identity Federationの任意のアカウントに指定されているパスワードを検証する際に使用されます。
新しい認証フローの定義
アクセス・サーバーの制限により、前述の手順で作成した新しいプラグインを組み込むための新しい認証フローを作成する際に、Fusion Middleware Controlを使用することができません。かわりに、Oracle Access Managerコンソールを使用して、それらのオブジェクトを作成する必要があります。
更新したそれぞれのフェデレーション・スキームに対して、次のアクションを実行します。
Oracle Access Managerコンソールに管理者としてログインします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」の順に移動します。
更新するフェデレーション・スキームを選択します。
「ステップ」タブをクリックします。
「追加」をクリックして、新しいステップを追加します。
「ステップ名」フィールドにステップの名前を入力します。
「使用可能なプラグイン」表で、次の順序で手順を実行します。
|
注意: この順序が重要です。 |
2つ目のcredential_mappingプラグインを選択して、「追加」をクリックします。
validate_passwordプラグインを選択して、「追加」をクリックします。
1つ目のcredential_mappingプラグインを選択して、「追加」をクリックします。
「保存」をクリックします。
「認証フロー」タブをクリックします。
「変更」をクリックします。
新しいステップを「開始ステップ」として選択します。
「成功時の次のステップ」で「停止」を選択します。
「失敗時の次のステップ」で「停止」を選択します。
「保存」をクリックします。
「ステップ」タブをクリックします。
古いステップを選択します。「削除」をクリックします。
この構成では次の前提に対応しています。
Oracle Identity Federationがすでにデプロイされ、Oracle Access Managerと統合されているか、またはOracle Identity Federationがデプロイされているが、Oracle Access Managerとまだ統合されていない状態です。
Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされていません。
アクセス・サーバーにはフェデレーション・スキームが作成されていません。
これには次のタスクが含まれます。
Oracle Identity Federation認証に使用するアカウントをLDAPディレクトリに作成します。
Oracle Identity Federationのアカウントに関する情報、および新しい認証スキームの作成で必要になると想定されるOracle Identity Federation/Oracle Access Manager統合に関する情報をFusion Middleware Controlで設定します。
Fusion Middleware Controlを使用して、新しいフェデレーション・スキームを作成します。
LDAPアカウントの作成
フェデレーション・スキームを使用する場合に、Oracle Identity FederationからOracle Access Managerへの認証を可能にするために、Oracle Identity Federation資格証明の検証時に使用するエントリをLDAPディレクトリに含める必要があります。そのようなエントリが存在しない場合は、識別子に基づいて双方からの検索が可能で、パスワード属性を持つエントリを作成する必要があります。Fusion Middleware Controlを使用して、次のものを設定します。
識別子
パスワード
エントリのベースDN
エントリのオブジェクト・クラス
識別子を格納する属性
次の選択が可能です。
すべてのユーザー・レコードが位置するブランチとは異なるエントリの場所
ユーザー・レコード・タイプとは異なるオブジェクト・クラス
Oracle Identity Federationアカウント情報の設定
フェデレーション・スキームの呼出し時に、資格証明を示すようにOracle Identity Federationを構成するには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
Oracle Identity Federation認証を有効にします。
Oracle Identity Federation認証に使用するアカウントのユーザー名とパスワードを入力します。
Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを入力します。
Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを入力します。
ユーザー名を含める、検索可能なLDAPエントリ属性を入力します(LDAPエントリで定義されている場合は、uidなど)。
必要に応じてOracle Access Managerの残りのフィールドを構成し、「Oracle Access Managerの構成」をクリックして変更を適用します。
この後に作成されるフェデレーション・スキームには、実行時のOracle Identity Federationの認証に必要な情報が含まれます。フェデレーション認証スキームを更新するために、Oracle Access Managerコンソールで手動で操作する必要はありません。
ここでの前提は次のとおりです。
Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。
Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされています。
フェデレーション・スキームが存在し、実行時にOracle Identity Federation認証を実行するように構成されています。
Oracle Identity Federation資格証明を更新すると、フェデレーション・スキームに対して次のような更新が必要になる場合があります。
Oracle Identity Federationパスワードのみが更新されている場合は、フェデレーション・スキームを変更しなくても構いません。
パスワード以外のOracle Identity Federationアカウントに関する情報(オブジェクト・クラス、ベースDN、ユーザー名など)が更新されている場合は、すべてのフェデレーション・スキームを更新する必要があります。
Oracle Identity Federationパスワードのみの更新
Oracle Identity Federationパスワードのみを更新する場合は、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
Oracle Identity Federation認証に使用するアカウントのパスワードを入力します。
「Oracle Access Managerの構成」をクリックして変更を適用します。
パスワード以外のデータの更新
Oracle Identity Federationパスワード以外の情報を更新する場合は、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
Oracle Identity Federation認証に使用するアカウントのユーザー名またはパスワード、あるいはその両方を更新します(任意)。
Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを更新します(任意)。
Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを更新します(任意)。
ユーザー名が格納される検索可能なLDAPエントリ属性(LDAPエントリで定義されている場合は、uidなど)を更新します(任意)。
Oracle Access Managerに作成されているすべてのフェデレーション・スキームを選択して「更新」をクリックします。
Oracle Access Manager管理者資格証明を入力して、Oracle Access Managerサーバーで管理用更新処理を実行できるようにします。
「Oracle Access Managerの構成」をクリックします。
これで、フェデレーション・スキームのcredential_mappingプラグインに更新された情報が組み込まれ、Oracle Identity Federationの認証処理で使用されるようになりました。
ここでの前提は次のとおりです。
Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。
Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされています。
フェデレーション・スキームが存在し、実行時にOracle Identity Federation認証を実行するように構成されています。
これらのタスクには次が含まれます。
既存のフェデレーション・スキームを更新して、Oracle Identity Federation認証に関連するオブジェクトを削除します。
Fusion Middleware Controlを使用して、Oracle Identity Federation認証を無効にします。
既存のフェデレーション・スキームの更新
この手順では、Oracle Identity Federation認証で不要となったフェデレーション・スキームを更新します。この処理を行わない場合、スキームは引き続き資格証明を受け入れようとしますが、これ以降、Oracle Identity Federationから資格証明が送信されることはありません。
更新したそれぞれのフェデレーション・スキームに対して、次の手順を実行します。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」の順に移動します。
更新するフェデレーション・スキームを選択します。
「ステップ」タブを選択します。
「追加」をクリックして、新しいステップを追加します。
「ステップ名」フィールドにステップの名前を入力します。
次の手順は、Oracle Identity Federation認証を有効にしたタイミング(このスキームの作成前か後か)によって異なります。
プラグインの順序が、credential_mapping、validate_password、credential_mappingの場合は、最後のcredential_mappingプラグインを選択して「追加」をクリックします。
プラグインの順序が、credential_mapping、credential_mapping、validate_passwordの場合は、最初のcredential_mappingプラグインを選択して「追加」をクリックします。
「保存」をクリックします。
「認証フロー」タブをクリックします。
「変更」をクリックします。
新しいステップを「開始ステップ」として選択します。
「成功時の次のステップ」で「停止」を選択します。
「失敗時の次のステップ」で「停止」を選択します。
「保存」をクリックします。
「ステップ」タブをクリックします。
古いステップを選択します。「削除」をクリックします。
「プラグイン」タブをクリックします。
「変更」をクリックします。
Oracle Identity Federationユーザー名が指定されているプラグイン・パラメータを持つ、validate_passwordプラグインとcredential_mappingプラグインを選択します。
「削除」→「保存」の順にクリックします。
このアクションの後には、プラグイン・パラメータに文字列%OIFUSERID%を含むcredential_mappingプラグインのみが残ります。
Oracle Identity Federation認証の無効化
認証を無効にするには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「SP統合モジュール」→「Oracle Access Manager」の順に移動します。
Oracle Identity Federation認証を無効にします。
「Oracle Access Managerの構成」をクリックして変更を適用します。
このアクションの後は、フェデレーション・スキームを呼び出しても、Oracle Identity Federationから認証用の資格証明が送信されることはなくなります。
Oracle Identity Federationの再有効化
Oracle Access ManagerへのOracle Identity Federation認証を無効にした後で再び有効にするには、第3.2.4.2「既存のフェデレーション・スキームを使用した認証の有効化」の手順に従います。
この項では、Oracle Directory Server Enterprise Edition(以前のSun Java System Web Server)とOracle Identity Federationを統合して、Webプロキシとして動作させる方法について説明します。
この項には、次の項目が含まれます。
Oracle Identity Federationの前面でプロキシを使用する場合は、プロキシ・サーバー・インスタンスのホスト名とポート番号が、Oracle Identity Federationへのアクセスに使用され、Oracle Identity Federationの構成に設定されます。
まずOracle Identity Federationをインストールして構成し、デプロイメントで必要なバックエンド(LDAP、RDBMS、Oracle Access Managerなど)と統合します。内容は次のとおりです。
Oracle Identity FederationをSSO SAMLプロトコル用に構成します。
Oracle Identity Federationのフェデレーションに信頼できるプロバイダを追加します。
Oracle Identity Federationとバックエンドの統合
Webプロキシ・サーバーの背後にOracle Identity Federationを構成する場合の手順は、次を除いて、Webプロキシ・サーバーを使用しない環境で実行した手順(第3.2.5.2項「Webプロキシ・サーバーを使用しないOracle Identity Federationの構成」を参照)と同じです。
Webプロキシ・サーバーは、Oracle Identity Federationを参照するように構成されます。
Oracle Identity Federationの構成は、Webプロキシ・サーバーのホスト名とポート情報を使用します。
標準的な手順(第3.2.5.2項「Webプロキシ・サーバーを使用しないOracle Identity Federationの構成」を参照)に従ってOracle Identity Federationを構成しますが、次の点を変更します。
構成URLを各構成のプロキシ・サーバーのURLに変更します。
Fusion Middleware Controlで、「管理」→「サーバー・プロパティ」の順に移動します。
実際のURLではなくプロキシのURLを使用してメタデータを収集した後で、そのメタデータをアップロードします。
「管理」→「セキュリティおよび信頼」の順に移動し、メタデータを取得します(メタデータのホスト名/ポート情報に新しい値が使用されるようになります)。リモート・プロバイダにメタデータを配布します。
アクセス・システム・コンソールで、ホスト識別子を次の形式で作成します。
proxy-host:port
次に、認証スキームのチャレンジ・リダイレクトをproxy-host:portに変更します。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
Sun Oneプロキシ・サーバーのOracle Identity Federation用構成の詳細は、『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』のobj.confファイルの変更に関するガイドラインを参照してください。
これでユーザーはWebサーバー・プロキシを経由してOracle Identity Federationにアクセスできるため、Oracle Access ManagerなどのIAMサーバーも同様に、ローカルのOracle Identity Federationマシンではなくプロキシを参照するように更新する必要があります。
Oracle Identity Federation(Oracle Access ManagerやOracle Single Sign-Onなど)を参照するバックエンドに移動し、Oracle Identity Federationがインストールされているローカル・マシンのかわりにWebプロキシ・サーバーのホスト名/ポートの値を使用するように構成を更新します。
Webプロキシ・サーバーは、Oracle Identity FederationがインストールされているマシンにHTTPリクエストを転送する必要があります。
この項では、obj.confおよびmagnus.conf構成ファイルのサンプルを示します。
サンプルのobj.confファイル
<Object name="default"> AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true" NameTrans fn="assign-name" from="/*" name="serverexample" NameTrans fn="ntrans-j2ee" name="j2ee" NameTrans fn=pfx2dir from=/mc-icons dir="/home/pfx/SunOne6.1/ns-icons" name="es-internal" NameTrans fn=document-root root="$docroot" PathCheck fn=unix-uri-clean PathCheck fn="check-acl" acl="default" PathCheck fn=find-pathinfo PathCheck fn=find-index index-names="index.html,home.html,index.jsp" ObjectType fn=type-by-extension ObjectType fn=force-type type=text/plain Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file Service method=TRACE fn=service-trace Error fn="error-j2ee" AddLog fn=flex-log name="access" </Object> <Object name="j2ee"> Service fn="service-j2ee" method="*" </Object> <Object name="cgi"> ObjectType fn=force-type type=magnus-internal/cgi Service fn=send-cgi user="$user" group="$group" chroot="$chroot" dir="$dir" nice="$nice" </Object> <Object name="es-internal"> PathCheck fn="check-acl" acl="es-internal" </Object> <Object name="send-compressed"> PathCheck fn="find-compressed" </Object> <Object name="compress-on-demand"> Output fn="insert-filter" filter="http-compression" </Object> # Execute these instructions for any resource with the assigned name # "server.example.com" <Object name="serverexample"> # Proxy the requested resource to the URL # "http://server.example.com:8080" Service fn="service-passthrough" servers="http://unit1.mycorp.co.in:1234" </Object>
サンプルのmagnus.confファイル
# # The NetsiteRoot, ServerName, and ServerID directives are DEPRECATED. # They will not be supported in future releases of the Web Server. NetsiteRoot /home/pfx/SunOne6.1 ServerName calgary ServerID https-oif_idp_flagstaff # RqThrottle 128 DNS off Security off PidLog /home/pfx/SunOne6.1/https-oif_idp_flagstaff/logs/pid User pfx StackSize 131072 TempDir /tmp/https-oif_idp_flagstaff-65cd125c Init fn=flex-init access="$accesslog" format.access="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%" Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/lib/libj2eeplugin.so" shlib_flags="(global|now)" Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/passthrough/plugins/passthrough /libpassthrough.so"
Oracle Identity Federationには、シングル・サインオンのテスト用としてテストSPエンジンが用意されています。後続の項では、テストSPエンジンの使用方法について説明します。
|
注意: 本番環境では、テストSPエンジンを無効にする必要があります。 |
テストSPエンジンを有効/無効にするには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ統合モジュール」の順に移動します。
「SPエンジンのテスト」タブで、エンジンの有効化を選択/選択解除します。
テストSPエンジンをデフォルトのSPエンジンにするには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ統合モジュール」の順に移動します。
「デフォルトSP統合モジュール」で、テストSPを選択します(注意: テストSPエンジンを有効にする必要があります)。
テスト・エンジンを使用するには、次のURLでシングル・サインオン・フローを開始します。
HTTP://OIF-SP-HOST:OIF-SP-PORT/fed/user/testspsso
ここで、
HTTPは、オープン接続の場合はhttp、セキュア接続の場合はhttpsです。
OIF-SP-HOSTは、Oracle Identity Federationサービス・プロバイダ・サーバーのホスト名です。
OIF-SP-PORTは、Oracle Identity Federationサービス・プロバイダ・サーバーのhttpまたはhttpsポート番号です。ポート80またはポート443に対しては、入力を省略します。
「SSOの開始」ボタンをクリックすると、ページで指定した情報でシングル・サインオンが開始されるようにOracle Identity Federationサービス・プロバイダにリクエストが送信されます(つまり、アイデンティティ・プロバイダに認証リクエストが送信されます)。次のパラメータを指定できます。
IdPプロバイダID: サービス・プロバイダが認証リクエストを送信するアイデンティティ・プロバイダのプロバイダIDまたは説明です。
認証リクエスト・バインディング: サービス・プロバイダのバインディングを認証リクエストの送信に使用するように指定します。SAML 2.0プロトコルにのみ適用されます。
強制認証: 選択した場合、以前の認証コンテキストを信頼するかわりに、アイデンティティ・プロバイダが強制的にユーザーを認証します。SAML 2.0およびWS-Fedプロトコルにのみ適用されます。
パッシブ: 選択した場合、アイデンティティ・プロバイダとユーザーとの対話は行われません。SAML 2.0プロトコルにのみ適用されます。
リレー状態: このフィールドには任意の文字列を入力できます。これは、リクエストの識別子または戻りURLのいずれかです。Oracle Sign-Onフローが実行された後にリレー状態として返されます。
デフォルト構成を使用: 選択した場合、Oracle Identity Federationは次のプロパティに対してデフォルトの構成を使用します。
フェデレーション作成を許可
SSOレスポンス・バインディング
名前IDフォーマット
リクエストされた認証メカニズム
認証メカニズムの比較
選択しない場合は、次が適用されます。
フェデレーション作成を許可: 選択しない場合は、ユーザーのフェデレーションが存在しない場合でも、アイデンティティ・プロバイダはフェデレーションを作成しません。SAML 2.0プロトコルにのみ適用されます。
SSOレスポンス・バインディング: アイデンティティ・プロバイダがサービス・プロバイダにレスポンスを送信する際に使用するバインディングを指定します。SAMLプロトコルにのみ適用されます。
名前IDフォーマット: ここで指定する名前IDフォーマットは、ユーザーのフェデレーションの検索時または作成時にアイデンティティ・プロバイダが使用するようにサービス・プロバイダによってリクエストされます。SAML 2.0プロトコルにのみ適用されます。
リクエストされた認証メカニズム: サービス・プロバイダが使用するローカル認証メカニズムを指定します。サービス・プロバイダはこのローカル・メカニズムをプロトコル固有の方式にマップし、アイデンティティ・プロバイダに対して認証リクエストでこの方式を指定します。(第5.14.1項「認証メカニズムについて」を参照してください。)SAML 2.0およびWS-Fedプロトコルにのみ適用されます。
認証メカニズムの比較: SAML 2.0を使用している場合は、使用する認証メカニズムをアイデンティティ・プロバイダが決定する際に使用するコンパレータを指定します。オプションは次のとおりです。
EXACT: アイデンティティ・プロバイダは、リクエストされた認証メカニズムを使用する必要があります。
MINIMUM: アイデンティティ・プロバイダは、最低でもリクエストされた認証メカニズムと同じ強度のメカニズムを使用する必要があります。
BETTER: アイデンティティ・プロバイダは、リクエストされた認証メカニズムよりも高い強度のメカニズムを使用する必要があります。
MAXIMUM: アイデンティティ・プロバイダは、リクエストされた認証メカニズムの強度の範囲内で、可能なかぎり強いメカニズムを使用する必要があります。
IdPが開始するシングル・サインオンをテストするためにテストSPエンジンを使用することもできます。サービス・プロバイダでは、テストSPエンジンを有効にし、テストSPをデフォルトSPエンジンとして構成した後で、IdPが開始するSSOをアイデンティティ・プロバイダから開始するだけです。テストSPエンジンにはシングル・サインオン処理の結果が表示されます。
シングル・サインオンを実行すると、次のような操作の結果がテストSPエンジンに表示されます。
SSO認証結果: 操作が成功したかどうか。
ユーザー識別子: シングル・サインオンが行われたユーザーのユーザーID。
認証インスタント: ユーザーを認証したアイデンティティ・プロバイダのインスタント。
セッション失効インスタント: ユーザー・セッションが無効になるインスタント。
認証メカニズム: ユーザーの認証に使用されたローカル・メカニズム。
SSOプライマリ・ステータス・コード: アイデンティティ・プロバイダから受信したアサーションのプライマリ・ステータス・コード。
SSOセカンダリ・ステータス・コード: アイデンティティ・プロバイダから受信したアサーションのセカンダリ・ステータス・コード。
SSOステータス・メッセージ: アイデンティティ・プロバイダから受信したアサーションのステータス・メッセージ。
IdPプロバイダID: ユーザーを認証したアイデンティティ・プロバイダのプロバイダID。
アイデンティティ・プロバイダから受信したアサーションに含まれる属性のリスト。次のとおりです。
orafed-providerid: ユーザーを認証したアイデンティティ・プロバイダのプロバイダID。
orafed-nameid-format: ユーザー・フェデレーションの名前IDフォーマット。
orafed-nameid-value: ユーザー・フェデレーションの名前ID。
orafed-assertionid: アイデンティティ・プロバイダから受信したアサーションのID。
アイデンティティ・プロバイダから受信したアサーションに含まれる任意のユーザー属性。
この項では、Oracle Identity Federationのアップグレード後に管理者が行う必要のあるアクションについて説明します。
リリース10gから11gへのアップグレード時に、アップグレード・アシスタントによって、Oracle Identity Federation 10g Liberty/SAML2.0署名鍵/証明書が、SAML2.0/SAML1.x/WS-Fed操作で使用するOracle Identity Federation 11gインスタンスの署名証明書として移行されます。
SAML 1.x/WS-Fedメッセージの署名にOracle Identity Federation 10gサーバーを使用していた場合、次の2つのオプションがあります。
SAML1.x/WS-Fed鍵/証明書を、すべてのプロトコル(SAML2.0/SAML1.x/WS-Fed)のOracle Identity Federation 11g署名鍵/証明書として維持します。
これを実装するには、10gキーストアを11g署名キーストアとしてアップロードします。10gキーストアは、Oracle Identity Federation管理コンソールの「SAML 1.x/WSフェデレーション」→「署名者」にあります。11gキーストアは、Fusion Middleware ControlでOracle Identity Federationインスタンスに移動すると、「セキュリティおよび信頼」セクションにあります。
変更後にSAML2.0メタデータをリモート・パートナに再分配して、新しい署名証明書をパートナが使用できるようにする必要があります。
SAML 2.0署名鍵/証明書を、Oracle Identity Federation 11gサーバーの署名鍵/証明書として維持します。
これを実装するには、すべてのSAML 1.x/WS-Fedパートナに対して新しい署名証明書を提供する必要があります。
