| Oracle Identity Federation管理者ガイド 10g（10.1.4.0.1） B31476-02 |
|
 戻る |
 次へ |
この章では、IDおよびアクセス管理システム、Webサーバーおよびバックエンド・データ・ストアとの統合など、主なデプロイ・シナリオについて説明します。内容は次のとおりです。
Oracle Identity Federationは、異機種間システム環境で動作し、アイデンティティ・プロバイダ、サービス・プロバイダ、データ・ストアおよびWebサーバーとして機能する幅広いアプリケーションと連携できます。
デプロイメントの問題および質問を解決するには、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。この章では、デプロイメントの計画に役立つ広範なバックグラウンド情報が説明されています。
「アーキテクチャ・オプション」では、サポートされているプロトコルおよびプロファイルに関する詳細と、デプロイメント・オプションを評価する際の考慮事項について説明しています。
「サイジングのガイドライン」では、パフォーマンスに影響を与える要因と、トポロジに関する推奨事項について説明しています。
「実装チェックリスト」は、デプロイメント用のチェックリストです。
次の項では、フェデレーテッド環境の主要なコンポーネントと連携するようにOracle Identity Federationを構成する手順について段階的に説明します。
この項では、一般的なOracle Identity Federationのデプロイ・シナリオについて説明します。内容は次のとおりです。
この項では、OracleAS Single Sign-Onと統合するようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。
この方法でデプロイすると、Oracle Identity Federationは、ローカル・ユーザー認証が必要な場合に、OracleAS Single Sign-Onが提供する認証機能を利用することができます。Oracle Identity Federationは次のことが可能です。
アイデンティティ・プロバイダとして動作してユーザーを認証し、任意の第三者にユーザーの認証情報を提供します。または
サービス・プロバイダとして動作して、ユーザーを認証するためにアイデンティティ・プロバイダから入手した認証データを使用します。
このデプロイを実行する手順を簡単にまとめると、次のようになります。
拡張インストール・モードを使用してOracle Identity Federationをインストールし、その際、フェデレーション・データをOracle Internet Directoryに格納することを選択します。オプションで、一時データをデータベースに格納します。
Oracle Identity FederationをOracleAS Single Sign-Onと統合します。これは、OracleAS Single Sign-On環境を更新してOracle Identity Federationを認証メカニズムとして追加し、サーバー・インスタンスをOracleAS Single Sign-Onに関連付けることを含みます。
Oracle Identity Federation構成を更新してOracleAS Single Sign-OnおよびOracle Internet Directoryサーバーのための接続詳細を提供し、トラスト・サークルのピア・プロバイダとメタデータを交換します。
次に、これらの手順の詳細を説明します。
Oracle Identity Federationのインストール
次のインストール手順を実行します。
Oracle Universal Installerを起動します。製品として「Oracle Identity Federation 10g」を選択し、「拡張」インストール方式を選択します。
「フェデレーション・データ・ストアの指定」画面で、ディレクトリ・サーバーのタイプに「Oracle Internet Directory」を選択して、サーバーについての情報を入力フィールドに入力します。次の例では、Oracle Internet Directoryサーバーのホスト名とポートは、それぞれ、infra.example.comと389です。
| フィールド | サンプル値 |
|---|---|
| ホスト | infra.example.com |
| ポート | 389 |
| バインドDN | cn=orcladmin |
| パスワード | orcladminのパスワード |
|
注意: これらのLDAP接続資格証明は、フェデレーション・データ・スキーマを使用してディレクトリを更新するためにだけ使用されます。通常は、後で、実行時ディレクトリ・アクセスのために様々な資格証明が構成されます。 |
「データベース内のフェデレーション一時データ」のオプションを選択した場合、データベース・ユーザーは表を作成する権限を持っている必要があります。
一時データのためにシステムの表領域を使用するよりは、表領域をこのユーザーに割り当てることをお薦めします。たとえば、SQL*Plusを使用して、ユーザーsysdbaとしてデータベースに接続した場合、次のコマンドを使用すると、oifdbという名前のユーザーが作成され、そのユーザーに表領域が割り当てられます。
create tablespace ts_oifdb logging datafile '/scratch/Oracle/i0120/oradata/i0120/ts_oifdb.dbf' size 512m autoextend on extent management local; create user oifdb identified by oifdb default tablespace ts_oifdb; grant connect,resource to oifdb; alter user oifdb account unlock;
「フェデレーション一時データ・ストアの指定」画面で、データベース接続情報（ユーザー名、パスワード、ホスト、ポートおよびWebサービス名）を入力します。
フェデレーション・サーバーID、インスタンス名および管理者パスワードを指定して、残りのOracle Identity Federationインストール手順を完了します。
Oracle Identity FederationとOracleAS Single Sign-Onの統合
次の手順では、まずOracle Identity Federationサーバー・ホストをOracleAS Single Sign-Onに認識させ、次にOracle Identity FederationインスタンスをOracleAS Single Sign-Onに関連付けます。
Oracle IdM/Infrastructureのホームで、sso/conf/policy.propertiesファイルの次の行をコメント解除して変更します。ここで、oif.example.com:7780はOracle Identity Federationサーバーのホストとポートです。
SASSOAuthnUrl = http\://oif.example.com\:7780/sso/authn SASSOLogoutUrl = http\://oif.example.com\:7780/sso/jsp/sasso_logout_success.jsp SASSOAuthLevel = MediumHighSecurity
sso/conf/policy.propertiesファイルに次の行を追加します。ここで、content.example.com:8888はリソース・サーバーのホストとポートです。
content.example.com\:8888 = MediumHighSecurity
MediumHighSecurity_AuthPlugin =
oracle.security.sso.server.auth.SASSOAuth
Oracle Identity Federation HOMEからInfrastructureホームにSSOキーストアをコピーします。次に例を示します。
cp OIF_HOME/sso/conf/keystore INFRA_HOME/sso/conf/
通常と同様にパートナ・アプリケーションをOracleAS Single Sign-Onに登録します。たとえば、/scratch/protected/index.htmlにリソースがあり、仮想ホストが140.87.26.53:8888の場合は、InfrastructureホームのApache/Apache/conf/httpd.confファイルを次のように編集します。
LoadModuleセクションの末尾にある<IfDefine SSL>の前に、次のいずれかの行を追加します。
Linuxの場合:
LoadModule osso_module libexec/mod_osso.so
Windowsの場合:
LoadModule osso_module modules/ApacheModuleOSSO.DLL
Windowsではまた、AddModuleセクションの末尾にある<IfDefine SSL>の前に次の行を追加します。
AddModule mod_osso.c
「# Include the configuration files needed for mod_oc4j」の前に次の行を追加します。
Listen 8888
NameVirtualHost 140.87.26.53:8888
<VirtualHost 140.87.26.53:8888>
ServerName content.example.com
DocumentRoot "/scratch/protected"
OssoConfigFile
"/scratch/Oracle/i0120/Apache/Apache/conf/osso/osso-app.conf"
OssoIpCheck off
<Location /index.html>
AuthType basic
Require valid-user
</Location>
</VirtualHost>
ssoregスクリプトを実行します。Linuxではssoreg.sh、Windowsではssoreg.batがそれに該当します。次に例を示します。
sso/bin/ssoreg.sh -oracle_home_path /scratch/Oracle/i0120
–site_name content.example.com –config_mod_osso TRUE
–mod_osso_url http://content.example.com:8888 –virtualhost
–config_file
/scratch/Oracle/i0120/Apache/Apache/conf/osso/osso-app.conf
Infrastructureを再起動します。
opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY opmn/bin/opmnctl restartproc process-type=HTTP_Server
Oracle Identity FederationインスタンスをOracleAS Single Sign-Onに関連付けるには、WebブラウザでOracle Identity Federation Enterprise Managerコンソールを開きます。次に例を示します。
http://infra.example.com:1810/emd/console
次の手順を実行します。
「インフラストラクチャ」→「ID管理」に移動し、「変更」ボタンをクリックします。
Oracle Internet Directoryのホストとポートを入力し、「次へ」をクリックします。
Oracle Internet Directoryのユーザー名（たとえばcn=orcladmin）とパスワードを入力し、「次へ」、「終了」の順にクリックします。
Enterprise Managerのメイン・ページで、Oracle HTTP Server、ホームおよびOC4J_FEDを再起動します。
Oracle Identity Federationの構成
次の手順では、まずデータ・ストアに接続するために必要な情報をOracle Identity Federationに提供し、次にOracle Identity Federationメタデータを更新してピア・プロバイダに配布します。
WebブラウザでOracle Identity Federation管理コンソールを開きます。
http://oif.example.com:7780/fedadmin
oif_adminとしてログインします。
「IDMデータ・ストア」→「ユーザー・データ・ストア」画面で、「OracleAS Single Sign-On」を選択し、接続情報を入力します。次に例を示します。
| フィールド | 値の例 |
|---|---|
| 接続URL: | ldap://infra.example.com:389
これはOracleAS Single Sign-Onによって使用されるOracle Internet Directoryのインスタンスです。 |
| バインドDN: | cn=orcladmin |
| パスワード: | orcladminのパスワード |
| ユーザーID属性: | uid |
| ユーザー説明属性: | uid |
| 個人オブジェクト・クラス: | inetorgperson |
| ベースDN: | dc=example,dc=com |
| 他のプロパティのデフォルト値 | |
| OSSOログインURL: | http://infra.example.com:7777/sso/auth |
| OSSOログアウトURL: | http://infra.example.com:7777/sso/logout |
「IDMデータ・ストア」→「フェデレーション・データ・ストア」画面で、「LDAPディレクトリ」を選択し、接続情報を入力します。次に例を示します。
| フィールド | サンプル値 |
|---|---|
| 接続URL: | ldap://infra.example.com:389
これはOracleAS Single Sign-Onによって使用されるOracle Internet Directoryのインスタンスです。 |
| バインドDN: | cn=orcladmin |
| パスワード: | orcladminのパスワード |
| ユーザー・フェデレーション・レコード・コンテキスト: | cn=fed,dc=example,dc=com |
| LDAPコンテナ・オブジェクト・クラス: | <blank> |
| 一意フェデレーションID属性: | <blank> |
「保存」をクリックします。
Oracle Identity Federation Enterprise Managerのコンソールに移動して、OC4J_FEDを再起動します。
Oracle Identity Federation管理コンソールに移動し、「サーバー構成」→「トラスト・サークル」画面にナビゲートします。
「信頼できるプロバイダの追加」セクションで、ピア・プロバイダのメタデータXML文書のファイル・システムの場所を参照し、そのプロバイダを説明するテキストを入力します。「追加」をクリックし、続いて「完了」をクリックします。「サーバーのリフレッシュ」をクリックします。
Oracle Identity Federationをサービス・プロバイダに構成する場合は、「サーバー構成」→「サービス・プロバイダ」→「グローバル設定」画面に移動し、リスト・ボックスから「デフォルトSSOアイデンティティ・プロバイダ」を選択します。
「保存」、「サーバーのリフレッシュ」の順にクリックします。
トラスト・サークル内の各ピア・プロバイダは、Oracle Identity FederationメタデータXML文書のコピーを必要とします。まず特定のサーバー・ロール（SPまたはIdP）と、該当するフェデレーション・プロトコル・バージョン（Liberty 1.1, 1.2またはSAML 2.0）に対応するメタデータURLにアクセスします。次に例を示します。
http://oif.example.com:7780/fed/sp/metadatav20
http://oif.example.com:7780/fed/idp/metadatav20
URLから取得したXMLファイルを保存し、トラスト・サークル内の他のプロバイダに配布します。別のOracle Identity Federationインスタンスをトラスト・サークルの一部として設定している場合は、これが「トラスト・サークル」画面の「信頼できるプロバイダの追加」を使用してロードするファイルになります。
この項では、Oracle Access Managerと統合されるようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。この手順では、2つのノードから構成されるデプロイ・シナリオを説明します。
host_aと呼ばれるノードA（host-a.us.oracle.comというタイプの、関連付けられたURLを持つ）は、サービス・プロバイダ（SP）タイプのサーバーです。
host_bと呼ばれるノードB（host-b.us.oracle.comというタイプの、関連付けられたURLを持つ）は、アイデンティティ・プロバイダ（IdP）タイプのサーバーです。
この項は、インストールするコンポーネントおよびデプロイメント・タスクの違いに応じて、別々の手順に別れています。
この項では、OracleAS Infrastructureのインストール方法を説明します。
|
注意: Oracle Access ManagerとともにOracleAS Infrastructureをインストールする必要があるのは、Oracle Access ManagerがディレクトリとしてOracle Internet Directoryを使用する場合だけです。それ以外の場合は、OracleAS Infrastructureをインストールする必要はありません。 |
Oracle Universal Installerを起動して、「Oracle Application Server Infrastructure 10g」インストール・オプションを選択します。
「Identity Management and Metadata Repository」を選択します。
デフォルトの構成オプションを使用します。
インストールが完了したら、データベース接続を確立します。
coraenvスクリプトを実行して、ORACLE_SIDおよびORACLE_HOMEの各変数に適切な値を設定します。
次のようにしてデータベースに接続します。
sqlplus '/ as sysdba'
次のSQLコマンドを実行します。
create tablespace ts_fd
logging
datafile '/scratch/aswu/Oracle/i0120/oradata/i0120/ts_fd01.dbf'
size 512m autoextend off,
'/scratch/aswu/Oracle/i0120/oradata/i0120/ts_fd02.dbf'
size 512m autoextend off
extent management local;
create user fd identified by fd default tablespace ts_fd; grant connect,resource to fd; alter user fd account unlock;
Oracle Identity Federationとともに使用する場合、いくつかのOracle Access Managerコンポーネントをインストールする必要があります。
アイデンティティ・サーバー
WebPass（Webサーバーにインストール）
アクセス・サーバー
Oracle Access Manager（管理用のUI。WebPassと同じWebサーバーにインストール）
WebGateエージェント（Oracle Identity FederationまたはOracle Access Managerのサイトがサービス・プロバイダ（SP）である場合に、フェデレーテッド・ユーザーが使用できるリソースやサービスを提供する各Webサーバー上にインストール）
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Oracle Access Managerインストール上の考慮事項
Oracle Access Managerをインストールおよびデプロイする際は、Oracle Identity Federationとの統合に重要な影響を及ぼす問題に十分注意してください。
Access Managerコンソールでアクセス・サーバー・エントリを構成する場合、「アクセス管理サービス」を「オン」に設定します。
|
注意: デフォルトでは、「アクセス管理サービス」は「オフ」に設定されています。Oracle Identity Federationでは、このフィールドが「オン」に設定されている必要があります。 |
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
デフォルトのポリシーを有効にする場合は、Oracle Access and Identity Basic Over LDAP認証スキーム（旧称NetPoint Basic Over LDAP認証スキーム）を設定することを強くお薦めします。そうしない場合は、手動で基本スキームを構成する必要があります。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
前述のとおり、Oracle Identity FederationまたはOracle Access Managerのサイトがサービス・プロバイダ（SP）である場合、フェデレーテッド・ユーザーが使用できるリソースやサービスを提供する各Webサーバー上にWebGateエージェントをインストールする必要があります。Webgateをデプロイする場合は、次のことに注意してください。
アクセス管理サービスの設定は、WebGateが使用するアクセス・サーバーの設定に一致している必要があります。このため、Oracle Identity Federationが使用するのと同一のアクセス・サーバーをWebGateが使用する場合は、アクセス管理サービスを「オン」に設定する必要があります。WebGateが、Access Management Serviceが「オフ」に設定されている、（同一ドメインの）異なるアクセス・サーバー・インスタンスを使用することも可能です。その場合、Web設定も「オフ」になります。
プライマリHTTP Cookieドメインを設定して、WebGateがインストールされている複数のWebサーバーでOracle Access Managerシングル・サインオンを有効にするように設定することはよくあります。Cookieドメインは最低でも、Oracle Identity Federationホストと、少なくとも1つのWebGateによって保護されたWebサーバーを含んでいる必要があります。たとえばOracle Identity Federationがホストoif.us.company.comにあり、Webサーバーがwww.us.company.comである場合、ドメイン設定は.us.company.comまたは.company.comになります。Webサーバーがwww.company.comの場合は、ドメイン設定は.company.comになります。注意: Cookieドメインに対するデフォルトのAccessGate設定は空です（ドメインなし）。これが機能するのは、Oracle Identity Federationと、保護されているすべてのリソースが同一のホストにある、非常にまれなデプロイメントだけです。
この項ではOracle Access Managerとともに使用するためにOracle Identity Federationをインストールする方法を説明します。必要手順の簡単な概要を次に示します。詳細は、「拡張インストール手順」を参照してください。
Oracle Universal Installerを起動し、Oracle Identity Federation 10gインストール・オプションを選択します。
インストール方式は「拡張」を選択します。
「構成オプションの選択」で、「LDAPサーバー内のフェデレーション・データ」および「データベース内のフェデレーション一時データ」を選択します。
「フェデレーション・データ・ストアの指定」で、次の情報を入力します。
サーバー・タイプ: Oracle Internet Directory
ホスト/ポート: LDAPサーバーのホストとポート
バインドDN: cn=orcladmin
「フェデレーション一時データ・ストアの指定」で、次の情報を入力します。
ユーザー名
パスワード
ホスト、ポートおよびサービス名: 一時データのデータベース
この項では、Oracle Identity FederationとOracle Access Managerを統合する方法を説明します。Oracle Identity Federation用のAccessGateの構成（Oracle Access Manager）、データ・ストアやその他の構成パラメータの設定（Oracle Identity Federation）など、両方の環境で実行する特定の手順が含まれます。
|
関連資料: 詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
アクセス・システム・コンソールhttp://AMhost:AMport/access/oblix（ここでAMhost:AMportはWebPassとAccess ManagerをインストールするWebサーバー）を使用して、Oracle Identity Federation用にAccessGateを構成します。
「アクセス・システム構成」タブを選択します。
コンソール・パネルから「新規Access Gateの追加」リンクを選択します。
イタリックの値を必要な値に置き換えて、次のようにAccessGateを構成します。
|
注意: AccessGateの名前は任意に選択できます。この例で設定する名前OIFは、単なる説明用です。 |
AccessGate Name: OIF Password: OIF-PASSWORD Hostname: OIF-HOST Port: OIF-PORT Transport Security: Match the Access Servers to be configured in Step d. Access Management Service: On Primary HTTP Cookie Domain: .company.com (Note: As noted in the WebGate configuration, the Primary HTTP Cookie Domain configured for Oracle Identity Federation must match the Primary HTTP Cookie Domains configured for the WebGates protecting the content to be accessed by federated users.) Preferred HTTP Host: OIF-HOST
「保存」をクリックします。
「アクセス・サーバーをリスト」をクリックします。
「追加」をクリックします。
ドロップダウン・メニューから1つ以上のサーバーを選択します。注意: 選択されているすべてのアクセス・サーバーで、アクセス管理サービスが「オン」になる必要があります。
Number of connections: 1
「追加」をクリックします。
必要に応じて、アクセス・システム・コンソールを使用してフェデレーション・ホストIDを構成します。
「アクセス・システム構成」タブを選択します。
コンソール・パネルから「ホスト識別子」リンクを選択します。
ホスト識別子が1つも定義されていない場合は、フェデレーション・ホストIDは不要です。手順3に進みます。
ホスト識別子が定義されたら、「追加」ボタンをクリックします。
Name: Fed HostID
注意: サポート対象のすべての言語で同一である固定値を入力します。
Hostname variables: OIF-HOST:OIF-PORT
注意: OIF-PORTが80または443の場合は、OIF-HOSTも含めます。
「保存」をクリックします。
アクセス・サーバーSDKをインストールします。
AccessServerSDKインストーラ（たとえばOracle_Access_Manager10_1_4_0_1_linux_AccessServerSDK）をOIF_HOME/fed/shareid/で実行します。
Linux上にインストールする場合は、LD_ASSUME_KERNEL環境変数を設定します。
Webブラウザで、Oracle Identity Federationのインストール用のEnterprise Managerコンソールを開きます。次に例を示します。
http://oif.example.org:1810/emd/console
次の手順を実行します。
- 「システム・コンポーネント」で、OC4J_FEDのリンクをクリックします。
- 「管理」→「サーバー・プロパティ」に移動し、「環境変数」で、「環境変数の追加」をクリックします。
- 新規エントリで、「名前」フィールドに「LD_ASSUME_KERNEL」と、「値」フィールドに「2.4.19」と入力します。「追加」チェック・ボックスは選択しないままにしておきます。
- 「適用」をクリックします。
- OC4J_FEDコンテナを再起動するには、「OK」をクリックします。
http://OIF-HOST:OIF-PORT/oifadminにあるOracle Identity Federation管理コンソールに移動します。「IDMデータ・ストア」タブをクリックします。
|
注意: 使用するディレクトリの必要に応じて、パラメータ値（バインドDN、パスワード、DNなど）を置き換えます。 |
フェデレーション・データ・ストアの場合:
Bind DN: cn=orcladmin
Password: your-password
User Federation Record Context: cn=fed,dc=us,dc=oracle,dc=com
ユーザー・データ・ストアの場合:
Active Repository: Oracle Access Manager Connection URL(s): ldap://LDAP-Server-Host:Port Bind DN: cn=orcladmin Password: your-password User ID Attribute: uid User Description Attribute: uid Person Object Class: inetOrgPerson Base DN: dc=us,dc=oracle,dc=com
Oracle Access Manager構成パラメータの場合:
Master Admin Login ID: orcladmin
Master Admin Password: your-password
Authorization result for unprotected resources: Allow
Oracle Access Manager Cookie Domain: .company.com
Basic Authentication Scheme Name: Oracle Access and Identity authentication scheme
|
注意:
|
「適用」をクリックします。
アクセス・サーバーでは次の資格証明を使用します。
アクセス・サーバーのホスト名: access-server-host
|
注意: これは手順1dで構成したサーバーの1つである必要があります。 |
Access Serverポート: access-server-port
Access Gate ID: OIF
Access Gateパスワード: OIF-password
接続タイプ: アクセス・サーバーに一致する必要があります。
Oracle Identity Federationサーバーを再起動します。
統合が完了したことを確認するには、次のようにします。
アクセス・システム・コンソール（http://AMhost:AMport/access/oblix/）にログインします。
「Access Manager」をクリックします。
ポリシー・ドメインに作成されたフェデレーション・ドメインをチェックします。
Oracle Identity Federationによって（サービス・プロバイダとして）リソースを作成するには、次のようにします。
『Oracle Access Managerアクセス管理ガイド』にあるリソースを保護するには、ポリシー・ドメインを使用するリソースの保護に関する章の手順に従います。
認証スキームを次のいずれかに変更します。
フェデレーションSSO - SAML 2.0/Liberty 1.x: SAML 2またはLiberty 1.1または1.2のSSOプロファイルを使用する場合
フェデレーションSSO - WSフェデレーション: WS-Federation Passive RequesterのSSOプロファイルを使用する場合
フェデレーションSSO - SAML 1.x: SAML 1.0または1.1のSSOプロファイルを使用する場合
Oracle Access Managerでの既存の認証スキームおよびフェデレーションSSOの認証スキームのセキュリティ・レベルの構成が、保護されているリソースがアクセスされたときにフェデレーションSSOスキームが選択されるように設定されていることの確認が必要な場合があります。たとえば、フェデレーションSSOの認証スキームのセキュリティ・レベルが1で、基本ログインの認証スキームのセキュリティ・レベルが2の場合、フェデレーテッド・シングル・サインオンに成功しても、ユーザーのログインが常に要求されます。
|
注意: 選択は、パートナのアイデンティティ・プロバイダがサポートするプロトコルによって決定されます。異なるプロトコルを必要とするパートナが同一のリソースにアクセスする場合、リソースURLの異なる別個のポリシーを設定し、リクエストを適切な認証スキームにマップする必要があります。たとえば、SAML 2とWS-Federationの両方を使用してリソース/my-resourceへのアクセスを提供する場合は、次を設定できます。
その後でWebサーバーを構成して、実際のリソース |
この項では、Oracle Identity FederationをeTrust SiteMinderと統合する方法を説明します。この方法でデプロイされると、Oracle Identity FederationはeTrust SiteMinderのIDおよびアクセス管理機能を利用できます。
ここでの説明では、次のフレームワークを前提にしています。
eTrust SiteMinderはIDおよびアクセス管理サーバーです。
eTrust SiteMinderのユーザー・ディレクトリはLDAPサーバーです。
Oracle Identity Federationで使用されるユーザー・データ・ストアはRDBMSです。
SP機能は使用されないため、SiteMinderのネイティブ・ライブラリをeTrust SiteMinderポリシー・サーバーにインストールする必要はありません。
|
注意: Oracle Identity Federationでは、特定のeTrust SiteMinderポリシー・オブジェクトがポリシー・サーバー上に作成される必要があります。Oracle Identity Federationでは通常、初期化時にeTrust SiteMinderポリシー・サーバーを使用してこれらのオブジェクトを自動的に作成しますが、手動で作成することも可能です。Oracle Identity Federationで作成されるポリシー・オブジェクトの例は、「eTrust SiteMinderポリシー・オブジェクト」で説明します。 |
内容は次のとおりです。
eTrust SiteMinderと統合するには、次の要件を満たす必要があります。
Oracle Identity FederationマシンにeTrust SiteMinder SDK 5.5をインストールする必要があります。
eTrust SiteMinderポリシー・サーバーのバージョンが5.5である必要があります。
このデプロイメントでは、Oracle Identity FederationはeTrust SiteMinderエージェントとして機能し、eTrust SiteMinder SDKを使用してeTrust SiteMinderポリシー・サーバーと通信します。SDKをインストールするには、次の手順を実行します。
eTrust SiteMinder SDKバージョン5.5を$ORACLE_HOME/fed/shareid/SiteMinderディレクトリにインストールします。
OC4J_FEDインスタンスを再起動します。
Oracle Identity Federationのユーザー・データ・ストアとして機能するデータベースをOracle Application Server内のデータソースとして定義します。
このようなデータソースを定義する手順は次のとおりです。
Oracle Identity FederationインスタンスのEMコンソールにログインして、「OC4J_FED」→「管理」→「データ・ソース」に移動します。
次の例を参考にして、新しいデータ・ソースを作成します。
Name: myDS
Data Source Class: com.evermind.sql.DriverManagerDataSource
JDBC URL: jdbc:oracle:thin:@stahs08.us.oracle.com:1521:ORCL (enter
the correct connection URL)
JDBC Driver: oracle.jdbc.driver.OracleDriver
Username: CUSTDATA (replace with the username used to access
the RDBMS)
Password: PASSWORD (replace with the password used to access
the RDBMS)
Location: jdbc/RDBMSUserDataSource
Transactional Loc: jdbc/xa/RDBMSUserDataSource
EJB Location: jdbc/RDBMSUserDataSource
|
注意: データベース接続情報が更新されていないとデプロイメント構成が反映されません。詳細は、Oracle Application ServerとOracle JDBCのマニュアルを参照してください。 |
変更を適用します。
次の手順に従って、RDBMSユーザー・データ・ストアを使用するようにOracle Identity FederationとeTrust SiteMinderを構成します。
Oracle Identity Federation管理コンソールにログインし、「IDMデータ・ストア」→「ユーザー・データ・ストア」とナビゲートします。
eTrust SiteMinderをアクティブ・リポジトリ・リストから選択します。
バックエンド・データ・ストアとして「リレーショナル・データベース」を選択し、適切な値を入力します（次の表を参照）。
| フィールド | 例 | 説明 |
|---|---|---|
| JNDI名 | jdbc/RDBMSUserDataSource | Oracle Enterprise Managerコンソールで入力した「EJBロケーション」と一致する必要があります。 |
| ユーザー名 | CUSTDATA | RDBMSへのアクセスに使用するユーザー名に置き換えます。 |
| パスワード | PASSWORD | RDBMSへのアクセスに使用するパスワードに置き換えます。 |
| ログイン表 | EMPLOYEES | ユーザー・レコードを含むRDBMS表の名前に置き換えます。 |
| ログインID列 | EMPLOYEE_ID | ユーザー識別子を含む列名に置き換えます。 |
| ログイン・パスワード列 | 空 | この属性は、認証にeTrust SiteMinderサーバーを使用する構成では使用されません。 |
| パスワード・ダイジェスト・アルゴリズム | なし | パスワード・ダイジェスト・アルゴリズムはこのデプロイメントでは使用しません。 |
| ユーザー説明属性 | EMPLOYEE_ID | 「ログインID列」フィールドで使用されている値に置き換えます。このフィールドは、フェデレーション・レコードの作成に使用されるユーザー識別子を含んでいる列である必要があります。この属性により、可読的な属性をユーザー・フェデレーション・レコードに設定できます。このフィールドは、メインのユーザー識別子が可読的でない場合に役立ちます。この場合、メインのユーザー識別子はユーザー名であるため、そのフィールドを「ログインID列」の値に設定するのみで十分です。 |
「適用」をクリックして変更を保存します。
eTrust SiteMinderポリシー・サーバーへの接続情報を入力します。
ホスト: Oracleポリシー・サーバーがインストールされているホストです。
権限ポート: Oracle認証リクエストで使用されるポリシー・サーバー・ポートです。デフォルト値は44442です。
認証ポート: 認証リクエストで使用されるポリシー・サーバー・ポートです。デフォルト値は44443です。
アカウンティング・ポート: アカウンティング・リクエストで使用されるポリシー・サーバー・ポートです。デフォルト値は44441です。
最大接続数: ポリシー・サーバーへのエージェント接続数の最大値です。
最小接続数: ポリシー・サーバーへのエージェント接続数の最小値です。
ステップ接続数: エージェントが一度にポリシー・サーバーに開ける接続の数です。
タイムアウト: ここで指定した時間が過ぎると、エージェントはポリシー・サーバーからレスポンスを待つのをやめ、エラーを返します（単位は秒）。
次の情報をeTrust SiteMinderエージェントの構成セクションに入力します。
既存のeTrust SiteMinder Webエージェントのエージェント名およびエージェント・シークレットを入力します。このエージェントの資格証明は、Oracle Identity FederationのSMBridgeAgentが存在し、かつ正しく登録されていることを検証するために、起動時に使用されます。
eTrust SiteMinderポリシー・サーバーで使用されるCookieドメインを入力します。Oracle Identity Federationでは、ユーザーのローカル認証時およびSMSESSION Cookieの設定時にこの値を使用します。
Oracle Identity FederationのSMBridgeAgentのパスワードを入力します。このパスワードは、ポリシー・サーバー上のSMBridgeAgentとして識別されているeTrust SiteMinderエージェントのパスワードと一致する必要があります。
次の情報を「自動ポリシー作成」セクションに入力します。
管理者ID: ポリシー・サーバーへのアクセスに使用されるeTrust SiteMinderアカウントのユーザー名です。
管理者パスワード: ポリシー・サーバーへのアクセスに使用されるパスワードです。
ドメイン名: ポリシー・オブジェクトが含まれているドメインです。
ユーザー・ディレクトリ: ドメインのユーザー・ディレクトリです。
この情報は、Oracle Identity Federationで必要なeTrust SiteMinderポリシー・オブジェクトがeTrust SiteMinderポリシー・サーバーに存在することを検証するために、起動時に使用されます。
ポリシーがすでに作成され、正しく構成されている場合、このセクションで指定された資格証明は、読取り権限でのみeTrust SiteMinderアカウントを参照できます。
「適用」をクリックします。
Oracle Identity FederationはeTrust SiteMinderサーバーとは異なるユーザー・データ・ストアを使用するようには設計されていないため、シングル・サインオン・フロー中に正しいユーザー識別子を取得するには次の構成手順が必要です。
Oracle Identity Federation管理コンソールにログインし、「IDMデータ・ストア」→「ユーザー・データ・ストア」とナビゲートします。
eTrust SiteMinderサーバーのバックエンド・データ・ストアとして「LDAPディレクトリ」を選択します。
「ユーザーID属性」フィールドで、ユーザー識別子を含むLDAPユーザー・レコードで使用されている属性を入力します。一般的なLDAPサーバーでは、uidに設定します。
「適用」をクリックします。
「IDMデータ・ストア」→「ユーザー・データ・ストア」とナビゲートします。
バックエンド・データ・ストアとして「リレーショナル・データベース」を選択します。
「適用」をクリックします。
OC4J_FEDを再起動します。
次の条件を満たすようにeTrust SiteMinder Webエージェントを構成する必要があります。
Oracle Identity FederationでSMSESSION Cookieを使用できるように、WebエージェントはSMSESSION Cookie上のドメインを指定する必要があります。
Oracle Identity FederationのeTrust SiteMinderエージェントがユーザーを認証する場合、WebエージェントはOracle Identity Federationで設定されたSMSESSION Cookieを受け入れる必要があります。
Webエージェントの構成を変更する前に、次の手順に従って、エージェントがローカル構成ファイルを使用しているかどうかを判断します。
SMSESSION Cookieを設定するeTrust SiteMinder Webエージェントを識別します。これは、ユーザーを認証するエージェントです。
eTrust SiteMinder管理コンソールに移動します。
Webエージェント構成オブジェクト・セクションに移動します。
手順1で識別したeTrust SiteMinder Webエージェントに対応するエントリを選択します。
リストでAllowLocalConfigパラメータを検索します。
次のアクションは、このパラメータの値によって異なります。
AllowLocalConfigパラメータの値が"Yes"の場合は、eTrust SiteMinder WebエージェントのWebAgent.confファイルを変更する必要があります。
このファイルは通常、Webエージェントがインストールされているマシンの、eTrust SiteMinder Webエージェントのバイナリおよび構成ファイルがインストールされているディレクトリにあります（$HOME\Netegrity\SiteMinder Web Agent\Bin\$HTTP_SERVER_NAME\WebAgent.conf）。ここで、$HOMEはeTrust SiteMinder Webエージェントのインストール・ディレクトリの親ディレクトリであり（c:\Program Filesなど）、$HTTP_SERVER_NAMEはWebエージェントと統合されているHTTP Webサーバーに対応するディレクトリ名です（eTrust SiteMinder WebエージェントがMicrosoft IISと統合されている場合、IISなど）。
このWebAgent.confファイルで、次のパラメータを追加します。
CookieDomain=".domain.com"
次に、.domain.comをデプロイ対象ドメインに置き換えます。
変更を保存してHTTPサーバーを再起動し、Webエージェントの構成のリロードをWebエージェントに強制します。
AllowLocalConfigパラメータの値が"No"の場合は、次の手順に従って、eTrust SiteMinderポリシー・サーバーのWebエージェント構成オブジェクトを変更する必要があります。
eTrust SiteMinder Webエージェントのエントリに移動します。
Webエージェント構成オブジェクト・セクションに移動します。
CookieDomainパラメータを検索し、この値をデプロイ対象ドメインに設定します。
変更を保存してHTTPサーバーを再起動し、Webエージェントの構成のリロードをWebエージェントに強制します。
Webエージェントでローカル構成ファイルを使用しているかどうかを判断するために使用したものと類似した手順に従って（「Cookieドメインの更新」を参照）、AcceptTPCookieプロパティを"Yes"に更新し、Oracle Identity Federationで設定されたSMSESSION CookieをeTrust SiteMinder Webエージェントで使用できるようにします。
このプロパティは、ユーザーがOracle Identity Federationサーバーで最初に認証される場合に必要です。
この項では、Oracle Identity Federation/eTrust SiteMinderコネクタの初期化後にeTrust SiteMinderポリシー・サーバーで生成されるポリシー・オブジェクトの例を示します。
#! SiteMinder Version 5.5
# Export Flags: Encrypted.
objectclass: Scheme
Oid: 0d-9a73cf80-225b-4267-8788-c9d1dd6f49b1
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
Level: 1
Lib: smauthdir
Param:
Secret: {RC2}XCoISknMgVRXLjoLd/Fzkg==
IsTemplate: false
IsUsedbyAdmin: false
Type: 1
AllowSaveCreds: false
IsRadius: false
IgnorePwCheck: false
objectclass: Scheme
Oid: 0d-afefd918-eb06-4322-bb54-5095c2a62976
Name: OracleFederation_LoginNoPwd
Desc: Automatically created by SHAREid. Do not modify.
Level: 1
Lib: smanapi
Param:
Secret: {RC2}zlnvNoQWQLsgkpm5lDGtnA==
IsTemplate: false
IsUsedbyAdmin: false
Type: 15
AllowSaveCreds: false
IsRadius: false
IgnorePwCheck: false
objectclass: Agent
Oid: 01-989a3b03-5f9a-4714-9e4c-8ce2e08914af
Name: oif_agent
Desc: oif_agent
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
RealmHintAttrId: 0
objectclass: TrustedHost
Oid: 24-e49e94f7-f914-49be-92ed-a10685759ad2
Name: oif_agent
Desc: oif_agent
IpAddr: 140.87.155.127
Secret: {RC2}4eRzjIbX82w6r2Ke+ph3KA==
Is4xHost: true
objectclass: Agent
Oid: 01-fe46c0bd-2802-4a3e-8dcf-a68a4f3eb40c
Name: smbridgeagent.oif1.staqk10vm4.us.oracle.com
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
RealmHintAttrId: 0
objectclass: TrustedHost
Oid: 24-ca92dc34-8ebc-4c83-9bbd-001c33542fb3
Name: smbridgeagent.oif1.staqk10vm4.us.oracle.com
Desc:
IpAddr: 140.87.155.130
Secret: {RC2}z3gdtk5parnuWkqt73fGPA==
Is4xHost: true
objectclass: AgentGroup
Oid: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
Name: OracleFederation
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Agents: 01-fe46c0bd-2802-4a3e-8dcf-a68a4f3eb40c
objectclass: Domain
Oid: 03-1c7ac22e-6646-4c61-8f2f-6261a0ef3a92
Name: FederationWebServicesDomain
Desc:
Realms: 06-a0cf82a7-d831-453d-ac9e-8ed814f90369
UserDirectories: 0e-08c6cadb-e30b-4e06-9e2e-b3d7a866fab8
Rules: 0b-ebe4b3ce-5a34-4a64-b67b-d1e64dee414d, 0b-3d48caac-a7d5-4cf7-8722-ea9ed257fa42, 0b-7f5c5171-8af3-48b0-897c-89d02ac15d43
RuleGroups:
Responses:
ResponseGroups:
Policies: 04-3d844415-ee88-46f0-b646-cfbc57e248b8, 04-6d11edc8-b6f4-4522-a956-b3ad263705fb, 04-70d60545-5316-49c3-ac96-ae5c75b7efe8
Admins:
Variables: 1d-dad4d124-7518-4b67-b72c-b4ef76622eb3, 1d-98031368-1b9d-4d40-b572-91cef289f497
ActiveExprs: 1f-ec5691c8-b45c-4ed7-8d69-95e1caa6c8ef, 1f-bcf186ea-cd60-4e9c-96c3-5d3076090ce1
IsAffiliate: false
IMSEnvs:
Mode: 0
objectclass: Realm
Oid: 06-09c376b0-44f4-4aa1-b076-52fe1ca05309
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
ResourceFilter: /OracleFederation/Login
Agent: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Scheme: 0d-9a73cf80-225b-4267-8788-c9d1dd6f49b1
ProcessAuthEvents: true
ProcessAzEvents: true
ProtectAll: true
SelfRegOid: 00-
AzUserDirOid: 00-
MaxTimeout: 0
IdleTimeout: 0
ParentRealmOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
SyncAudit: false
Type: 0
SessionType: 0
SessionDrift: -1
objectclass: Realm
Oid: 06-e076704c-2d8e-4c10-83f0-6d67e2c38163
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_LoginNoPwd
Desc: Automatically created by SHAREid. Do not modify.
ResourceFilter: /OracleFederation/LoginNoPwd
Agent: 02-70eb00c8-30f4-4f9e-8e46-722014a42e02
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Scheme: 0d-afefd918-eb06-4322-bb54-5095c2a62976
ProcessAuthEvents: true
ProcessAzEvents: true
ProtectAll: true
SelfRegOid: 00-
AzUserDirOid: 00-
MaxTimeout: 0
IdleTimeout: 0
ParentRealmOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
SyncAudit: false
Type: 0
SessionType: 0
SessionDrift: -1
objectclass: Rule
Oid: 0b-0bac8120-dd43-45a4-badd-5f56df272c2a
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_Login
Desc: Automatically created by SHAREid. Do not modify.
Realm: 06-09c376b0-44f4-4aa1-b076-52fe1ca05309
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Action: Get
Resource: *
Time: 00000000-00000000-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
AllowAccess: true
RegularExpression: false
IsEnabled: true
ActiveExpr: 00-
Variables:
objectclass: Response
Oid: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_UserAttributes
Desc: Automatically created by SHAREid. Do not modify.
AgentType: 10-8d78bb96-ae15-11d1-9cdd-006008aac24b
Attributes: 08-8d8cf013-e93f-4a06-83b5-7eb44432bfb7, 08-fef77ff7-038d-4a94-840a-c562f137da5d, 08-8cb3d975-56b1-4b0d-a742-a1c044624b28
AccessAccept: false
AccessReject: false
AccessChallenge: false
Type: 0
objectclass: ResponseAttr
Oid: 08-8d8cf013-e93f-4a06-83b5-7eb44432bfb7
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: uid=<%userattr="uid"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: ResponseAttr
Oid: 08-fef77ff7-038d-4a94-840a-c562f137da5d
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: mail=<%userattr="mail"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: ResponseAttr
Oid: 08-8cb3d975-56b1-4b0d-a742-a1c044624b28
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
AgentTypeAttr: 11-8d78bb90-ae15-11d1-9cdd-006008aac24b
Value: genUserID=<%userattr="genUserID"%>
TTL: 0
Flags: 0
ActiveExpr: 00-
objectclass: PolicyLink
Oid: 05-88999535-dc1e-46c0-8420-b22ae3feb56f
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-75967ff0-bffd-4410-acc8-6cbe3e65c68f
Response: 00-
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: PolicyLink
Oid: 05-8c49d99a-c459-4b48-bd32-e6f755d3cd34
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-2259776d-e839-4eb4-9b0e-97adf95ae19a
Response: 00-
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: UserPolicy
Oid: 0f-d1c1fe0a-526e-4471-93c3-abd40109eb2d
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
FilterPath: o=company,c=us
FilterClass: organization
PolicyResolution: 5
PolicyFlags: 0
UserDirectory: 0e-0aec4e86-469e-400f-ab82-2d75685ce40b
Policy: 04-98e5b0bc-f051-4447-8b99-08b1d7454115
objectclass: Policy
Oid: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Name: OracleFederation_UserAttributes
Desc: Automatically created by SHAREid. Do not modify.
Time: 00000000-00000000-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
PolicyLinks: 05-b09b8003-d82c-4586-8132-9c9bf2a40874
UserPolicies: 0f-c1147a2a-a47b-455d-a52f-19f8cf401961
AllowAccess: true
IsEnabled: true
IPAddress:
Type: 0
ActiveExpr: 00-
UserActiveExpr: 00-
objectclass: PolicyLink
Oid: 05-b09b8003-d82c-4586-8132-9c9bf2a40874
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
Rule: 0b-0bac8120-dd43-45a4-badd-5f56df272c2a
Response: 07-7a3e908b-1292-43af-ba0d-52f85b3e2716
Policy: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
objectclass: UserPolicy
Oid: 0f-c1147a2a-a47b-455d-a52f-19f8cf401961
DomainOid: 03-0eda0cd9-58e3-4df4-8eeb-c4cfbded874e
FilterPath: (genuserid=*)
FilterClass: User Attribute
PolicyResolution: 3
PolicyFlags: 0
UserDirectory: 0e-0aec4e86-469e-400f-ab82-2d75685ce40b
Policy: 04-aa1d7959-82b9-4dca-9737-ff89f153d10e
この項では、Sun Java System Web ServerをOracle Identity Federationと次の構成で統合する方法を説明します。
1番目のOracle Identity Federationインスタンスがサービス・プロバイダ（SP）として構成されており、Oracle Access Managerバックエンドがあり、任意のディレクトリ・サーバーを使用
2番目のOracle Identity Federationインスタンスがアイデンティティ・プロバイダ（IdP）として構成されており、任意のディレクトリ・サーバーまたはデータベースをバックエンドで使用
内容は次のとおりです。
Oracle Identity FederationとOracleAS Single Sign-Onの統合
（この項では、Oracle Application Server Single Sign-Onバックエンドを実装する方法を説明します。）
Oracle Identity Federationの前面でプロキシを使用する場合は、プロキシ・サーバー・インスタンスのホスト名およびポート番号をOracle Identity Federationのfedadmin管理コンソールのホストおよびポートとしてそれぞれ使用します。プロキシはfedadminコンソールのみを非表示にするため、アプリケーション・サーバー・コンソールも非表示にするリバース・プロキシ・プラグインを使用して、Sun Java System Web Serverの2番目のインスタンスを作成する必要があります。
この構成では、次の2つの手順が必要です。
アイデンティティ・プロバイダの構成
サービス・プロバイダの構成
アイデンティティ・プロバイダの構成
次の手順に従って、アイデンティティ・プロバイダ（IdP）を構成します。
Oracle Identity Federationのインスタンスをインストールします。
インストールの詳細は、『Oracle Identity Federation管理者ガイド』の第3章「Oracle Identity Federationのインストール」を参照してください。
次の場所にある管理コンソールにログインします。
http://IdPhost:port/fedadmin
「サーバー構成」→「一般」→「サーバー・プロパティ」に移動します。
完全修飾ホスト名としてサーバー名を入力します。
「サーバー・ポート」および「SOAPポート」は、fedadminポートと同じです。
他の情報は変更しないでください。
「サーバー・プロパティ」→「サービス・プロバイダ」→「グローバル設定」に移動します。
プロバイダのURLを、http://fully-qualified-host:port/fed/spと入力します。
「サーバー・プロパティ」→「アイデンティティ・プロバイダ」→「グローバル設定」に移動します。
プロバイダのURLを、http://fully-qualified-host:port/fed/idpと入力します。
次の形式で共通ドメイン名を入力します。
.mycompany.com
「IDMデータ・ストア」→「ユーザー・データ・ストア」に移動します。
アクティブ・リポジトリを選択します。
次のリポジトリ・パラメータを入力します。
| フィールド | 値 |
|---|---|
| 接続URL | LDAPの場合、URLとしてldap://host:portを入力 |
| バインドDN | cn=directory manager、パスワードをパスワード・フィールドに入力 |
| ユーザーID属性 | ログイン・ユーザーID |
| ユーザー説明属性 | 「ユーザーID属性」と同一 |
| 個人オブジェクト・クラス | 適宜（inetorgpersonなど） |
| ベースDN | 検索ベースのDNと同一 |
残りのフィールドでは、デフォルト値を受け入れます。
同じページで、「フェデレーション・データ・ストア」に移動し、アクティブ・リポジトリを選択します。
次のリポジトリ・パラメータを入力します。
| フィールド | 値 |
|---|---|
| 接続URL | LDAPの場合、URLとしてldap://host:portを入力 |
| バインドDN | cn=directory manager、パスワードをパスワード・フィールドに入力 |
| ユーザー・フェデレーション・レコード・コンテキスト: | 検索ベースの場合と同一 |
残りのフィールドでは、デフォルト値を受け入れます。
メタデータを収集するには、ブラウザでURLを次の形式で入力します。
http://hostname/fed/idp/metadatav11、または
http://hostname/fed/idp/metadatav12、または
http://hostname/fed/idp/metadatav20
メタデータをファイルに保存します。
サービス・プロバイダの構成
次の手順に従って、サービス・プロバイダ（SP）を構成します。
Oracle Access Managerをインストールします。
Oracle Identity Federationをインストールします。次の場所にある管理コンソールにログインします。
http://host:port/fedadmin
「サーバー構成」→「一般」→「サーバー・プロパティ」に移動します。
完全修飾ホスト名としてサーバー名を入力します。
次に例を示します。
host.mycompany.com:port
「サーバー・ポート」および「SOAPポート」は、fedadminポートと同じです。
他の情報は変更しないでください。
「サーバー・プロパティ」→「サービス・プロバイダ」→「グローバル設定」に移動します。
プロバイダのURLを、http://fully-qualified-host:port/fed/spと入力します。
「サーバー・プロパティ」→「アイデンティティ・プロバイダ」→「グローバル設定」に移動します。
プロバイダのURLを、http://fully-qualified-IdPhost:port/fed/idpと入力します。
次の形式で共通ドメイン名を入力します。
.mycompany.com
Oracle Access Managerアクセス・サーバーSDKをOIF_Install_Dir/fed/shareidにインストールします。アクセス・サーバーSDKはOIF_Install_Dir/fed/shareid/AccessServerSDKにインストールされます。
Oracle Access Managerを使用して、Oracle Identity Federation用のAccessGateインスタンスを構成します。
|
注意: アクセス管理サービスがAccessGate構成に対してオンである必要があります。 |
アクセス・システム・コンソールで、名前がFed HostIDのホスト識別子を次の形式で作成します。
fully-qualified-SPhost:port
Fed SSO - SAML 2.0/Liberty 1.x認証スキームを使用して、テスト・リソースを保護するポリシー・ドメインを作成します。
Oracle Identity Federation管理コンソールで、「IDMデータ・ストア」→「ユーザー・データ・ストア」に移動します。
Oracle Access Managerをアクティブ・リポジトリとして選択します。
次のリポジトリ・パラメータを入力します。
| フィールド | 値 |
|---|---|
| 接続URL | LDAPの場合、URLとしてldap://host:portを入力 |
| バインドDN | cn=directory manager、パスワードをパスワード・フィールドに入力 |
| ユーザーID属性 | ログイン・ユーザーID |
| ユーザー説明属性 | 「ユーザーID属性」と同一 |
| 個人オブジェクト・クラス | 適宜（inetorgpersonなど） |
| ベースDN | 検索ベースのDNと同一 |
残りのフィールドでは、デフォルト値を受け入れます。
Oracle Access Manager構成パラメータには、次の情報を指定します。
| フィールド | 値 |
|---|---|
| マスター管理者ログインID | 管理ユーザーID |
| マスター管理者パスワード | 管理ユーザー・パスワード |
| 無保護リソースに対する認証結果 | 許可 |
| Oracle Access Manager Cookieドメイン | 完全修飾ホスト名 |
| Basic認証スキーム名 | Oracle Access and Identity Basic Over LDAP（Oracle Access Manager 10.1.4以上の場合）またはBasic Over LDAP（7.0.4の場合） |
「適用」をクリックします。
同じページで、「フェデレーション・データ・ストア」に移動します。
アクティブ・リポジトリを選択します。
次のリポジトリ・パラメータを入力します。
| フィールド | 値 |
|---|---|
| 接続URL | LDAPの場合、URLとしてldap://host:portを入力 |
| バインドDN | cn=directory manager、パスワードをパスワード・フィールドに入力 |
| ユーザー・フェデレーション・レコード・コンテキスト: | cn=fed、searchbase |
残りのフィールドでは、デフォルト値を受け入れます。
「サーバー構成」→「トラスト・サークル」に移動します。
「信頼できるプロバイダの追加」ページから、IdP用に収集したメタデータをアップロードし、サーバーをリフレッシュします。
IdPが「アイデンティティ・プロバイダ」のリストに表示されたら、メイン・メニューから「アイデンティティ・フェデレーション」に移動し、「アイデンティティ・プロバイダ」リストにIdPのURLが表示されていることを確認します。
「サーバー構成」→「サービス・プロバイダ」→「グローバル設定」に移動します。
「デフォルトSSOアイデンティティ・プロバイダ」のドロップダウン・リストで、IdPプロバイダのURLを選択します。
変更を保存してサーバーをリフレッシュします。
メタデータを収集するには、ブラウザでURLを次の形式で入力します。
http://hostname/fed/sp/metadatav11、または
http://hostname/fed/sp/metadatav12、または
http://hostname/fed/sp/metadatav20
メタデータをファイルに保存します。
このメタデータをIdPにアップロードします。
「Webプロキシ・サーバーを使用しないOracle Identity Federationの構成」に定義されている手順に従いますが、次の点を変更します。
構成URLを各構成のプロキシ・サーバーのURLに変更します。
Oracle Identity Federation管理コンソールで、「SAML 1.x/WSフェデレーション」→「ドメイン」→「マイ・ドメイン」に移動し、SAML 1.x/WS-Fed構成の次のURLを更新します。
エラーURL
転送URL
応答者URL
ソースID（新規応答者URL用に再生成する場合は空白）
アイデンティティ・レルム・セキュア・トークン・サービス(STS) URL
受信者URL
リソース・レルム・セキュア・トークン・サービス(STS) URL
これらのURLの詳細は、「SAML 1.xプロパティとWS-Federationプロパティの構成」を参照してください。
実際のURLではなくプロキシのURLを使用してメタデータを収集した後で、そのメタデータをアップロードします。
アクセス・システム・コンソールで、ホスト識別子を次の形式で作成します。
proxy-host:port
次に、認証スキームのチャレンジ・リダイレクトをproxy-host:portに変更します。
Oracle Identity FederationをOracle Single Sign-Onバックエンドと統合するには、次の追加手順を実行します。
OracleAS Single Sign-Onパートナ・アプリケーションを更新します。
Oracle Single Sign-On管理コンソール（http://osso_host:osso_port/pls/orasso）に移動します。
「シングル・サインオン管理」をクリックします。
「パートナ・アプリケーション管理」をクリックします。
Oracle Identity Federationサーバーを参照しているパートナ・アプリケーションを選択し、アプリケーション構成を編集します。
http（s）、ホスト名およびポート番号を、プロキシのホームURL、成功URLおよびログアウトURLの値に置き換えます。
「OK」をクリックします。
policy.propertiesファイルを更新します。
OracleAS Single Sign-OnデプロイメントのORACLE_HOME/sso/conf/policy.propertiesファイルを開きます。
http（s）、ホスト名およびポート番号を、プロキシのSASSOAuthnUrlおよびSASSOLogoutUrlエントリの値に置き換えます。
保存してファイルを閉じます。
OracleAS Single Sign-OnデプロイメントのOC4J_SECURITYインスタンスを、次のコマンドを使用して再起動します。
opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
この項では、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/panacea/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://flagstaff.persistent.co.in:7777" </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/panacea/SunOne6.1 ServerName calgary ServerID https-oif_idp_flagstaff # RqThrottle 128 DNS off Security off PidLog /home/panacea/SunOne6.1/https-oif_idp_flagstaff/logs/pid User panacea 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/panacea/SunOne6.1/bin/https/lib/libj2eeplugin.so" shlib_flags="(global|now)" Init fn="load-modules" shlib="/home/panacea/SunOne6.1/bin/https/passthrough/plugins/passthrough /libpassthrough.so"
この項では、IBM Tivoli Directory Server（IBM TDS）6.0をバックエンドでフェデレーション・データ・ストアまたはユーザー・データ・ストアとして使用するようにOracle Identity Federationを構成する方法を説明します。内容は次のとおりです。
IBM TDSデータ・ストアを設定する前に、次の前提条件が満たされていることを確認してください。
Oracle Identity Federationをインストールします。
IBM TDS v6.0をインストールおよび構成します。
フェデレーション・スキーマを外部からIBM TDSにロードし、フェデレーション・レコードを作成します。LDAPスキーマのこの更新には、$ORACLE_HOME/setup/ldap/userFedSchemaTivoli.ldifファイルを使用します。
LDAPスキーマの構成方法の詳細は、「フェデレーション・データ・ストア」の「LDAPスキーマに関する注意」を参照してください。
Oracle Identity Federation管理コンソールで、「IDMデータ・ストア」→「フェデレーション・データ・ストアの編集」とナビゲートします。
アクティブ・リポジトリの「LDAPディレクトリ」を選択します。
次のリポジトリ・パラメータを指定します。
接続URL: 接続URLです。ホスト名とポートで構成されるIBM Tivoli Directory ServerのURLのスペース区切りリストを入力します。
バインドDN: Oracle Identity FederationサーバーがIBM Tivoli Directory Serverに接続するために使用するDNです。
パスワード: LDAPサーバーへの接続に使用する管理者アカウントのパスワードを入力します。
ユーザー・フェデレーション・レコード・コンテキスト: このOracle Identity Federationサーバーのすべてのフェデレーション・レコードをその下に格納するノードを入力します。
LDAPコンテナ・オブジェクト・クラス: LDAPコンテナを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキストのタイプを入力します。たとえば、IBM Tivoli Directory Serverでは、このフィールドを空白のままにできます。
一意フェデレーションID属性: フェデレーション・レコードを一意に識別するために使用されるLDAP属性を入力します。たとえば、IBM Tivoli Directory Serverでは、このフィールドを空白のままにできます。
最大接続数: Oracle Identity FederationによってIBM Tivoli Directory Serverに作成可能な同時接続数の最大値を入力します。
接続待機タイムアウト: Oracle Identity FederationによってIBM Tivoli Directory Serverに開かれた接続数が最大値に達した場合に、接続が使用可能になるまで待機する秒数の最大値を入力します。
Oracle Identity Federation管理コンソールで、「IDMデータ・ストア」→「ユーザー・データ・ストアの編集」とナビゲートします。
アクティブ・リポジトリから「LDAPディレクトリ」を選択します。
次のリポジトリ・パラメータを指定します。
接続URL: 接続URLです。ホスト名とポートで構成されるIBM Tivoli Directory ServerのURLのスペース区切りリストを接続URLとして入力します。
バインドDN: Oracle Identity FederationサーバーがIBM Tivoli Directory Serverに接続するために使用するDNです。
パスワード: データ・ストアへの接続に使用する管理者アカウントのパスワードを入力します。
ユーザーID属性: 検索または認証手順でユーザーをマップするために使用する属性名を入力します。たとえば、IBM Tivoli Directory Serverでは、このフィールドをuidに設定できます。
ユーザー説明属性: このフィールドは、可読的なフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。たとえば、IBM Tivoli Directory Serverでは、このフィールドをuidに設定できます。
個人オブジェクト・クラス: IBM Tivoli Directory Serverでユーザーを表すLDAPオブジェクト・クラスを入力します。たとえば、IBM Tivoli Directory Serverでは、このフィールドをinetOrgPersonに設定できます。
ベースDN: IBM Tivoli Directory Serverユーザー検索が実行されるノードを入力します。たとえば、dc=us,dc=oracle,dc=comなどです。
接続待機タイムアウト: Oracle Identity FederationによってIBM Tivoli Directory Serverに行われた同時接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値を入力します。
Oracle Identity Federationでは、SAML、LibertyおよびWS-Federationなどの標準プロトコルを使用して、クロスドメインのシングル・サインオンが可能です。
デフォルトでは、Oracle Identity Federationは次のような複数のIDおよびアクセス管理（IAM）製品と統合されています。
OracleAS Single Sign-On
Oracle Access Manager
CA eTrust SiteMinder
Oracle Identity Federationには、カスタムまたはサード・パーティのIDおよびアクセス管理ソリューションを統合する際に開発者が使用できるフレームワークも用意されています。この項では、このフレームワークのコンポーネントについて説明し、カスタムIAMソリューションを構成してこのフレームワークに統合する方法を示します。
|
注意: この項で説明されているカスタム統合および認証用以外のアプリケーションをOC4J_FED J2EEコンテナ・インスタンスにデプロイすると、セキュリティ上のリスクが発生する可能性があるため、そのようなデプロイは行わないことをお薦めします。OC4J_FEDコンテナにデプロイされた無関係なアプリケーションは、悪意のあるソフトウェアによるサーバー・フローの動作の変更を可能にするため、フェデレーション・サーバーのセキュリティに悪影響を与えることがあります。 |
この項には、カスタム・エンジンの実装に関連する次の内容が含まれています。
実行時に、Oracle Identity Federationは2種類の外部モジュール（ユーザー・データ・ストアと、IDおよびアクセス管理システム）と相互作用します。
Oracle Identity Federationがユーザー・データ・ストアと連携する目的は次のとおりです。
ローカル認証後のユーザーの検索
着信SAMLアサーションの処理後のユーザーの検索
特定のユーザーの属性の取得
IDおよびアクセス管理（IAM）システムは、保護されたリソースに対するアクセスを制御します。Oracle Identity Federationがフェデレーション・サーバーとしてIAMと相互作用する目的は次のとおりです。
サーバーがユーザーのローカルIDを取得する必要がある場合にユーザーを認証します。この操作は、サーバーがIdPとして機能する場合、またはSPとして機能するサーバーが初期アカウント・リンク/フェデレーション作成中にユーザーを認証する必要がある場合に行われることがあります。
サーバーが着信SAMLアサーションを処理し、特定のユーザーのIDをIAMシステムに対して宣言する場合に、そのユーザー用の認証済セッションを作成します。
ログアウト・フローを処理します。この場合、フェデレーション・サーバーは、ユーザーをシステムからログアウトさせるIAM機能を起動します。
図4-1に、Oracle Identity Federationデプロイメントの複数の外部および内部モジュールと、各モジュールが実行時に相互作用する方法を示します。
ここでは、わかりやすいように、Oracle Identity Federationサーバーを次の3つの内部モジュールとして示します。
アイデンティティ・フェデレーション・エンジン。AuthnRequest、AssertionおよびLogoutなどのSAMLメッセージの作成および処理を行います。
このモジュールの機能は次のとおりです。
SAMLメッセージの処理時に、ユーザー・データ・ストアと連携します。
ユーザーをローカルに識別する必要がある場合に、認証エンジンと相互作用します。
アサーションの処理後にユーザーがIAMコンポーネントにリダイレクトされる際に、SP統合エンジンと相互作用します。
認証エンジン。フェデレーション・エンジンからのリクエストを処理してユーザーを認証します。このモジュールは、IAMコンポーネントおよびユーザー・データ・ストアと相互作用して、ユーザーの認証と、Oracle Identity Federationでユーザーの参照に使用される一意の識別子の取得を実行します。
このモジュールは、ローカル認証が必要な場合に、IdPまたはSPモードで起動できます。
ユーザーの認証後、認証エンジンは、ユーザー識別子や認証時刻およびその他のデータなどの認証情報をフェデレーション・エンジンに送信します。
フェデレーション・エンジンは、着信SAMLアサーションを正常に処理し、アサーションで参照されるユーザーを検索した後、そのユーザー用の認証済セッションをIAMドメインで作成するようにSP統合エンジンに指示します。必要な情報（ユーザー識別子、認証時刻など）をSP統合エンジンに渡します。SP統合エンジンは、IAMサーバーと相互作用してこのセッションを作成します。
Oracle Identity Federationに付属の認証エンジンには、サーバーからのリクエストを処理してユーザーを認証するサーブレットと、デフォルトでサポートされている各種のIAMサーバーとの相互作用を可能にする複数の内部プラグインが含まれています（この説明の最初の部分を参照）。
ここでは、認証エンジンが一般的なユーザー・フローで他のフェデレーション・サーバー・コンポーネントと相互作用する方法を段階的に説明します。
ユーザーがOracle Identity FederationにアクセスしてSSO処理を行います（SPまたはIdPモード）。
サーバーの内部プロセスで、ユーザーの識別が必要であることを判断します。
フェデレーション・サーバーが、既存の問合せのStringパラメータを削除してOracle Identity Federationの問合せのStringに置き換えるために、ユーザーを自身にリダイレクトします。一般的な新規問合せのStringには、次のパラメータが含まれています。
doneURL: getUsrSessパラメータの値がtrueでない場合、認証エンジンによるユーザーの識別後にユーザーを再転送する必要がある相対URL。
authnMech: ユーザーの認証に使用するようにフェデレーション・サーバーからリクエストされた認証メカニズム。
refID: フェデレーション・サーバー内のデータを参照する識別子。このパラメータは、存在する場合、認証エンジンによるユーザーの転送時にOracle Identity Federationに戻される必要があります。
getUsrSess: ユーザーをdoneURLパラメータではなくWS-Fed/SAML 1.xプロトコル・エンジンにリダイレクトするかどうかを示すブール型パラメータ。
フェデレーション・エンジンが、ユーザーのリクエストを/sso/authn URL（コンテキストは/sso、転送URLは/authn）に内部的に転送します。HttpServletRequestでは、ユーザー認証をリクエストしていることを示すために、oracle.security.sso.sasso.authn.dyna_modeというString属性がidpに設定されます。
認証エンジンが受信リクエストを処理します。このエンジンは、次の情報にアクセスできます。
doneURL、authnMech、refIDおよびgetUsrSess（問合せパラメータ）
oracle.security.sso.sasso.authn.dyna_mode（HttpServletRequest属性）
認証エンジンは、IAMコンポーネントと相互作用し、ユーザーの資格証明を要求する場合があります。認証に成功すると、Cookieを設定する場合があります（IAMサーバーまたはターゲット・アプリケーション、あるいはその両方との認証済セッションを維持するためなど）。
getUsrSessパラメータが存在しない、またはfalseに設定されている場合、認証エンジンはユーザーをdoneURLにあるLiberty 1.x/SAML 2.0フェデレーション・エンジンにフェデレーション・コンテキストで再転送します（コンテキストは/fedで、転送URLは以前に受信されたdoneURL問合せパラメータ）。
getUsrSessパラメータの値がtrueの場合、認証エンジンはユーザーを/saml/ObSAMLLoginService相対URLにあるWS-Fed/SAML 1.xフェデレーション・エンジンに再転送し、コンテキストを/shareidにします。
認証エンジンは次のHttpServletRequest属性を設定します。
String属性oracle.security.sso.sasso.uid。ユーザー識別子が含まれています。フェデレーション・エンジンはこの識別子を使用して、Oracle Identity Federation管理コンソール（具体的には、「ユーザー・データ・ストア」ページの「ユーザーID」フィールド）で設定されたユーザー・レコード属性に基づいてユーザーを検索します。
String属性oracle.security.sso.sasso.refID。以前に送信されたrefID問合せパラメータ値が含まれています。
String属性oracle.security.sso.sasso.authnMech。ユーザーの認証に使用される方法を参照するOracle認証メカニズム識別子が含まれています。現在、この値はoracle:fed:authentication:password-protectedにのみ設定できます。
date属性oracle.security.sso.sasso.authnInst。ユーザーを認証した時刻が含まれています。
|
注意: この属性には、クラスjava.util.Dateのオブジェクトが含まれます。 |
Oracle Identity Federationが次の機能を実行します。
受信リクエストの処理
属性としてHttpServletRequestに埋め込まれたデータの取得
ユーザー・データ・ストアでのユーザーの検索
ユーザー用のセッションの作成
Cookieの設定
SSO処理の再開
Oracle Identity Federationに付属のSP統合エンジンは、サーバーからのリクエストを処理してIAMサーバーでユーザー用の認証済セッションを作成するサーブレットで構成されています。このエンジンには、複数のIAMサーバーとの相互作用を可能にする複数の内部プラグインが含まれています。
ここでは、SP統合エンジンが一般的なユーザー・フローで他のフェデレーション・サーバー・コンポーネントと相互作用する方法を段階的に説明します。
ユーザーがリモートIdPを使用してフェデレーションSSO処理をトリガーします。SSOは、次の問合せパラメータを使用して/fed/sp/initiatesso URLをリクエストすることで、IdP（IdPが開始するSSO）またはOracle Identity Federation SPでトリガーされます。
providerid: IdPのプロバイダID（必須）
returnurl: フェデレーションSSOが成功した場合にユーザーのリダイレクト先となるURL（オプション）
IdPが、ユーザーをアサーションとともに、SPとして機能するフェデレーション・サーバーにリダイレクトします。
サーバーがアサーションを処理し、ユーザーをユーザー・データ・ストアで検索します。これで、ユーザーがフェデレーション・サーバーで認証されます。
フェデレーション・エンジンが、ユーザーを/sso/authn URLに内部的に転送し、次のデータをHttpServletRequest属性として渡します。
ユーザー識別子。
認証時刻。
認証済セッションの有効期限。これは、Oracle Identity Federationのセッション・タイムアウトと、アサーションでIdPによって送信されたセッション有効期限のうち、短いほうの時間になります。
ユーザーのリダイレクト先となるURL。
SP統合エンジンが、IAMサーバーと相互作用して、ユーザー用の認証済セッションを作成します。このセッションは、Oracle Identity Federationから受信されたデータに基づきます。
SP統合エンジンが、ユーザーを最終のターゲットURLにリダイレクトします。
Oracle Identity Federationは、認証操作およびSP統合に関する特定の要件を満たすよう設計されています（ユーザー・セッションがIAMサーバーで作成される場合）。したがって、カスタム認証エンジンまたはSP統合エンジンの実装時は次の要件を満たす必要があります。
認証エンジン、SP統合エンジン、アイデンティティ・フェデレーション・エンジンおよびIAMサーバーは、同じユーザー・データ・ストアをユーザー・リポジトリとして使用する必要があります。このストアには、ユーザーの検索および認証に使用されるユーザー・データが含まれています。
認証エンジンおよびSP統合エンジンには、Javaサーブレット/JSPが含まれている必要があります。
OIFと認証/SP統合エンジンの間のデータ交換は、内部HTTPリクエスト転送を介して行われる必要があります。これは実際には、J2EEサーブレット・フレームワークに依存したモジュール間の内部APIコールであり、HTTPプロトコルを介して行われます。
ログアウト・サービスを実装し、認証エンジンまたはSP統合エンジン（あるいはその両方）がこのサービスを使用できるようにする必要があります。このログアウト・サービスは、サーブレット/JSPとして公開される必要があります。
カスタマイズされた認証エンジンとSP統合エンジンの両方がOracle Identity Federationとともに実装される場合、LDAPまたはRDBMS用のユーザー・データ・ストアをスタンドアロン・モードで構成する必要があります。これが必要なのは、Oracle Identity FederationがIAMサーバー（Oracle SSO、Oracle Access ManagerまたはCA SiteMinder）との相互作用を初期化時などに試行しないようにするためです。
この項では、カスタム認証エンジンを計画、開発および実装する方法を説明します。
カスタマイズされた認証エンジンの作成には、次の手順が含まれます。
Oracle Identity Federationからの受信リクエストを処理するサービスの作成。
ユーザーを認証するモジュールの実装。
ユーザーを必須情報とともにフェデレーション・サーバーに転送するサービスの作成。
認証エンジンがユーザーの認証後にCookieを設定するかどうかの判断。設定する場合、認証モジュールをログアウト処理と統合する必要があります（「ログアウト」を参照）。
前述のサービスおよびモジュールのWebアプリケーションへのパッケージ化と、Oracle Identity Federationが実行されているOracle Application ServerのOC4J_FEDインスタンスへのこのアプリケーションのデプロイ。
Oracle Identity Federationの構成ファイルが新規認証エンジンを参照するようにするための変更。
|
注意: この手順では、OC4J_FEDを再起動する必要があります。 |
認証エンジンで使用されるユーザー・リポジトリが、Oracle Identity Federation管理コンソールで構成され、フェデレーション・サーバーで使用されるユーザー・データ・ストアと同じであることの確認。
ここでは、モジュール開発のいくつかの側面について説明します。
URL
フェデレーション・エンジンと認証エンジンの間の通信は、APIコールに相当する内部サーブレット転送を介して行われます。これらの転送では、次のJ2EE APIを使用します。
ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)
ここで、
contextPathは、Webアプリケーションのルート・コンテキスト・パスです。たとえば、Oracle Identity FederationのcontextPathは/fedまたは/shareidです。
relativePathは、ユーザーの転送先となるサービスURLであり、contextPathに相対的です。たとえば、ユーザーの認証後、認証エンジンではユーザーの転送時に/user/loginssoまたは/saml/ObSAMLLoginServiceをrelativePathとして使用します。
認証エンジンは、Oracle Identity FederationサーバーのcontextPathが/fedまたは/shareidであることを認識している必要があります。
また、Oracle Identity Federationは、新規認証エンジンのcontextPathおよびrelativePathも認識している必要があります。これは、フェデレーション・サーバーが発行した認証リクエストを処理するURLです。
次のファイルを変更してこれらのURLを構成します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
値がsasso_login_idp_contextと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値を新規認証エンジンのcontextPathに変更します（デフォルトでは、この値は/ssoに設定されています）。
値がsasso_login_idp_urlと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値を新規認証エンジンのrelativePathに変更します（デフォルトでは、この値は/authnに設定されています）。
SAML 1.xおよびWS-Fedプロトコルも、新規認証エンジンのcontextPathおよびrelativePathを認識している必要があります。これらのURLを構成するには、$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを次のように変更します。
<LoginConfig> XML要素で、Name属性がSassoと等しい<AuthnMethod>要素を検索し、LoginURL属性をcontextPathとrelativePathを連結したものに設定します。
|
注意: Oracle Identity FederationにおけるSAML 1.x/WS-Fedプロトコルの制限により、relativePathに含めることのできる"/"文字は1つのみです。contextPathには制限はありません。たとえば、contextPathを/path1/path2/path3に設定することはできますが、relativePathは/path4への設定のみが可能であり、/path5/path6の値はrelativePathには無効です。 |
authn-mappings.xmlファイルの変更後、OC4J_FEDインスタンスを再起動します。
サービスの実装
この項では、認証エンジンが実行する役割と、実装を成功させるためにサービスで実行できる必要がある処理タスクについて説明します。
認証エンジンは次を実行する必要があります。
フェデレーション・エンジンからのリクエストの処理
認証成功後のフェデレーション・サーバーへのユーザーの転送
サーバーからの認証リクエストの処理時に、エンジンは次の着信データを処理する必要があります。
doneURL問合せパラメータ: getUsrSessパラメータの値がtrueでない場合、認証エンジンによる識別後にユーザーを転送する必要がある相対URL。
authnMech問合せパラメータ: ユーザーの認証に使用するようにフェデレーション・サーバーからリクエストされた認証メカニズム。今回のリリースでは、常にoracle:fed:authentication:password-protectedになります。
refID問合せパラメータ: フェデレーション・サーバー内のデータを参照する識別子。このパラメータは、存在する場合、認証エンジンによるユーザーの転送時にOracle Identity Federationに戻される必要があります。
getUsrSess: ユーザーをdoneURLパラメータではなくWS-Fed/SAML 1.xプロトコル・エンジンにリダイレクトするかどうかを示すブール型パラメータ。
oracle.security.sso.sasso.authn.dyna_mode: HttpServletRequest属性。ローカル認証が起動される場合、この値は常にidpに設定されます。
認証成功後、エンジンはユーザーをフェデレーション・サーバーに転送する必要があります。getUsrSessパラメータが存在しない、またはその値がtrueでない場合、フェデレーション・エンジンのrootContextは/fedであり、今回のリリースのrelativePathは/user/loginssoです。このrelativePathパラメータは、doneURL問合せパラメータにも格納されます。getUsrSessパラメータが存在し、その値がtrueの場合、フェデレーション・エンジンのrootContextは/shareidであり、今回のリリースのrelativePathは/saml/ObSAMLLoginServiceです。
Oracle Identity Federationでは、内部転送の処理時に次のデータが必要です。
oracle.security.sso.sasso.uid: タイプがStringのHttpServletRequest属性。ユーザー識別子が含まれています。
oracle.security.sso.sasso.refID: タイプがStringのHttpServletRequest属性。Oracle Identity Federationから以前に送信されたrefID問合せパラメータ値が含まれています。
oracle.security.sso.sasso.authnMech: タイプがStringのHttpServletRequest属性。ユーザーの認証に使用される方法を参照するOracle認証メカニズム識別子が含まれています。今回のリリースでは、この値はoracle:fed:authentication:password-protectedに設定される必要があります。
oracle.security.sso.sasso.authnInst: タイプがjava.util.DateのHttpServletRequest属性。ユーザーを認証した時刻が含まれています。
さらに、次の追加の実装要件があります。
サービスでCookieを設定する必要がある場合、ユーザーをフェデレーション・サーバーに転送する前にその操作を実行してください。
Cookieパス値を"/"に設定してください。これが必要なのは、Oracle Identity Federation Webアプリケーションと認証エンジンWebアプリケーションの間の内部転送のためです。ユーザーのブラウザは、フェデレーション・サーバーのみへのアクセス時でも、認証エンジンに関連するCookieを送信する必要があります。このように、フェデレーション・サーバーから認証エンジンへの内部転送では、エンジンが設定したCookieがHTTPリクエストに含まれます。
この項では、カスタム認証エンジンをOracleAS Single Sign-Onと統合する方法を説明します。
設定
この例では、Oracle Identity Federationが実行されているアプリケーション・サーバーはOracleAS Single Sign-Onサーバーと統合されており、SSOモジュールは/engine/forward.jsp URLを静的に保護しています。
また、Oracle Identity Federation管理コンソールで構成されたユーザー・データ・ストアは、OracleAS Single Sign-Onで使用されるOracle Internet Directoryサーバーを参照します。
パッケージ
認証エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。
authentication.jsp: Oracle Identity Federationサーバーからの受信リクエストを処理します。
forward.jsp: OracleAS Single Sign-Onで保護され、ユーザーを必須データとともにフェデレーション・サーバーに再転送します。
authentication.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String authnMech = request.getParameter("authnMech");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String authnMode = (String)request.getAttribute("oracle.security.sso.sasso.authn.dyna_mode");
if (authnMode != null && !"idp".equals(authnMode))
throw new ServletException("Incorrect authn mode");
String redirectURL = "/engine/forward.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
response.sendRedirect(redirectURL);
%>
forward.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String userID = request.getRemoteUser();
String authnMethod = "oracle:fed:authentication:password-protected";
Date now = new Date();
request.setAttribute("oracle.security.sso.sasso.uid", userID);
request.setAttribute("oracle.security.sso.sasso.refID", refID);
request.setAttribute("oracle.security.sso.sasso.authnMech", authnMethod);
request.setAttribute("oracle.security.sso.sasso.authnInst", now);
if ("true".equals(getUserSession))
request.getSession().getServletContext().getContext("/shareid").getRequestDispatcher("/saml/ObSAMLLoginService").forward(request, response);
else
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher(doneURL).forward(request, response);
%>
Oracle Identity Federationの構成ファイル
次のファイルを変更し、認証エンジンのcontextPathおよびrelativePathを定義します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
<authn-mapping>
<authn-method>sasso_login_idp_context</authn-method>
<authn-screen>/engine</authn-screen>
</authn-mapping>
<authn-mapping>
<authn-method>sasso_login_idp_url</authn-method>
<authn-screen>/authentication.jsp</authn-screen>
</authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更して認証エンジンのURLを定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="Sasso"
LoginURL="/engine/authentication.jsp" LogoutURL="/sso/logout" />
</SHAREidConfiguration>"
ログアウト
OracleAS Single Sign-OnフレームワークではCookieをユーザーのブラウザに設定するため、認証エンジンをログアウト・フローと統合する必要があります（「ログアウト」を参照）。
この項では、カスタマイズされた認証エンジンをスタンドアロンLDAPサーバーと統合する方法を示します。
設定
Oracle Identity Federation管理コンソールで構成されたユーザー・データ・ストアは、認証エンジンで使用されるLDAPサーバーを参照します。
パッケージ
認証エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。
loginpage.jsp: フェデレーション・サーバーからの受信リクエストを処理し、ログイン・ページを表示します。
ldapforward.jsp: ユーザーの資格証明をLDAPサーバーに対して認証し、認証成功時にユーザーをフェデレーション・サーバーに転送します。
loginpage.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String authnMech = request.getParameter("authnMech");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String authnMode = (String)request.getAttribute("oracle.security.sso.sasso.authn.dyna_mode");
if (authnMode != null && !"idp".equals(authnMode))
throw new ServletException("Incorrect authn mode");
String postURL = "/engine/ldapforward.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
String msg = request.getParameter("message");
%>
<HTML>
<BODY>
<FORM action="<%=postURL%>" method="POST">
<% if(msg != null && msg.length() > 0) { %> <%=msg%><BR/> <%}%>
Username: <INPUT type="text" name="username"/><BR/>
Password: <INPUT type="password" name="password"/><BR/>
<INPUT type="submit" value="Submit"/>
</FORM>
</BODY>
</HTML>
forward.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String doneURL = request.getParameter("doneURL");
String refID = request.getParameter("refID");
String getUserSession = request.getParameter("getUsrSess");
String userID = request.getParameter("username");
String password = request.getParameter("password");
String authnMethod = "oracle:fed:authentication:password-protected";
Date now = new Date();
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://stadm14.us.oracle.com:389");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=" + userID + ",cn=users,dc=us,dc=oracle,dc=com");
env.put(Context.SECURITY_CREDENTIALS, password);
try {
DirContext ctx = new InitialDirContext(env);
} catch (NamingException ex) {
String redirectURL = "/engine/loginpage.jsp?doneURL=" +
(doneURL != null ? URLEncoder.encode(doneURL) : "") + "&refID=" +
(refID != null ? URLEncoder.encode(refID) : "") + "&authnMech=" +
URLEncoder.encode(authnMethod) + "&message=" +
URLEncoder.encode(ex.toString() + " for " + userID + " / " + password) +
(getUserSession != null && getUserSession.length() > 0 ? "&getUsrSess=" + URLEncoder.encode(getUserSession) : "");
response.sendRedirect(redirectURL);
return;
}
request.setAttribute("oracle.security.sso.sasso.uid", userID);
request.setAttribute("oracle.security.sso.sasso.refID", refID);
request.setAttribute("oracle.security.sso.sasso.authnMech", authnMethod);
request.setAttribute("oracle.security.sso.sasso.authnInst", now);
if ("true".equals(getUserSession))
request.getSession().getServletContext().getContext("
/shareid").getRequestDispatcher("/saml/ObSAMLLoginService").forward(request, response);
else
request.getSession().getServletContext().getContext
("/fed").getRequestDispatcher(doneURL).forward(request, response);
%>
Oracle Identity Federationの構成ファイル
次のファイルを変更し、認証エンジンのcontextPathおよびrelativePathを定義します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
<authn-mapping> <authn-method>sasso_login_idp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_idp_url</authn-method> <authn-screen>/loginpage.jsp</authn-screen> </authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更して認証エンジンのURLを定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="Sasso" LoginURL="/engine/authentication.jsp"
LogoutURL="/sso/logout" />
</SHAREidConfiguration>"
ログアウト
このフローではCookieは設定されないため、認証エンジンをログアウト・フローと統合する必要はありません（「ログアウト」を参照）。
この項では、カスタムSP統合エンジンを計画、開発および実装する方法を説明します。
|
関連項目:
|
カスタムSP統合エンジンの開発には、次の手順が含まれます。
Oracle Identity FederationからのリクエストをSPモードで処理するサービスの作成。
ユーザー用の認証済セッションをIAMサーバーで作成するモジュールの実装。
最終のターゲットURLへのユーザーのリダイレクト。
SP統合エンジンがIAMサーバーでの認証済セッションの作成後にCookieを設定するかどうかの判断。設定する場合、エンジンをログアウト処理と統合する必要があります（「ログアウト」を参照）。
前述のサービスおよびモジュールのWebアプリケーションへのパッケージ化と、フェデレーション・サーバーが実行されているアプリケーション・サーバーのOC4J_FEDインスタンスへのこのアプリケーションのデプロイ。
Oracle Identity Federationの構成ファイルが新規SP統合エンジンを参照するようにするための変更。この手順では、OC4J_FEDを再起動する必要があります。
SP統合エンジンがユーザー・リポジトリにアクセスする場合、そのユーザー・リポジトリが、Oracle Identity Federationで使用されるようにOracle Identity Federation管理コンソールで構成されているユーザー・データ・ストアと同じであることの確認。
この項では、統合モジュールを開発する方法と、フェデレーション環境に実装する方法を説明します。
URL
アイデンティティ・フェデレーション・エンジンとSP統合エンジンの間の通信では、APIコールに相当する内部サーブレット転送が必要です。これらの転送は、次のJ2EE APIを使用してアーカイブされます。
ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)
ここで、
contextPathは、Webアプリケーションのルート・コンテキスト・パスです。たとえば、Oracle Identity FederationサーバーのcontextPathは/fedです。
relativePathは、ユーザーの転送先となるサービスURLであり、contextPathに相対的です。たとえば、認証後、認証エンジンではユーザーの転送時に/user/loginssoをrelativePathとして使用します。
Oracle Identity Federationでは、新規SP統合エンジンのcontextPathおよびrelativePathを認識している必要があります。これらのパスは、IAMサーバーと相互作用して認証済セッションを作成するサービスを公開するURLです。これらのURLを構成するには、$ORACLE_HOME/fed/conf/spmanager/authn-mappings.xmlファイルを次のように変更する必要があります。
値がsasso_login_sp_contextと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値を新規SP統合エンジンのcontextPathに変更します（デフォルトでは、この値は/ssoに設定されています）。
値がsasso_login_sp_urlと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値を新規SP統合エンジンのrelativePathに変更します（デフォルトでは、この値は/authnに設定されています）。
SAML 1.xおよびWS-Fedプロトコルも、新規SP統合エンジンのcontextPathおよびrelativePathを認識している必要があります。これらのURLを構成するには、$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを次のように変更します。<LoginConfig> XML要素で、Name属性がSassoSPと等しい<AuthnMethod>要素を検索し、LoginURL属性をcontextPathとrelativePathを連結したものに設定します。
|
注意: Oracle Identity FederationにおけるSAML 1.x/WS-Fedプロトコルの制限により、relativePathに含めることのできる"/"文字は1つのみです。contextPathには制限はありません。たとえば、contextPathを/path1/path2/path3に設定することはできますが、relativePathは/path4への設定のみが可能であり、/path5/path6の値はrelativePathには無効です。 |
これらの変更を永続化するには、最上位の<SHAREidConfiguration> XML要素のuseLocalConfig属性をtrueに設定します。
authn-mappings.xmlおよびshareid-config.xmlファイルの変更後、OC4J_FEDインスタンスを再起動します。
サービスの実装
Oracle Identity Federationからリクエストを受信した後、SP統合エンジンは次の機能を実行する必要があります。
ユーザー用の認証済セッションの作成
最終のURLへのユーザーのリダイレクト
エンジンは次の受信データを処理する必要があります。
oracle.security.sso.sasso.uid: タイプがStringのHttpServletRequest属性。一意のユーザー識別子が含まれています。
oracle.security.sso.sasso.authnInst: タイプがjava.util.DateのHttpServletRequest属性。ユーザー認証時刻が含まれています。
oracle.security.sso.sasso.expiryInst: タイプがjava.util.DateのHttpServletRequest属性。認証済セッションが期限切れになる時刻が含まれています。
oracle.security.sso.sasso.targetURL: タイプがStringのHttpServletRequest属性。最終のターゲットURLが含まれています。
oracle.security.sso.sasso.authn.dyna_mode: タイプがStringのHttpServletRequest属性。SPモードでは、この値は常にspに設定されます。
これらのデータを使用して、SP統合エンジンは、認証済セッションを作成し、ユーザーを最終のターゲットURLにリダイレクトします。
サービスでCookieの設定が必要な場合、Cookieパスは"/"に設定する必要があります。これが必要なのは、Oracle Identity Federation WebアプリケーションとSP統合エンジンWebアプリケーションの間の内部転送のためです。ユーザーのブラウザは、フェデレーション・サーバーのみへのアクセス時でも、SP統合エンジンに関連するCookieを送信する必要があります。このように、フェデレーション・サーバーからSP統合エンジンへの内部転送では、エンジンが設定したCookieがHTTPリクエストに含まれます。
次の2つの項では、カスタム認証エンジンの実装例を示します。
|
注意: この後でサンプルの統合モジュール1および2として説明されているカスタム統合および認証用以外のアプリケーションをOC4J_FED J2EEコンテナ・インスタンスにデプロイすると、セキュリティ上のリスクが発生する可能性があるため、そのようなデプロイは行わないことをお薦めします。OC4J_FEDコンテナにデプロイされた無関係なアプリケーションは、悪意のあるソフトウェアによるサーバー・フローの動作の変更を可能にするため、フェデレーション・サーバーのセキュリティに悪影響を与えることがあります。 |
この項では、javax.servlet.http.HttpSessionを使用して属性を設定する単純なSP統合エンジンを示します。この属性の存在により、ユーザーを認証するかどうかが決まります。
|
注意: この項の例は、説明のみを目的としているため、本番環境では使用しないでください。この例では、OC4J_FEDインスタンスにデプロイされている他のアプリケーションがSP統合エンジンで設定されるデータを使用すると想定していますが、このようなアプローチは使用しないことをお薦めします。さらに、この例は、特定のデプロイメント、特にHttpSessionを複数のJ2EEアプリケーションに伝播しているデプロイメントでは、正しく機能しない場合があります。 |
設定
SP統合エンジンは、Oracle Identity Federationで使用されるユーザー・データ・ストアとは相互作用しません。OC4J_FEDインスタンスには、複数のJ2EEアプリケーションがデプロイされます。
パッケージ
SP統合エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。
oc4jintegration.jsp: フェデレーション・サーバーからのリクエストを処理し、ユーザー識別子が含まれるfeduserid属性を使用してHttpSessionを作成します。
application.jsp: アプリケーションとして機能します。HttpSessionのfeduserid属性を検索し、属性が見つからない場合はフェデレーションSSOをトリガーします。
application.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getSession().getAttribute("feduserid");
if (userid == null || userid.length() == 0) {
String redirectURL = "/fed/sp/initiatesso?providerid=" +
URLEncoder.encode("http://stadm14.us.oracle.com:7778/fed/idp") +
"&returnurl=/engine/application.jsp";
response.sendRedirect(redirectURL);
return;
}
%>
Welcome <%=userid%>
oc4jintegration.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getAttribute("oracle.security.sso.sasso.uid");
Date authnInst = (Date)request.getAttribute("oracle.security.sso.sasso.authnInst");
Date expirationInst = (Date)request.getAttribute("oracle.security.sso.sasso.expiryInst");
String targetURL = (String)request.getAttribute("oracle.security.sso.sasso.targetURL");
request.getSession().setAttribute("feduserid", userid);
response.sendRedirect(targetURL);
%>
Oracle Identity Federationの構成ファイル
$ORACLE_HOME/fed/conf/spmanager/authn-mappings.xmlファイルを変更し、SP統合エンジンのcontextPathおよびrelativePathを定義します。
<authn-mapping> <authn-method>sasso_login_sp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_sp_url</authn-method> <authn-screen>/oc4jintegration.jsp</authn-screen> </authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更してSP統合エンジンのURLを定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true"> .. <AuthMethod Name="SassoSP" LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/sso/logout" /> </SHAREidConfiguration>
ログアウト
このアプリケーションではHttpSessionをOC4J_FEDインスタンスに設定するため、SP統合エンジンをログアウト・フローと統合する必要があります（「ログアウト」を参照）。
この項で示すSP統合エンジンでは、ユーザー名および認証済セッションの有効期限が含まれているCookieに基づく単純なシングル・サインオン・フレームワークを使用します。
|
注意: この例は、説明のみを目的としているため、本番環境では使用しないでください。たとえば、この例で設定されるCookieは暗号化されないため、攻撃者がこのようなCookieを手動で構成することで、ユーザーのなりすましが可能になります。 |
設定
SP統合エンジンは、Oracle Identity Federationで使用されるユーザー・データ・ストアとは相互作用しません。このエンジンは、String変数のユーザー識別子とlong変数のセッション・タイムアウトが含まれるCookieをドメイン全体に対して設定します。
パッケージ
SP統合エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。
domainintegration.jsp: Oracle Identity Federationサーバーからのリクエストを処理し、ユーザーIDおよびセッション・タイムアウトを含むCookieを作成します。
domainapplication.jsp: アプリケーションとして機能します。Cookieを検索し、Cookieが見つからない場合はフェデレーションSSOをトリガーします。
domainapplication.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*, java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
Cookie[] cookies = request.getCookies();
String userid = null;
Date timeout = null;
for(int i = 0, size = (cookies != null ? cookies.length : 0); i < size; i++) {
String name = cookies[i].getName();
if ("spintegrationcookie".equals(name)){
String value = cookies[i].getValue();
StringTokenizer st = new StringTokenizer(value, "*");
userid = st.nextToken();
timeout = new Date(Long.parseLong(st.nextToken()));
break;
}
}
if (userid == null || userid.length() == 0) {
String redirectURL = "http://stadm04.us.oracle.com:7778" +
"/fed/sp/initiatesso?providerid=" +
URLEncoder.encode("http://stadm14.us.oracle.com:7778/fed/idp") +
"&returnurl=" + URLEncoder.encode(
"http://stadm04.us.oracle.com:7778/engine/domainapplication.jsp");
response.sendRedirect(redirectURL);
return;
}
%>
Welcome <%=userid%>. You are logged until <%=timeout%>
domainintegration.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String userid = (String)request.getAttribute("oracle.security.sso.sasso.uid");
Date authnInst = (Date)request.getAttribute("oracle.security.sso.sasso.authnInst");
Date expirationInst = (Date)request.getAttribute("oracle.security.sso.sasso.expiryInst");
String targetURL = (String)request.getAttribute("oracle.security.sso.sasso.targetURL");
String cookieValue = userid + "*" + expirationInst.getTime();
Cookie cookie = new Cookie("spintegrationcookie", cookieValue);
cookie.setDomain(".us.oracle.com");
cookie.setPath("/");
response.addCookie(cookie);
response.sendRedirect(targetURL);
%>
Oracle Identity Federationの構成ファイル
$ORACLE_HOME/fed/conf/spmanager/authn-mappings.xmlファイルを変更し、SP統合エンジンのcontextPathおよびrelativePathを定義します。
<authn-mapping> <authn-method>sasso_login_sp_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_login_sp_url</authn-method> <authn-screen>/domainintegration.jsp</authn-screen> </authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更してSP統合エンジンのURLを定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true">
…
<AuthMethod Name="SassoSP" LoginURL="/engine/domainintegration.jsp" LogoutURL="/sso/logout" />
</SHAREidConfiguration>
ログアウト
このサンプルのアプリケーションではドメインCookieを設定するため、SP統合エンジンをログアウト・フローと統合する必要があります（次の「ログアウト」を参照）。
この項では、ログアウト・フローを構成する方法を説明します。
ログアウト・フローでは、図4-2に示すように、アイデンティティ・フェデレーション・エンジンはSP統合エンジンと認証エンジンを単一のエンティティであると考えます。
ここでは、ログアウト処理の起動時に、複数のOracle Identity Federationモジュールによって実行されるアクションについて説明します。
ユーザーは以前に、Oracle Identity FederationにアクセスしてSSO処理を実行しています（SPまたはIdPモード）。
このユーザーが、次の問合せパラメータを使用して、Oracle Identity Federationのログアウト・サービスURL /fed/user/logoutにアクセスします。
returnurl: ログアウト処理の完了後にユーザーのリダイレクト先となるURL（オプション）。詳細は、「ログアウト・サービスの構成」を参照してください。
Oracle Identity Federationのユーザー・セッションが、ログアウト中とマークされます。
Oracle Identity Federationが、/sso/logout URLにある認証およびSP統合エンジンのセッション終了を担当するサーブレットにユーザーをリダイレクトします。このサーブレットは、IAMフレームワークと相互作用してログアウト操作を実行する場合があります。Oracle Identity Federationからログアウト・サーブレットへのリダイレクトには、次の問合せパラメータが含まれることがあります。
invokeOSFSLogout: ユーザーをIAMおよび認証/SP統合エンジンからログアウトした後にログアウト認証およびSP統合サーブレットがユーザーを/fed/user/logoutsso URLにリダイレクトするかどうかを示すブール値。このパラメータが存在しない、またはfalseの場合、ローカル・ログアウトの完了後にdoneURLパラメータを使用してユーザーをリダイレクトする必要があります。
doneURL: ユーザーをIAMおよび認証/SP統合エンジンからログアウトした後にユーザーのリダイレクト先となるURLを含んでいるURLエンコード値。このパラメータは、invokeOSFSLogoutがfalseまたは存在しない場合に使用されます。
ユーザーがOracle Identity Federationにリダイレクトされ、リモート・プロバイダを使用してフェデレーション・ログアウト操作が実行されます。
フェデレーション・ログアウト手順の実行後、Oracle Identity Federationのユーザー・セッションが破棄されます。
ユーザーがreturnurlの位置にリダイレクトされます。
この項には、ログアウト中のリダイレクションに関連する内容が含まれます。
URL
ユーザーは、ログアウト操作中に、フェデレーション・エンジンと、認証およびSP統合エンジンのログアウト・サービスとの間でリダイレクトされます。
Oracle Identity Federationは、ユーザーをサーブレット/jspページにリダイレクトしてログアウトするために、ログアウト・サービスの場所を認識している必要があります。このURLは、authn-mappings.xmlファイルに定義されています。URLは、contextPathとrelativePathの結合として定義できます。
contextPathは、Webアプリケーションのルート・コンテキスト・パスです。たとえば、Oracle Identity FederationのcontextPathは/fedです。
relativePathは、ユーザーの転送先となるサービスURLであり、contextPathに相対的です。たとえば、認証およびSP統合エンジンのデフォルトのログアウト場所は/logout（relativePath）です。
次のファイルを変更してこれらのURLを構成します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
値がsasso_logout_contextと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値を新規認証エンジンのcontextPathに変更します（デフォルトでは、この値は/ssoに設定されています）。
値がsasso_logout_urlと等しい<authn-method>を含む<authn-mapping>要素で、対応する<authn-screen>の値をログアウト・サービスのrelativePathに変更します（デフォルトでは、この値は/logoutに設定されています）。
SAML 1.xおよびWS-Fedプロトコルも、新規ログアウト・サービスのcontextPathおよびrelativePathを認識している必要があります。これらのURLを構成するには、$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを次のように変更します。
LoginConfig XML要素で、Name属性がSassoと等しいAuthnMethod要素を検索し、LogoutURL属性をcontextPathとrelativePathを連結したものに設定します。
LoginConfig XML要素で、Name属性がSassoSPと等しいAuthnMethod要素を検索し、LogoutURL属性をcontextPathとrelativePathを連結したものに設定します。
<LogoutConfig> XML要素で、SassoURL属性をcontextPathとrelativePathを連結したものに設定します。
|
注意: Oracle Identity FederationにおけるSAML 1.x/WS-Fedプロトコルの制限により、relativePathに含めることのできる"/"文字は1つのみです。contextPathには制限はありません。たとえば、contextPathを/path1/path2/path3に設定することはできますが、relativePathは/path4への設定のみが可能であり、/path5/path6の値はrelativePathには無効です。 |
これらの変更を永続化するには、最上位の<SHAREidConfiguration> XML要素のuseLocalConfig属性をtrueに設定します。
authn-mappings.xmlファイルの変更後、OC4J_FEDインスタンスを再起動します。
ログアウト・サービスの実装
ログアウト・サービスでは、次の操作を実行する必要があります。
フェデレーション・エンジンからのリクエストの処理。
統合されているIAMフレームワークとの相互作用によるユーザーのログアウト。
Oracle Identity Federationとバンドルされている認証エンジンとSP統合エンジンの両方が置き換えられた場合、フェデレーション・エンジンまたはdoneURLパラメータへのユーザーのリダイレクト。
認証エンジンとSP統合エンジンの一方のみが置き換えられた場合、Oracle Identity Federationから渡された問合せパラメータ（invokeOSFSLogoutやdoneURL）による/sso/logout URLのリダイレクト。これが必要なのは、デフォルトのOracle Identity Federationエンジンの一方が使用されており、ユーザー・セッションをこのモジュールからログアウトする必要があるためです。
次の2つの項では、ログアウト・サービスの次の使用例を概説します。
ログアウト・サービス例1では、認証エンジンとSP統合エンジンの両方がカスタマイズされている場合のカスタム・ログアウト・サービスについて説明します。
ログアウト・サービス例2では、SP統合エンジンのみがカスタマイズされている場合のカスタム・ログアウト・サービスについて説明します。
この項では、認証エンジンとSP統合エンジンの両方がカスタマイズされている場合、つまり、デフォルト・エンジンが使用されていない場合に、カスタム・ログアウト・サービスを統合する方法を説明します。
設定
この例では、認証エンジンは3.3.2で説明したLDAPエンジンであり、SP統合エンジンは「サンプルの統合モジュール1: OC4J_FED統合」で説明したOC4J_FED統合エンジンです。
パッケージ
ログアウト・サービスは、認証およびSP統合エンジンとバンドルされている次のJSPページで構成されています。
logout.jsp: Oracle Identity Federationサーバーからのリクエストを処理し、oc4jintegration.jspページに設定されているfeduserid属性をHttpSessionオブジェクトから削除し、ユーザーをOracle Identity FederationまたはdoneURLパラメータにリダイレクトします。
logout.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String oifContext = "/fed";
String oifLogoutPath = "/user/logoutsso";
String invokeOSFSLogout = request.getParameter("invokeOSFSLogout");
String doneURL;
if ("true".equals(invokeOSFSLogout))
doneURL = oifContext + oifLogoutPath;
else
doneURL = request.getParameter("doneURL");
request.getSession().removeAttribute("feduserid");
response.sendRedirect(doneURL);
%>
Oracle Identity Federationの構成ファイル
次のファイルを変更し、認証エンジンのcontextPathおよびrelativePathを定義します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
<authn-mapping> <authn-method>sasso_logout_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_logout_url</authn-method> <authn-screen>/logout.jsp</authn-screen> </authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更してログアウト・サービスのURLを3箇所で定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true">
<LoginConfig>
…
<AuthMethod Name="Sasso" LoginURL="/engine/loginpage.jsp"
LogoutURL="/engine/logout.jsp" />
<AuthMethod Name="SassoSP"
LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/engine/logout.jsp" />
</LoginConfig>
<LogoutConfig Protocol="http" HostName="…"
Port="…" SassoURL="/engine/logout.jsp" OsfsURL="/fed/user/logoutwsfed" />
</SHAREidConfiguration>
この項では、SP統合エンジンのみがカスタマイズされている場合、つまり、デフォルトの認証エンジンがまだ使用されている場合に、カスタム・ログアウト・サービスを統合する方法を説明します。
設定
この例では、認証エンジンはOracle Identity Federation管理コンソールで構成されたLDAPスタンドアロンであり、SP統合エンジンは「サンプルの統合モジュール1: OC4J_FED統合」で説明したOC4J_FED統合エンジンです。
パッケージ
ログアウト・サービスは、認証およびSP統合エンジンとバンドルされている次のJSPページで構成されています。
logout.jsp: Oracle Identity Federationサーバーからのリクエストを処理し、oc4jintegration.jspページに設定されているfeduserid属性をHttpSessionオブジェクトから削除し、invokeOSFSLogoutおよびdoneURLパラメータを使用してユーザーを/sso/logout URLにリダイレクトします。
logout.jspの実装
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
String ssoLogout = "/sso/logout";
String invokeOSFSLogout = request.getParameter("invokeOSFSLogout");
String doneURL = request.getParameter("doneURL");
String queryString = "";
if (invokeOSFSLogout != null && invokeOSFSLogout.length() > 0)
queryString = queryString + "invokeOSFSLogout=" + URLEncoder.encode(invokeOSFSLogout);
if (doneURL!= null && doneURL.length() > 0)
{
if (queryString.length() > 0)
queryString = queryString + "&";
queryString = queryString + "doneURL=" + URLEncoder.encode(doneURL);
}
if (queryString.length() > 0)
ssoLogout = ssoLogout + "?" + queryString;
request.getSession().removeAttribute("feduserid");
response.sendRedirect(ssoLogout);
%>
Oracle Identity Federationの構成ファイル
次のファイルを変更し、認証エンジンのcontextPathおよびrelativePathを定義します。
$ORACLE_HOME/fed/conf/idpmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/spmanager/authn-mappings.xml $ORACLE_HOME/fed/conf/usermanager/authn-mappings.xml
各ファイルでは、次の一連の同じ変更が必要です。
<authn-mapping> <authn-method>sasso_logout_context</authn-method> <authn-screen>/engine</authn-screen> </authn-mapping> <authn-mapping> <authn-method>sasso_logout_url</authn-method> <authn-screen>/logout.jsp</authn-screen> </authn-mapping>
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを変更してログアウト・サービスのURLを3箇所で定義し、再起動時に変更が強制的に保持されるようにuseLocalConfig属性をtrueに設定します。
<SHAREidConfiguration … useLocalConfig="true">
<LoginConfig>
…
<AuthMethod Name="Sasso" LoginURL="/engine/loginpage.jsp"
LogoutURL="/engine/logout.jsp" />
<AuthMethod Name="SassoSP"
LoginURL="/engine/oc4jintegration.jsp" LogoutURL="/engine/logout.jsp" />
</LoginConfig>
<LogoutConfig Protocol="http" HostName="…"
Port="…" SassoURL="/engine/logout.jsp" OsfsURL="/fed/user/logoutwsfed" />
</SHAREidConfiguration>
Metalink Note 427374.1には、実際のSP統合エンジンのソース・コードが含まれています。これに含まれるファイルは次のとおりです。
cookieprovider.jsp（ユーザーCookieを生成）
testapplication.jsp（Cookieを検索してデプロイメントをテスト）
GenericSPCookieProvider.EAR
このNoteでは、この実用例に関する次のような詳細が説明されています。
EARの機能の説明
アプリケーション・サーバーへのEARファイルのデプロイ方法
EARデプロイメントのテスト方法
このMetalink Noteは、http://webiv.oraclecorp.com/cgi-bin/webiv//do.pl/Get?WwwID=note:427374.1にあります。
Oracle Identity Federationは、SAML 1.0/1.1またはWS-Federationプロトコルを使用する場合、IDおよびアクセス管理システムの要不要に関係なく、HTTP Basic資格証明を承諾するように構成できます。
|
注意: この項で説明する方法は、Oracle Identity FederationがIdPとして機能している場合にのみ適用できます。Oracle Identity FederationがSPの場合は適用できません。 |
IdPとして機能しているOracle Identity FederationがOracle Access ManagerなどのIDストアに対してユーザーを認証する環境では、Basic認証を構成できます。ブラウザ・アーティファクト（またはブラウザPOST）プロファイルを使用した一般的なフローは次のとおりです。
ブラウザ以外のクライアントが、IdPにインストールされているOracle Identity Federationサーバーを使用して、SPにあるアプリケーションとのフェデレーションを要求します。このクライアントは、HTTP GETリクエストをIdPに送信します。
Oracle Identity Federation IdPが、401 Not Authorizedレスポンスをクライアントに返送します。
クライアントが、指定外の手段で取得したHTTP BasicまたはNTML資格証明を含む認可ヘッダーを使用して、GETを再送します。
IdPが、認可ヘッダー内の資格証明を使用して、ユーザーをそのIDストアに対して認証します。
Oracle Identity Federation IdPは次に、ユーザー用のアサーションを作成し、（アーティファクト・プロファイルに対して）そのアサーションをアーティファクトに関連付け、アーティファクトとターゲットURLを含む302 RedirectレスポンスをSPのアサーション受信者サーバー用のクライアントに送信します。
クライアントは、GETリクエストをSPのアサーション受信者サービスに送信することで、このリダイレクトに応答します。
SPのアサーション受信者サービスは、GETリクエストを処理し、IdPをアーティファクトから判断し、アーティファクト取得リクエストをIdPのSOAPレスポンダ・サービスに送信します。IdPはアーティファクトに関連付けられているアサーションを返し、SPはアーティファクトに適切な処理を実行してターゲットURLへのアクセスを許可します。
クライアントは、GETリクエストをアプリケーションに送信することで、このリダイレクトに応答します（手順6でSSO Cookieが設定された場合、そのCookieも送信されます）。
アプリケーションがWebアクセス・マネージャで保護されている場合、アクセス・マネージャはSSO Cookieを受け入れ、アプリケーションへのアクセスを許可します。また、アプリケーションでは、アサーションをSP SAMLコンポーネントから直接取得し、これを使用してアクセスを認可する場合もあります。
Oracle Access Manager（OAM）の使用時にこのフローでHTTP Basic認証を使用する手順:
OAM Policy Managerを使用して、フェデレーション・ドメインのポリシー・ドメイン（OAMを使用するようにOracle Identity Federationが構成されている場合に自動的に設定されるドメイン）内の転送サービス・ポリシーを変更し、Basic認証スキームを使用するように設定します。選択したOAM設定オプションに応じて、事前構成済のいくつかのBasicスキームを使用できます。
OAM OHS WebGateエージェントをOracle Identity FederationのHTTP_Serverコンポーネントにインストールします。手順1で設定した転送サービス・ポリシーに基づいて、WebGateは401レスポンスをクライアントに返送し、クライアントからの認可ヘッダーを使用してObSSOCookieを作成します。このCookieは、Oracle Identity Federationで使用されます。
|
注意: この手順では、Oracle Access Managerバグ5736326に対する修正が必要です。 |
Oracle Identity FederationがIDストアに対してユーザーを認証しない環境では、Basic認証を構成できます。このフローは、「IDストアを使用したBasic認証」で説明したフローと類似しています。
この使用例でのBasic認証の構成は、$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルから開始します。このファイルに含まれているLoginConfig要素は、デフォルトでは次のとおりです。
<LoginConfig AuthMethod="Sasso" LogoutPage="/shareid/logout.jsp"
LoggedInPage="/shareid/loggedIn.jsp" SSOCookieDomain=".us.oracle.com">
<AuthMethod Name="Basic" RealmName="SHAREid Login" />
<AuthMethod Name="Form" LoginPage="/shareid/login.jsp" />
<AuthMethod Name="External" Header="userid" />
<AuthMethod Name="Sasso" LoginURL="/sso/authn" LogoutURL="/sso/logout" />
<AuthMethod Name="SassoSP" LoginURL="/sso/authn" LogoutURL="/sso/logout" />
</LoginConfig>
デフォルトのAuthMethodは、「IDストアを使用したBasic認証」で説明したSassoコンポーネントであり、フォームベースのログインのみを実行できます。LoginConfig要素内のAuthMethod属性をBasicに変更すると、SAML 1.x用のHTTP Basicメソッドがアクティブになります。必要に応じて、401レスポンスで使用されるレルムをRealmName属性で構成することもできます。
この項では、WebGateコンポーネントをインストールし、Oracle Identity FederationサーバーにバンドルされているHTTPサーバーと統合する方法を説明します。
この使用例では、「Oracle Identity FederationとOracle Access Managerのデプロイ」および「ユーザー・データ・ストアの編集」で示したように、Oracle Identity FederationがOracle Access Managerとすでに統合されていることを前提にしています。
次の手順に従って、WebGateを統合します。
アクセス・システム・コンソールを使用して新規AccessGateを作成し、Oracle Identity Federationが実行されているアプリケーション・サーバーのOracle HTTP Server上に対応するWebGateをインストールします。
WebGateをOracle HTTP Serverにインストールする方法は、Oracle Access Managerのマニュアルを参照してください。
Oracle Identity FederationのログインJSPページを次のように変更します。
|
注意: これは、特定のタイプの認証スキームが正しく機能するために必要な手順です。 |
$ORACLE_HOME/j2ee/OC4J_FED/applications/sso/web/jsp/salogin.jspファイルをバックアップします。
$ORACLE_HOME/j2ee/OC4J_FED/applications/sso/web/jsp/salogin.jspを編集し、次の内容に置き換えます。
<%
response.sendRedirect("/fed/user/sassoredirectlogin?" + request.getQueryString());
%>
Oracle Access Managerポリシーを構成します。
アクセス・システム・コンソールから、ポリシー・マネージャのセクションに移動し、フェデレーション・ドメイン・ポリシーを選択します。
「リソース」タブをクリックします。
/shareidリソースURLを確認し、「削除」をクリックします。
「追加」をクリックし、次のURLを使用して新規リソースを追加します。
/shareid/saml/userAttributes /shareid/saml/mapping /shareid/sasso
WebGate/Oracle Identity Federationで使用するOracle Access Managerポリシーを作成します。
アクセス・システム・コンソールから、ポリシー・マネージャのセクションに移動します。
新規ポリシー・ドメインを作成して名前を入力し、「保存」をクリックします。
|
注意: このポリシーは、Oracle Identity Federationのログイン・プロセスURLを保護するために使用されます。 |
「リソース」タブから、次のURLを追加します。
/fed/user/sassoredirectlogin /shareid/sassologin.jsp
「デフォルト・ルール」タブに移動し、「認証ルール」サブタブをクリックします。
使用する認証スキームを選択します（FORM BasedまたはBasicなど）。
「認可ルール」タブに移動します。
新規認可ルールを追加して有効化します。「保存」をクリックします。
「アクセスの許可」サブタブに移動します。
Oracle Identity Federationにアクセスできるユーザーを構成し（全ユーザーの場合はAnyoneなど）、「保存」をクリックします。
「デフォルト・ルール」タブに移動し、「認可条件式」サブタブを選択します。
前の手順で作成した認可ルールを追加し、「保存」をクリックします。
「ポリシー・ドメイン」リストに移動します。
新規作成したポリシーを選択して有効化します。
