| Oracle Identity Federation管理者ガイド 10g（10.1.4.0.1） B31476-02 |
|
 戻る |
 次へ |
この章では、フェデレーテッドID管理の概要、およびOracle Identity Federationの特長や利点について説明します。内容は次のとおりです。
シングル・サインオン（SSO）は繰返しログインする必要性が少なくなるため幅広く採用されていますが、フェデレーテッド環境、つまり、サービスをビジネス・パートナと共有しつつ、そのサービスを不正アクセスから防御する必要がある環境で運用する企業の場合、SSOでは不十分です。
フェデレーテッド環境は、各ビジネス・パートナがそれぞれのセキュリティ・ドメインを横断してID情報を共有するメカニズムを提供することにより、ID管理レルムにおける統合を達成できます。
この項では、フェデレーテッドID管理の概要について説明します。内容は次のとおりです。
Webベースのアプリケーションへのシングル・サインオンは、この数年間、各種の方法で取り組まれ、解決されてきたビジネス目標です。それでもなお、企業情報システムを効率的なコストで管理するためには、次のような大きな課題があります。
それらのソリューションの多くが独自規格のものであるために、プロトコルとソフトウェアが特定ベンダー、実装業者、またはデプロイ・シナリオに限定され、他のシングル・サインオン・システムとの相互運用に適していません。
コンテンツ・フォーマット、サプライ・チェーン、顧客管理システムおよびユーザー・データ・ストアが急増するため、セキュリティとメンテナンスに問題が生じます。たとえば、医療機関にサービスを提供している金融サービス会社の場合、何十万もの従業員アカウントを管理する必要があったり、パスワードの紛失などのイベントやその他のレコード・メンテナンスに対処しながら新しいユーザーをプロビジョニングするために多大なコストが発生する可能性があります。ユーザーの側では、認証システムが様々であるために、複数のIDとパスワードを記憶したり、場合によっては書き留めておくことが必要になりますが、それを行うことは言うまでもなく危険です。
絶えず規模が拡大し、活動的になるエンドユーザー・コミュニティでは、情報とアプリケーションに、従業員だけではなく、ベンダー、パートナと顧客からもアクセス可能であることが必要です。従来のアクセス提供の取組みでは、組織内部で個人ユーザーのアカウントを保守する必要があり、IDデータが重複したり、管理やコンプライアンス上の問題が発生する可能性があります。
フェデレーテッドID管理はSSOパラダイムの進化形で、自社の境界外にあるコンピューティング・リソースやサービスにアクセスする必要性の高まりに応えるものです。フェデレーテッド環境では、そうしたサービスを提供する企業が、個人やその他のエンティティのID情報を、ユーザーの本拠である組織やセキュリティ・ドメインから、信頼性を保って取得できます。これには、次のような利点が伴います。
ビジネスが行われている各エンティティにアクセスするエンド・ユーザーが、ログイン資格証明を提示する必要がありません。これにより、多数のログイン名やパスワードを記憶、管理する必要がなくなります。（ただし、両方のアカウントをリンクするために、それぞれのサイトにアカウントが必要です。）
いずれかのパートナ組織にすでに認識されているユーザーのIDを管理するために新しいアカウントを作成する必要はありません。先ほどの例で言えば、サービス・プロバイダはクライアントの医療機関が内部的に維持していた従業員データを活用することができます。
この項のユースケースでは、複数のアプリケーションに対する認証を1度のみ行うことで、フェデレーションがエンドユーザーにスムーズな操作感を提供し、前述のような実際のビジネスでの問題を克服できることを説明します。
ユースケース1: パートナ・サイトへのシングル・サインオン
図1-1は、MyCorpの従業員Maryが次の出張計画を立てようとしている状況を示しています。次の手順を実行することによって、Maryは1つのセッションでスムーズに計画を完成できます。
Maryが自分の端末から自社のMyCorp従業員ポータルにアクセスします。
WS-Federationに対応したポータルにサインオン・ダイアログが表示されます。
Maryがサインオンすると、ポータルにより、Maryの情報が表示されたパーソナライズ・ページが返されます。
Maryは出張計画の作成を開始するにあたり、ポータル内でTravelClubのリンクをクリックします。TravelClubは、MyCorp従業員に一連の旅行サービスへのアクセスを提供するパートナ組織です。MaryはTravelClubとの間にフェデレーテッド関係をすでに確立しています。
TravelClubでは、Maryが自分のアカウントにアクセスするために認証を行う必要があり、MyCorpに対しても同じ認証を要求します。MyCorpはTravelClubに対して必要なID情報を返します。これで、MaryはTravelClubサイトに自動的に認証されます。TravelClubがMaryの出張アカウント情報が表示されたページを返します。
Maryの作業が終了したら、シングル・グローバル・ログアウト機能を使用して、MyCorpのホームページからTravelClubとMyCorpの両方のセッションをログアウトできます。
この方法では、Maryは自社のWebサイトで1度認証を受けるだけで別のサイトに接続して必要なタスクを実行でき、2番目のサイトであらたに認証を受ける必要がありません。
ユースケース2: パートナ・サイトでの新規フェデレーテッド・アカウント
図1-2のユースケースでは、MyCorpの別の従業員であるJimがMyCarsに新規アカウントを設定しようとしています。MyCarsは、MyCorpの従業員に格安の自動車修理サービスを提供する外部サイトです。手順は次のとおりです。
JimがMyCorpポータルにサインオンします。
Jimはポータル内で作業した後で、ポータルの「Vendors」ページに移動して自動車修理サービスを探すために「MyCars」リンクをクリックします。
MyCarsに新規アカウントを設定するための情報が要求されます。MyCarsはJimの権限を使用して、JimのIDに関連する情報を取得するためにMyCorpと通信します。
これでJimはMyCarsのアカウントを取得できました。このアカウントには、先ほどのユースケースで説明したのと似た方法でアクセスできます。
これらのユースケースは、フェデレーテッド・シングル・サインオンとフェデレーテッドID管理の一般的な使用例です。次の各項で、フェデレーション・テクノロジのキー・コンセプトと、Oracle Identity Federationでのその活用法について詳しく見ていきます。
この項ではフェデレーテッドID管理の主要な概念を説明します。
プリンシパル
プリンシパルはサービスを使用でき、フェデレーテッドIDを入手できるあらゆるエンティティです。
プリンシパルとは、そのIDが認証を受けることができる、人（「ユーザー」）、ユーザーのグループ（会社など）またはシステム・エンティティです。
これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にアイデンティティ・プロバイダ（IdP）とサービス・プロバイダ（SP）があります。
ドメイン
ドメインとは、プリンシパルがリソースを使用できるWebサイトおよびアプリケーションです。フェデレーテッド・サイトはアイデンティティ・プロバイダ（一部の仕様ではソース・ドメイン）か、サービス・プロバイダ（宛先ドメイン）、またはその両方です。
アイデンティティ・プロバイダ
アイデンティティ・プロバイダは、指定されたトラスト・サークル内でIDの集合を管理、認証および宣言します。
アイデンティティ・プロバイダは、他のサービス・プロバイダと連携するためのビジネス・インセンティブを提供するサービス・プロバイダです。
これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にプリンシパルとサービス・プロバイダがあります。
アイデンティティ・プロバイダは、SAML 1.xプロトコルではソース・ドメインとも呼ばれます。この観点では、ソース・ドメインのユーザーが、アクセス先ドメインにあるサイト上のリソースにアクセスするための許可をリクエストする、リクエストの発生箇所がアイデンティティ・プロバイダです。
サービス・プロバイダ
サービス・プロバイダは、プリンシパルにサービスや商品を提供します。ただし、プリンシパルのID認証はアイデンティティ・プロバイダに委ねます。
サービス・プロバイダは、リライング・パーティ（SAML）または宛先ドメインとも呼ばれます。ドメインの観点からすると、サービス・プロバイダには、ソース・ドメインのユーザーがアクセスするリソースが含まれます。
サービス・プロバイダはユーザーにWebベースのサービスを提供する組織です。この広範なカテゴリには、たとえば次のような、実質的にすべてのWeb上の組織が含まれます。
インターネット・ポータル
小売業者
金融機関
行政機関
NPO（非営利組織）
娯楽産業
運送業者
これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にアイデンティティ・プロバイダとプリンシパルがあります。
|
注意: 1つの組織が、一般的あるいは特定の相互作用のコンテキスト内で、アイデンティティ・プロバイダとサービス・プロバイダの両方であることがあります。 |
トラスト・サークル
トラスト・サークルは、一連のアイデンティティ・プロバイダとサービス・プロバイダの間の信頼関係です。これによりプリンシパルは、そのサークル内のプロバイダとビジネス・トランザクションを実行する際に、単一のフェデレーテッドIDとシングル・サインオンを使用できます。
組織は、フェデレーション・テクノロジおよび各当事者間の信頼関係を定義する運用協定に基づいて、トラスト・サークルに加入します。
たとえば、企業トラスト・サークルでは、アイデンティティ・プロバイダは企業を横断して従業員ネットワークIDを活用する会社です。
別の例は消費者バンキング・トラスト・サークルで、ここではユーザーの銀行が他の各種サービス・プロバイダとビジネス関係を確立しており、ユーザーはそれらのプロバイダに対して銀行ベースのネットワークIDを使用できます。
|
注意: トラスト・サークルには、複数のアイデンティティ・プロバイダがある場合があります。 |
アイデンティティ・フェデレーション
アイデンティティ・フェデレーションとは、指定されたトラスト・サークル内の1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダでプリンシパルが所持している場合がある、2つ以上のアカウントの結びつきです。
ユーザーが複数のビジネスに対して持っている、相互に独立している個別のアカウント（ローカルID）をフェデレートすると、2つのエンティティ間にリレーションシップ（任意の数のサービス・プロバイダとアイデンティティ・プロバイダで構成される関係付け）が作成されます。
シングル・サインオン
シングル・サインオンの場合、ユーザーはアイデンティティ・プロバイダとサービス・プロバイダのフェデレーテッド・グループのメンバー（プロバイダの視点からはトラスト・サークルのメンバー）に対して1度サインオンすれば、そのグループ内の各種のリソースをそれ以降使用でき、再び署名する必要がありません。
Libertyプロトコルで、プリンシパル、SPおよびIdPの間でシングル・サインオン運用を実行するには、次の条件が必要です。
SPとIdPが同一のトラスト・サークルにある（信頼されているビジネス・リレーションシップがある）こと。
プリンシパルが、SPとIdPの両方にローカル・アカウントを持っており、その2つのアカウントがフェデレーテッド関係にあること。
セキュリティ・ドメインを横断する相互運用性、保証および信頼上の問題に対処するフェデレーテッド・アーキテクチャの構築では、ID管理統合で有用な構築ブロックとして次のプロトコルが注目を集めています。
Security Assertions Markup Language（SAML）: オンライン・ビジネス・パートナの間でのセキュリティ情報を交換するための手段として、OASISによって開発された標準です。二者間の一般的なSAMLメッセージ交換では、片方がリライング・パーティ、もう一方がアサーティング・パーティとなります。アサーティング・パーティは、特定のサブジェクトについて、そのサブジェクトが認証されているかどうか、あるアクションを実行する権限を認可されているかどうかなどの情報を宣言します。
リライング・パーティは、アサーティング・パーティが提供した情報を使用して、サブジェクトに関するセキュリティ関連の決定を行います。たとえば、そのサブジェクトが許可される特定のリソースに対するアクセスの種類などを決定します。
Liberty Identity Federation Framework（Liberty ID - FF）はLiberty Allianceによって開発された標準です。その目標は次のとおりです。
フェデレーテッド・ネットワークIDによりサインオンを単純化します。
権限ベースの属性共有のサポートにより、ユーザーの個人識別データの使用と開示をユーザー自身がコントロールできるようにします。
SAMLとLibertyプロトコルは、セキュリティ・ドメイン相互の間での情報の交換、プロバイダ間の調整（「ハンドシェイク」）、およびフェデレーテッド・サインオンとグローバル・ログアウトなどの識別イベントの管理のためのフレームワークを提供します。次のプロトコルがあります。
SAML 1.0および1.1。セキュリティ・データ交換（アサーション）で使用するフォーマットや、アサーションの使用手段を提供するプロファイルを定義します。
Liberty ID-FF 1.0および1.1。SAML 1.0の拡張で、アカウントのリンキング、調整などのタスクのための追加プロファイルを提供します。
Liberty ID-FF 1.2。
SAML 2.0。Liberty ID-FF 1.2が組み込まれています。
WS-Federation。参加しているWebサービスの間でのID、ユーザー属性、認証の信頼を仲介することによって、異なるセキュリティ・レルムのフェデレーションを可能にします。
これらの標準は、ドメインを超えてセキュリティ情報を通信するためのXMLベースのフレームワークを提供します。次のような利点があります。
ドメインの疎結合。ディレクトリ間でユーザー・データを同期したりレプリケートする必要がありません。
プラットフォームやテクノロジに中立な手法。クロスドメイン統合の障害を除去します。
アプリケーション・サーバー、Webサービス管理、およびセキュリティ製品、セキュリティ・ベンダーにより広くサポートされ、採用する組織は増え続けています。
この項では、基礎的なSAMLの概念とフェデレーション・プロトコルについて詳しく説明します。内容は次のとおりです。
Oracle Identity Federationでサポートされているプロファイルの詳細は、「フェデレーション・プロトコル・プロファイル」を参照してください。
二者間の一般的なSAMLメッセージ交換では、片方がリライング・パーティ、もう一方がアサーティング・パーティとなります。
アサーティング・パーティは、特定のサブジェクトについて、そのサブジェクトが認証されているかどうか、あるアクションを実行する権限を認可されているかどうかなどの情報を宣言します。リライング・パーティは、アサーティング・パーティが提供した情報を使用して、サブジェクトに関するセキュリティ関連の決定を行います。たとえば、そのサブジェクトが特定のリソースに対して許可されるアクセスの種類などを決定します。
SAMLアサーション
SAMLは、特定のドメイン内でのプリンシパルのアクセス権限を決定する際に使用できる追加のID情報にプリンシパルを関連付けます。SAMLドキュメントはすべて、こうした関連付けを含むアサーション要素を持っています。
SAMLは、次の3種類のアサーションを定義します。これらはサブジェクトに関する1つ以上の事実の宣言です。
認証アサーション。ユーザーの識別情報が、特定の時刻において特定の方法によって証明されていることを明示します。
属性アサーション。従業員番号やアカウント番号など、ユーザーに関する固有の詳細情報が含まれます。
認可アサーション。ユーザーがアクセスできるリソースと、アクセス可能な条件を明示します。
アサーションはすでに発生したイベントについて生成される、コード化された文です。
|
注意: SAMLは資格証明についてアサーションを行いますが、実際にユーザーを認証あるいは認可するわけではありません。 |
例1-1は、SAMLPレスポンス・メッセージにラップされた典型的なSAML 1.0認証アサーションを示しています。
SAMLのリクエストとレスポンスのサイクル
通常のSAMLサイクルでは、特定のクライアント・リクエストを認証する必要があるリライング・パーティが、SAMLリクエストを発行認証局に送信します。発行認証局はSAMLアサーションで回答し、リクエストされたセキュリティ情報をリライング・パーティに提供します。このサイクルを図1-3に示します。
たとえば、ユーザーがリライング・パーティのSAML準拠サービスにサインインする場合、サービスにより発行認証局に「認証アサーションのリクエスト」が送信されます。発行認証局は、そのユーザーが特定の方法で特定の時刻に認証されていることを記述した「認証アサーション」参照を返します。通常の認証アサーションの詳細は例1-1を参照してください。
サービスは、ユーザーの資格証明を検証するために他のリライング・パーティ・サイトにこのアサーション参照を渡すことができます。ユーザーが認証を必要とするもう1つのSAML準拠サイトにアクセスすると、そのサイトは参照を使用して発行認証局からの「認証アサーション」をリクエストします。アサーションは、ユーザーがすでに認証されていることを明示します。
発行認証局では、アサーション・レイヤーがSAMLプロトコルを使用してリクエストおよびレスポンスのメッセージを処理します。SAMLプロトコルは、様々な通信および転送プロトコル（HTTP、SOAPなど）にバインドできます。クライアントは常にアサーションのコンシューマになりますが、発行認証局はアサーションを作成および評価できるので、プロデューサとコンシューマの役を果すことができます。
SAMLプロトコルのバインディングとプロファイル
SAMLは、アサーション（SAMLP）をリクエストおよび取得するためのプロトコルを定義します。バインディングは、SAMLメッセージと標準的な通信プロトコルの間にマッピングを提供することで、発行認証局とリライング・パーティにおいてSAMLリクエストとレスポンス・メッセージが転送される標準的な方法を定義します。たとえば、SAMLリクエストおよびレスポンスのために定義されたHTTP経由の転送メカニズムの1つがSimple Object Access Protocol（SOAP）です。これにより、いくつかのWebサービスを横断するSAML情報の標準的な方法での交換が可能になります。
プロファイルは、SAMLアサーションが標準的なフレームワークとプロトコルにどのように組み込まれ、また抽出されるかを記述します。シングル・サインオンのためのWebブラウザ・プロファイルと、SOAPペイロードのセキュリティを確保するためのSOAPプロファイルは、利用可能なプロファイルの一例です。
クロスドメインのシングル・サインオン・アプリケーションを迅速に開発する必要があったアクセス制御ベンダーのニーズに応えるOASIS標準化団体の取組みにより、この種の最初の標準であるSAML 1.0が2002年に生まれました。Liberty AllianceはフェデレーテッドIDのオープン標準に取り組み、SAML仕様の上に構築する形でLiberty 1標準を作成しました。同時期に、別のベンダーと企業のコンソーシアムが、Webサービス指向アプリケーションのための、進化を続ける認証および認可の標準に取り組んでいました。それ以降の取組みにより、WS-Federation標準の開発と、SAMLおよびLiberty標準の拡張と改善が並行して実現しました。これらの様々な標準について次に説明します。
|
関連資料:
|
SAML 1.0では、次の2つの主要な概念が定義されています。
アサーションとも呼ばれるセキュリティ・トークン・フォーマット。任意のIDを特定のアクセス権限に関連付けます。
シングル・サインオンを提供するためにそれらのアサーションをパッケージングする方法を記述したプロファイル。
SAML 1.1は、SAML 1.0にフィードバックと訂正を反映させたものです。
例1-1は、SAMLPレスポンス・メッセージにラップされた典型的なSAML 1.0認証アサーションを示しています。
例1-1 SAML 1.0認証アサーションを含むSAMLPのレスポンス例
<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="123.45.678.90.12345678"
IssueInstant="2005-12-14T10:00:23Z"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success" />
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="123.45.678.90.12345678"
Issuer="IssuingAuthority.com"
IssueInstant="2005-12-14T10:00:23Z" >
<saml:Conditions
NotBefore="2005-12-14T10:00:30Z"
NotAfter="2005-12-14T10:15:00Z" />
</saml:Conditions
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2005-12-14T10:00:20Z">
<saml:Subject>
<saml:NameIdentifier NameQualifier="RelyingParty.com">
john.smith
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>
Liberty ID-FF 1.1は、アイデンティティ・フェデレーションとシングル・サインオンをサポートするための、SAML 1.0の拡張プロファイルです。Libertyのフレームワークでは、アイデンティティ・プロバイダ、サービス・プロバイダおよびプリンシパルの、3タイプのアクターが定義されます。
Libertyのフレームワーク内部では、サービス・プロバイダおよびアイデンティティ・プロバイダのグループは、トラスト・サークルの内部で相互に連携することがあります。これによりプリンシパルは、トラスト・サークル内でプロバイダとのビジネス・トランザクションを実行する際に、単一のフェデレーテッドIDとシングル・サインオンを使用できます。
Liberty ID-FF 1.2は、アイデンティティ・フェデレーションとシングル・サインオンをサポートするための、SAML 1.1の拡張プロファイルです。Liberty ID-FF1.2のフレームワークでは、アイデンティティ・プロバイダ、サービス・プロバイダ、アフィリエーション（サービス・プロバイダのグループ）およびプリンシパルの、4つのタイプのアクターが定義されます。
SAML 2.0には、大部分をLiberty Alliance ID-FF仕様によって開発されたフレームワークに基づくシングル・サインオンのサポートが含まれます。
アイデンティティ・フェデレーションの概念は仕様にありませんが、SAML2.0では、特定の用途のための名前識別子の存在に注意を促しています。SAML2.0は、SAML1.xから継承した名前識別子の他に、Liberty ID - FF 1.2の機能を大幅に反映した、名前が付けられた多くのプロファイルをサポートしています。
例1-2は、SAML 2.0認証アサーションを示しています。
例1-2 SAML 2.0認証アサーション
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0"
ID="id-V01vmFAGUOKmKVJh9-hQ-gsPhX8-"
IssueInstant="2005-10-06T21:03:17.375Z">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://issuingauthority.example.com/
</saml:Issuer>
<!-- signature by the issuer over the assertion -->
<ds:Signature>
...
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
id-V9l9N2S4nA8KlHd0X9Df3KYKm4E-
</saml:NameID>
<saml:SubjectConfirmation Method=
"urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
NotOnOrAfter="2005-10-06T21:03:32.375Z"
Recipient="http://issuingauthority.example.com/fed/sp/art20"
InResponseTo="id-G2mgYgtGH9gu8Nwo8KwxPYrpXKE-"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2006-04-27T16:40:49Z"
NotOnOrAfter="2006-04-27T17:05:49Z">
<saml:AudienceRestriction>
<saml:Audience>
http://serviceprovider.example.com:80/fed/sp
</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2005-10-06T21:01:03.451Z"
SessionIndex="1448745">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
この項では、Oracle Identity Federationで、Oracle Identity Management製品のユーザーや、Oracle APSスタックに慣れていない顧客が、様々なユーザー認証のソースを使用して、異種環境を横断してどのようにビジネス結合に関与するかを説明します。内容は次のとおりです。
Oracle Identity Federationはスタンドアロンの自己完結型フェデレーション・サーバーで、複数ドメインのIDネットワークにおいてシングル・サインオンと認証を提供します。Oracle Identity Federationは、Liberty ID-FFプロトコルやSAMLプロトコルなど、複数のフェデレーテッドIDプロトコルをサポートしています。これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。
Oracle Identity Federationの主要な機能には、次のようなものがあります。
アイデンティティ・プロバイダとサービス・プロバイダの両方を含む環境で、クロスサイトのアクセスと認証を実装可能
外部サイトの構成、有効化および無効化が可能
シングル・サインオンを使用して宛先サイトのアプリケーションにアクセス可能
次に示す主要なフェデレーション・プロトコルのサポート
Liberty ID-FF 1.1
Liberty ID-FF 1.2
SAML 2.0属性レスポンダ機能を含むSAML 2.0
WS-Federation
Oracle Access ManagerおよびOracleAS Single Sign-Onとの統合
プロトコルを超えたシングル・サインオンおよびサインアウトのサポート
アフィリエーションのサポートにより、サービス・プロバイダがフェデレーション情報を共有できるため、フェデレーションの数を削減可能
Oracle Internet Directoryとの統合、および次のサポート
Oracle Access ManagerやCA eTrust SiteMinderなどの広範な認証エンジン
Microsoft Active DirectoryやSun Java System Directory ServerなどのLDAPストアを含むユーザー・データ・リポジトリ
リレーショナル・データベース
X.509証明書検証のサポート
図1-4は、Oracle Identity Federation（OIF）のアーキテクチャと、他のフェデレーション・コンポーネントとOIFの関係を示しています。ここで、Oracle Identity Federationは、他のアイデンティティ・プロバイダとサービス・プロバイダ（追加のOracle Identity Federationインスタンスまたはサード・パーティのプロバイダ）を含むトラスト・サークルのメンバーです。
|
注意: 1つのOracle Identity Federationインスタンスは、1つのIdPと1つのSPしかサポートできません。このため、図に示されている2つのサービス・プロバイダが、どちらもOracle Identity Federationの同一のインスタンスに属することはできません。それらは、トラスト・サークルに参加するピア・プロバイダです。 |
Oracle Identity Federationには、自己完結した軽量の認証サービスが含まれます。IdMBridgeに基づくこのサービス（図1-5）は、Oracle Identity FederationとともにWAR（Web Application aRchive）ファイルにデプロイされ、サーバーと同一のJava仮想マシンで実行されます。
Oracle Identity Federationは、次のような広範な認証メカニズムおよびユーザー・データ・リポジトリと通信できます。
Oracle Identity Management
Oracle Identity Federation認証サービスは、OracleAS Single Sign-OnまたはOracle Access Managerにより保護された次のようなリソースへのシングル・サインオン・アクセスを可能にするように構成できます。
Oracle Collaboration Suite
Oracle E-Business Suite
PeopleSoftモジュール
その他
サード・パーティのアクセス管理ソリューションと併用するためにOracleAS Single Sign-Onがデプロイされていれば、この構成では、Oracle Application Server Single Sign-On（およびOracle Internet Directoryユーザー・リポジトリ）またはOracle Access Manager（および各種のリポジトリ）の他に、サード・パーティのアクセス管理ソリューションも活用できます。
|
注意: Oracle Identity FederationとOracleAS Single Sign-Onの両方がリソースを保護している環境では、いずれかのコンポーネントを、ユーザー・リクエストが保護リソースにアクセスした場合に認証メカニズムとして動作するように構成できます。たとえば、Oracle Identity Federationは、認証リクエストをOracleAS Single Sign-Onに転送できます。また、OracleAS Single Sign-Onは、適切なアイデンティティ・プロバイダを見つけるようにOracle Identity Federationにリクエストできます。詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。同様に、Oracle Identity FederationとOracle Access Managerの両方を含む環境にも類似の機能があります。 |
データ・ストア
Oracle Identity Federationは、次のものにアクセスするように構成できます。
LDAPディレクトリ
RDBMSデータベース
Oracle Access Manager
eTrust SiteMinder
Oracle Identity Federation機能を詳しく見る前に、フェデレーテッド環境でユーザー・アクセスを管理できる処理フローを高水準で考えると役に立ちます。
ユーザーは通常、会社のポータルを介して複数のドメインでアプリケーションにアクセスします。たとえば、Alpha Corp.が、Alphaのユーザー・ログイン、ページ・パーソナライズなどを管理するポータル・サーバーを備えているとします。そのポータル・サーバーは、アプリケーション・サーバー内で動作する自社製ロジックで構成されていたり、市販の製品の場合があります。パートナ会社であるBeta Corp.が、MyBeta.comというタイプのポータルでその技術データベース・アプリケーションの役割を果すことがあります。この場合、それぞれ自社ポータル・サーバーを運用していることになります。
ユーザーは、Oracle Access Manager、CA SiteMinderやその他の製品などのWebアクセス管理（WAM）システムによりアクセスが管理されているAlphaポータルにログインします。次にユーザーは、実際はBeta Corp.がホストしているリソースをクリックします。
この時点でOracle Identity FederationがWAMシステムに接続され、セッションの作成がトリガーされます。セッションは通常、暗号化セッション・トークンで表され、ユーザーのブラウザにセッション・クッキーとして設定されます。Oracle Identity FederationによりWAMシステム内でこのセッションがトリガーされるプロセスは、WAMベンダーの仕様により異なります（「認証エンジン」を参照）。ただし、高水準の場合、着信アサーションから取得した属性をOracle Identity FederationがAPI経由でWAMシステムに提供するプロセスが含まれます。WAMシステムではこのAPIを使用して、IDがそのローカルIDストアに一意にマッピングされます。
マッピングが成功すると、WAMによりセッション・トークン（SAMLアサーション）とともに成功したレスポンスが戻されます。これにより、（ポータルの初期シングル・サインオンで生成された）初期ユーザー・クッキーで起動されたフェデレーション・エンジンによりBeta Corp.に表示できるSAMLアサーションが構築されます。次にBeta Corp.はSAMLアサーションを受信し、そのローカル認証システムにマッピングします。
Oracle Identity Federation処理フローの詳細は、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。
IDプロバイダとサービス・プロバイダは、SAMLやLiberty ID-FFなどのフェデレーション・プロトコルで定義されているプロファイルやサービスを使用してアサーションを交換します。アサーション機能には、次の機能があります。
保護接続の確立
その接続を経由した認証データの運搬
他のSAMLドメインからのアサーションの受信と解釈
プロファイルは、IdPとSPの間でアサーションを転送するために必要な交換の種類を定義します。この項では、Oracle Identity Federationで利用できるアサーション・プロファイルを詳しく見ていきます。
SAMLブラウザPOSTプロファイルは、アーティファクトを使用せずに、アイデンティティ・プロバイダからサービス・プロバイダへアサーション全体を送信します。Oracle Identity FederationはHTMLフォームの非表示変数としてユーザーのブラウザにアサーションを送信し、ブラウザが宛先サイトにアサーションをポストします。
SAML 2.0では、実世界の通信プロトコルの下でのSAMLプロトコル・メッセージの埋込みと転送のためのフレームワークをHTTP POSTバインディングが提供します。
一部のブラウザで、取り扱えるURL文字の数に制限があることがあります。SAMLブラウザ・アーティファクト・プロファイルは、アサーション全体を送信せず、アーティファクトと呼ばれるアサーションへの簡易参照を使用してデータを伝達することによって、これに対処します。アーティファクトの受信者は、アーティファクト解決プロトコルを使用して、アーティファクトにより参照されたアサーション全体を入手します。
SAML 2.0では、実世界の通信プロトコルの下でのアーティファクトの埋込みと転送のためのフレームワークをHTTP Artifactバインディングが提供します。
バインディングとは、抽象的なメッセージ交換から、実世界のメッセージングや通信プロトコルへのマッピングです。たとえば、SAML SOAPバインディングは、SAMLプロトコル・メッセージがSOAPメッセージ内でどのように通信されるかを定義しています。
ブラウザHTTPリダイレクト・プロファイルは、リクエストされたリソースが異なるURLの下にあることをリクエスト元に示します。
SAML 2.0では、HTTPリダイレクト・バインディングは、URL問合せ文字列パラメータのデータを、HTTPリダイレクト・レスポンスを使用して相互に送信しています。送信できるデータ量は、ブラウザにより許可される最長のURLによって制限されるため、これは通常アサーション全体でなく、より短いメッセージで使用されます。
名前識別子プロファイルは、いずれかのプロバイダが、共通するユーザーのいずれかに割り当てられている名前識別子を更新しようとしたときに、プロバイダが相互に通信する方法を定義します。このプロファイルにより、サービス・プロバイダやアイデンティティ・プロバイダがプリンシパルの名前識別子を指定できます。ピア・プロバイダは、プリンシパルについて他のプロバイダと通信する場合は、この名前識別子を使用する必要があります。
Oracle Identity Federationは、次のSOAP/HTTPおよびHTTPリダイレクト名前識別子プロファイルをサポートしています。
IdPが開始するLiberty ID-FF 1.1の名前識別子登録プロファイル
SPが開始するLiberty ID-FF 1.1の名前識別子登録プロファイル
IdPが開始するLiberty ID-FF 1.2の名前識別子登録プロファイル
SPが開始するLiberty ID-FF 1.2の名前識別子登録プロファイル
IdPが開始するSAML 2.0の名前識別子更新用のNameID管理プロファイル
SPが開始するSAML 2.0の名前識別子更新用のNameID管理プロファイル
SAML 2.0には、プリンシパルの属性を取得するための属性問合せ/レスポンス・プロトコルがあります。SAML属性共有プロファイルは、サブジェクトがX.509証明書を使用して認証されている場合、このプロトコルをSOAPバインディングとともに使用して、属性取得を可能にします。
このプロトコルがどのように使用されているかを見るには、サービス・プロバイダが保守しているWebリソースにアクセスする必要があるプリンシパルを検討します。認証は、ユーザーのフェデレーテッド資格証明を、信頼されているX.509v3証明書の形で、関連付けられている秘密鍵の所有証明とともに提示することによって行われます。この方法の一般的な例の1つは、ユーザーのブラウザとWebサーバーの間で使用される、SSL（Secure Sockets Layer）プロトコルのクライアント証明書認証機能です。
サービス・プロバイダは、一部の制限リソースの認可決定に際して、プリンシパルについての追加情報を必要とすることがあります。その情報を入手するには、SPはプリンシパルのX.509v3証明書のSubjectDNを使用して、必要な属性をアイデンティティ・プロバイダに問い合せます。IdPがこれらの属性値を返すと、SPは、その追加データに基づいて認可決定をくだすことが可能になります。プロファイルは、このようにして、不正アクセスを阻止する、強化されたリソース保護を提供します。
WS-Federationは、セキュリティ・ドメインやプロトコルを横断するID、認証および認可の統合をサポートしています。フェデレーション・サービスのクライアントに、HTTPプロトコルをサポートするWebブラウザなどのパッシブ・リクエスタが含まれている場合、WS-Federationパッシブ・リクエスタ・プロファイルがその仕様の使用方法を定義します。
ユーザーはフェデレーションを終了させることができます。そうするには、通常、アイデンティティ・プロバイダまたはサービス・プロバイダのWebサイト上のリンクを使用します。IdPで開始されている場合、このアクションによりSPは、それ以降IdPがSPにユーザーのID情報を提供しないことを通知されます。SPで開始されている場合、このアクションによりIdPは、それ以降IdPがSPにユーザーのID情報を提供しないようにユーザーが要求していることを通知されます。
|
注意: フェデレーションの終了は、フェデレーション解除とも呼ばれます。 |
フェデレーション終了プロファイルは、アイデンティティ・プロバイダやサービス・プロバイダがフェデレーション終了について通知される方法を指定します。
Oracle Identity Federationは、次のフェデレーション終了プロファイルをサポートしています。
IdPが開始するLiberty ID-FF 1.1のフェデレーション終了通知プロファイル
SPが開始するLiberty ID-FF 1.1のフェデレーション終了通知プロファイル
IdPが開始するLiberty ID-FF 1.2のフェデレーション終了通知プロファイル
SPが開始するLiberty ID-FF 1.2のフェデレーション終了通知プロファイル
IdPが開始するSAML 2.0の名前識別子削除用のNameID管理プロファイル
SPが開始するSAML 2.0の名前識別子削除用のNameID管理プロファイル
名前のとおり、このプロファイルはグローバル・ログアウトのサポートを提供します。アイデンティティ・プロバイダは、IdPが提供するアサーションに基づいて、任意のユーザーがログインしているすべてのサービス・プロバイダのリストを保守しています。ユーザーがログアウトしようとすると、IdPは各SPに対してログアウト・リクエストを送信して、そのIdPに関してグローバル・ログアウトを実行します。
ログアウト処理の手順は次のとおりです。
ユーザーまたはピア・プロバイダがログアウト・リクエストを開始します。
Oracle Identity FederationのIdPが、ユーザーがログインしているサービス・プロバイダやアイデンティティ・プロバイダにログアウト・リクエストを送信します。送信するメッセージの種類はシングル・サインオンのタイプにより異なります。たとえば、シングル・サインオンがLiberty 1.2に基づいている場合、Oracle Identity FederationはLiberty 1.2のLogoutRequestを送信します。
Oracle Identity Federationは、メッセージが送信されたプロバイダからログアウト・レスポンスを受け取ります。
Oracle Identity Federationが次のログアウト・リクエスト（手順2）を送信します。
ユーザーがすべてのプロバイダからログアウトすると、Oracle Identity Federationがユーザーをサーバーからログアウトさせます。
WS-Federationログアウトの場合、Oracle Identity Federationはユーザーに対して正常ログアウトのページを表示します。Liberty 1.xおよびSAML 2.0のログアウト・プロファイルは、元のログアウト・リクエストを送信したピア・プロバイダにユーザーを送り返します。
Oracle Identity Federationは次のプロトコルのSOAP/HTTPおよびHTTPリダイレクト・グローバル・ログアウト・プロファイルをサポートしています。
IdPが開始するLiberty ID-FF 1.1のシングル・ログアウト・プロファイル
SPが開始するLiberty ID-FF 1.1のシングル・ログアウト・プロファイル
IdPが開始するLiberty ID-FF 1.2のシングル・ログアウト・プロファイル
SPが開始するLiberty ID-FF 1.2のシングル・ログアウト・プロファイル
IdPが開始するSAML 2.0のシングル・ログアウト・プロファイル
SPが開始するSAML 2.0のシングル・ログアウト・プロファイル
WS-Federationのパッシブ・リクエスタ・ログアウト・プロファイル
Liberty 1.2/SAML 2.0のアフィリエーションは、論理グループに参加しているサービス・プロバイダで構成されます。
アフィリエーションは具体的なエンティティやサーバーではなく、論理上のプロバイダです。このため、アフィリエーションとして動作できるサーバーはありません。そのかわりにアフィリエーションは、プロトコル・メッセージの交換を実行する際にサービス・プロバイダによって使用される立場です（この場合のアフィリエーションは論理プロバイダとみなされる）。一方、このアフィリエーションのメッセージの送信者/受信者は、具体的なサービス・プロバイダです。このようにして、アフィリエーションに参加しているサービス・プロバイダがアフィリエーションとして動作し、その論理プロバイダについてのすべてのフェデレーション情報にアクセス可能になります。
Oracle Identity Federationでのアフィリエーションの実装の詳細は、「アフィリエーションの構成と使用」を参照してください。
Oracle Identity Federationでは、XML署名キーまたは暗号化キーがPKCS#12ウォレットによって提供されると想定されます。Oracle Identity Federationでは、基礎となる暗号化プロバイダをスワップアウトする構成ノブは提供されません。
この項では、フェデレーテッド・インタラクションにおける通常のメッセージ・フローについて説明します。
図1-1のユースケースを細かく見てみましょう。Maryがmycorp.comで認証済であり、未ログインのtravelclub.comに移動する場合を考えます。travelclub.comはMaryに対して認証を受けることを要求し、travelclub.comのシングル・サインオンをリクエストしているmycorp.comに、SAML 2.0メッセージを付けてMaryをリダイレクトします。そうしないとMaryは自分のローカル・アカウントにアクセスできません。Maryはアイデンティティ・プロバイダにログイン済であるため、mycorp.comはMaryのアカウントとフェデレーションのデータを取得し、travelclub.comに彼女をリダイレクトしなおします。プロバイダ識別子mycorp.comと、リダイレクトで提供されたユーザー識別子xyz123を使用すると、travelclub.comはMaryのフェデレーション・データとローカル・アカウントを一意に取得できます。
Oracle Identity Federationによってサポートされているプラットフォームと製品バージョンの詳細は、次の該当する認定マトリックスを参照してください。
https://metalink.oracle.comのMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Management」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」をクリックします。
「General Oracle Identity Management Certification Information」で、「Oracle Identity Federation Certification」をクリックします。
