| Oracle® Fusion Middleware Oracle Identity Federation管理者ガイド 11g リリース1(11.1.1) B66693-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サイトおよびアプリケーションです。フェデレーテッド・サイトはアイデンティティ・プロバイダ(一部の仕様ではソース・ドメイン)か、サービス・プロバイダ(宛先ドメイン)、またはその両方です。
アイデンティティ・プロバイダ
アイデンティティ・プロバイダ(IdP)は、一連のフェデレーション内でIDの集合を管理、認証および宣言します。
これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にプリンシパルとサービス・プロバイダがあります。
アイデンティティ・プロバイダは、SAML 1.xプロトコルではソース・ドメインとも呼ばれます。この観点では、ソース・ドメインのユーザーが、アクセス先ドメインにあるサイト上のリソースにアクセスするための許可をリクエストする、リクエストの発生箇所がアイデンティティ・プロバイダです。
サービス・プロバイダ
サービス・プロバイダ(SP)はプリンシパルにサービスを提供し、プリンシパルのIDの認証はアイデンティティ・プロバイダに依存します。
サービス・プロバイダは、リライイング・パーティ(SAML)または宛先ドメインとも呼ばれます。ドメインの観点からすると、サービス・プロバイダには、ソース・ドメインのユーザーがアクセスするリソースが含まれます。
サービス・プロバイダはユーザーにWebベースのサービスを提供する組織です。この広範なカテゴリには、たとえば次のような、実質的にすべてのWeb上の組織が含まれます。
インターネット・ポータル
小売業者
金融機関
行政機関
NPO(非営利組織)
娯楽産業
運送業者
これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にアイデンティティ・プロバイダとプリンシパルがあります。
|
注意: 1つの組織が、一般的あるいは特定の相互作用のコンテキスト内で、アイデンティティ・プロバイダとサービス・プロバイダの両方であることがあります。 |
OpenIDプロトコルによってユーザー認証を行うプロバイダ。略称はOPです。SAMLのIDプロバイダに類似しています。
OpenIDのリライイング・パーティ。略称はRPです。SAMLのサービス・プロバイダに類似しています。
OPとRP間における承諾です。メッセージの署名に使用されるMAC秘密鍵を定義します。
OpenIDのOPとRPがサービス・サポートとエンドポイントの場所を特定して検証する際に使用するオンライン手段です。OpenIDの検出は、XRDSメタデータ公開プロトコルによって行われます。OPのXRDSメタデータには、サポートされるサービス(たとえば、属性交換、PAPEなど)やサインオンURLが記述されています。RPのXRDSには、戻りURLが記述されています。
フェデレーション
フェデレーションとは、アイデンティティ・プロバイダとサービス・プロバイダ間の信頼関係です。プリンシパルはこれを利用して、これらのプロバイダとビジネス・トランザクションを実行する際に、シングル・フェデレーテッド・アイデンティティおよびシングル・サインオンを使用できます。
組織は、フェデレーション・テクノロジおよび組織間の信頼関係を定義する運用協定に基づいて、フェデレーションを作成します。
たとえば、企業フェデレーションを作成することにより、アイデンティティ・プロバイダが企業を横断して従業員ネットワークIDを活用できるようになります。別の例として消費者バンキングがあります。この場合、ユーザーの銀行が他の各種サービス・プロバイダとビジネス関係(つまり、フェデレーション)を確立しており、ユーザーはそれらのプロバイダに対して銀行ベースのネットワークIDを使用できます。
フェデレーション・ソリューション
フェデレーションで最も重要な点は、個々のセキュリティ・ドメイン間でIDデータを交換することです。フェデレーションの実現方法を考える場合、信頼レベル、達成目標、そして各種フェデレーションに伴う管理作業量について必然的に考えなければなりません。
|
注意: 次のリストは、ビジネス・レベルでのフェデレーション、およびフェデレーションの計画時に関連すると思われるソリューションのタイプに対する考え方を定義しています。これらの考え方は、必ずしも特定の技術ソリューションに該当するものではありません。 |
一時フェデレーション
一時フェデレーションでは、追加のIDエンティティ・データの送信や使用を必要とせずに、ドメイン間でユーザー・セッションの転送が行われます。受信者は、送信者を信頼してプリンシパルの認証/認可を行います。
一時フェデレーションは、a)各プロバイダが暗黙的に相互に信頼し合っている場合、b)各プロバイダが共通の標準(SAML 2.0など)に合意している場合に適しています。
一時フェデレーションは、実装および管理が比較的しやすい方法です。ユーザーはリンクをクリックするだけで、認証ユーザーとしてサービス・プロバイダにアクセスできるので、ユーザー操作は透過的になります。
一時フェデレーションの一般的な応用例として、国民に関する情報を独自のドメインで維持、認証するために証明書などの認証方法を使用している政府機関では、他の機関にユーザーをフェデレートすることにより、それらの機関のサービスへのシングル・サインオンが可能になります。
一時フェデレーションの明らかな限界は、送信ドメインの信頼性に起因して、受信ドメインが追加のユーザー検証を実行できないことです。
アカウント・マッピング
アカウント・マッピングは、確立済の非常に高度な信頼がセキュリティ・ドメインにないと考えられる場合や、フェデレーテッド・ユーザーがアクセスできる情報を制限する場合に適しています。
アカウント・マッピングでは、IDを両方のドメインでメンテナンスする必要があるため、追加の管理作業が必要になります。ドメインは、ユーザーIDを含むメッセージ形式でユーザー情報(アサーション)を交換します。受信者は、このユーザーIDをローカル・ストア内にある既知のIDにマップできます。アカウント・マッピングの利点も同様に、フェデレーションを行うドメイン間で高度な信頼を必要としないことです。
アカウント・リンク
アカウント・リンクはアカウント・マッピングの拡張です。ただし、ローカルIDの詳細を各ドメインで維持するかわりに、最初にフェデレーションが行われるときにユーザーから取得する情報を受信パートナが使用したり拡張したりすることができ、さらに将来使用するために保管することができます。
アカウント作成のタスクはユーザーに委任されます。そのため、アカウント・リンクではアカウント・マッピングで必要とされる管理作業が軽減されます。
アカウント・リンクおよびアカウント・マッピングの一般的な応用例は旅行業界で見られます。旅行関連企業が関連するパートナとフェデレートして商機を共有することにより、ユーザーは旅行に関するあらゆること(航空券の予約、車のレンタル、ホテルの予約など)を計画できます。また、最小限の認証で必要なサービスにアクセスすることも可能になります。
属性フェデレーション
属性フェデレーションは、パートナ間でアクセス制御ポリシーに基づいてリソースへのアクセス権を付与する場合、またはその必要がある場合に有効です。
各ドメインではユーザーIDを維持するかわりに、グループ、ロールなどの情報を維持します。フェデレーション時には、受信パートナがユーザーの属性を調べてその属性をこの認可情報にマップし、許可するアクセスのタイプを決定します。したがって、パートナ間で共通のマッピング・ルールに合意している必要があります。
実際のIDデータではなく、ルールのみを維持すれば済むため、(アカウント・マッピングやアカウント・リンクに比べて)管理がより簡単です。
このタイプのフェデレーションの例として、企業間(B2B)環境があります。この環境ではパートナ間でID情報が交換される一方で、リソースへのアクセスをリクエストするユーザーに対してアクセス権の付与や認可の決定を行うための個々のルールは各パートナが維持します。
組合せフェデレーション
組合せフェデレーションでは、その名前が示すように、送信ドメインは識別情報(名前、アドレス、ロールなど)をフェデレーション・リクエストで必要なだけ提供できます。
このフェデレーション方式の長所は、各ドメインでリクエストを形成する際に柔軟性がもたらされる点です。同時に、組合せフェデレーションの短所は、高度な管理が求められる点と、パートナ間で強固な信頼関係と連携が必要になる点です。
アイデンティティ・フェデレーション
アイデンティティ・フェデレーションとは、フェデレーションを作成した1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダで、プリンシパルが保持している場合がある、2つ以上のアカウントの結びつきです。
ユーザーが複数のビジネスに対して持っている、相互に独立している個別のアカウント(ローカルID)をフェデレートすると、2つのエンティティ間にリレーションシップ(任意の数のサービス・プロバイダとアイデンティティ・プロバイダで構成される関係付け)が作成されます。
技術的な観点からすると、プリンシパルの識別に使用する一連のIDや属性についてプロバイダ間で合意がある場合、そのプリンシパルIDはプロバイダ間でフェデレーテッド関係にあると言われています。
シングル・サインオン
シングル・サインオンの場合、ユーザーはアイデンティティ・プロバイダとサービス・プロバイダのフェデレーテッド・グループのメンバーに対して1度サインオンすれば、そのグループ内の各種のリソースをそれ以降使用でき、再び署名する必要がありません。
SAMLプロトコルまたはWS-Federationプロトコルを使用して、プリンシパル間でシングル・サインオン処理を実行するには、SPおよびIdPで次のことが必要です。
SPとIdPの間にフェデレーションが存在する(信頼できるビジネス・リレーションシップがある)こと。
プリンシパルが、SPとIdPの両方のローカルID(またはロール)を持っており、その2つのIDがフェデレーテッド関係にあること。
Oracle Universal Federation Framework
Oracle Universal Federation Frameworkには、業界標準のフェデレーション機能に対してすぐに使用できるサポートが用意されています。また、次のような拡張機能も数多く用意されています。
認証およびSP統合処理の前後におけるカスタム・アクション(この機能は、前処理プラグインおよび後処理プラグインとも呼ばれます)
カスタム認証エンジン
カスタムSP統合エンジン
セキュリティ・ドメインを横断する相互運用性、保証および信頼上の問題に対処するフェデレーテッド・アーキテクチャの構築では、ID管理統合で有用な構築ブロックとして次のプロトコルが注目を集めています。
SAML 1.0および1.1。セキュリティ・データ交換(アサーション)で使用するフォーマットや、アサーションの使用手段を提供するプロファイルを定義します。
SAML 2.0。SAML 1.1の拡張で、追加のプロファイルを提供します。
WS-Federation。参加しているWebサービスの間でのID、ユーザー属性、認証の信頼を仲介することによって、異なるセキュリティ・レルムのフェデレーションを可能にします。
SAMLとWS-Federationプロトコルは、セキュリティ・ドメイン相互の間での情報の交換、プロバイダ間の調整(「ハンドシェイク」)、およびフェデレーテッド・サインオンとグローバル・ログアウトなどの識別イベントの管理のためのフレームワークを提供します。これらの標準は、ドメインを超えてセキュリティ情報を通信するためのXMLベースのフレームワークを提供します。これには次の利点があります。
ドメインの疎結合。ディレクトリ間でユーザー・データを同期したりレプリケートする必要がありません。
プラットフォームやテクノロジに中立な手法。クロスドメイン統合の障害を除去します。
アプリケーション・サーバー、Webサービス管理、およびセキュリティ製品、セキュリティ・ベンダーにより広くサポートされ、採用する組織は増え続けています。
この項では、基礎的なSAMLの概念とフェデレーション・プロトコルについて詳しく説明します。内容は次のとおりです。
Oracle Identity Federationでサポートされているプロファイルの詳細は、第1.2.4項「フェデレーション・プロトコル・プロファイル」を参照してください。
|
注意: Liberty 1.xのサポートは非推奨です。 |
Security Assertions Markup Language(SAML): オンライン・ビジネス・パートナの間でのセキュリティ情報を交換するための手段として、OASISによって開発された標準です。
二者間の一般的なSAMLメッセージ交換では、片方がリライイング・パーティ、もう一方がアサーティング・パーティとなります。
アサーティング・パーティは、特定のサブジェクトについて、そのサブジェクトが認証されているかどうか、あるアクションを実行する権限を認可されているかどうかなどの情報を宣言します。リライイング・パーティは、アサーティング・パーティが提供した情報を使用して、サブジェクトに関するセキュリティ関連の決定を行います。たとえば、そのサブジェクトが特定のリソースに対して許可されるアクセスの種類などを決定します。
SAMLアサーション
SAMLは、特定のドメイン内でのプリンシパルのアクセス権限を決定する際に使用できる追加のID情報にプリンシパルを関連付けます。SAMLドキュメントはすべて、こうした関連付けを含むアサーション要素を持っています。
SAMLは、次の3種類のアサーションを定義します。これらはサブジェクトに関する1つ以上の事実の宣言です。
認証アサーション。ユーザーの識別情報が、特定の時刻において特定の方法によって証明されていることを明示します。
属性アサーション。従業員番号やアカウント番号など、ユーザーに関する固有の詳細情報が含まれます。
認可アサーション。ユーザーがアクセスできるリソースと、アクセス可能な条件を明示します。
アサーションはすでに発生したイベントについて生成される、コード化された文です。
|
注意: |
例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にフィードバックと訂正を反映させたものです。特に、SAML 1.1にはXMLデジタル署名の変更が取り入れられており、相互運用性が大幅に向上しています。このようにXMLデジタル署名が変更されたことによって、署名検証時の問題が大幅に軽減されるため、可能なかぎりSAML 1.0のかわりにSAML 1.1プロトコルを使用することをお薦めします。
例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>
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、OpenID、SAMLプロトコルなど、複数のフェデレーテッドIDプロトコルをサポートしています。これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。
Oracle Identity Federationの主要な機能には、次のようなものがあります。
アイデンティティ・プロバイダとサービス・プロバイダの両方を含む環境で、クロスサイトのアクセスと認証を実装可能
外部サイトの構成、有効化および無効化が可能
シングル・サインオンを使用して宛先サイトのアプリケーションにアクセス可能
次に示す主要なフェデレーション・プロトコルのサポート
SAML 1.x属性リクエスタと属性レスポンダ、認証問合せレスポンダ、アサーションIDレスポンダの機能を含むSAML 1.x
SAML 2.0属性リクエスタと属性レスポンダ、認証問合せレスポンダ、アサーションIDレスポンダの機能を含むSAML 2.0
WS-Federationのパッシブ・リクエスタ
Liberty ID-FF 1.x
OpenID 2.0
Oracle Access ManagerおよびOracle Single Sign-Onとの統合
プロトコルを超えたシングル・サインオンおよびサインアウトのサポート
アフィリエーションのサポートにより、サービス・プロバイダがフェデレーション情報を共有できるため、フェデレーションの数を削減可能
Oracle Internet Directoryとの統合、および次のサポート
Oracle Access ManagerやLDAPなどの広範な認証エンジン
Microsoft Active DirectoryやSun Java System Directory ServerなどのLDAPストアを含むユーザー・データ・リポジトリ
リレーショナル・データベース
X.509証明書検証のサポート
図1-4は、Oracle Identity Federationのアーキテクチャと、他のフェデレーション・コンポーネントとOIFの関係を示しています。ここで、Oracle Identity Federation(OIFと表記)は、他のアイデンティティ・プロバイダとサービス・プロバイダ(追加のOracle Identity Federationインスタンスまたはサード・パーティのプロバイダ)とのフェデレーションを作成しています。
|
注意: 1つのOracle Identity Federationインスタンスは、1つのIdPおよび1つのSPとして動作することができます。図に示されているアイデンティティ・プロバイダと2つのサービス・プロバイダは、フェデレーテッド・ピア・プロバイダです。 |
Oracle Identity Federationには、自己完結した軽量の認証サービスが含まれます。
Oracle Identity Federationは、次のような広範な認証メカニズムおよびユーザー・データ・リポジトリと通信できます。
Oracle Identity Management
Oracle Identity Federation認証サービスは、Oracle Single Sign-OnまたはOracle Access Managerにより保護された次のようなリソースへのシングル・サインオン・アクセスを可能にするように構成できます。
Oracle Collaboration Suite
Oracle E-Business Suite
PeopleSoftモジュール
その他
サード・パーティのアクセス管理ソリューションと併用するためにOracle Single Sign-Onがデプロイされていれば、この構成では、Oracle Single Sign-On(およびOracle Internet Directoryユーザー・リポジトリ)またはOracle Access Manager(および各種のリポジトリ)の他に、サード・パーティのアクセス管理ソリューションも活用できます。
|
注意: Oracle Identity FederationとOracle Single Sign-Onの両方がリソースを保護している環境では、いずれかのコンポーネントを、ユーザー・リクエストが保護リソースにアクセスした場合に認証メカニズムとして動作するように構成できます。たとえば、Oracle Identity Federationは、認証リクエストをOracle Single Sign-Onに転送できます。また、Oracle Single Sign-Onは、適切なアイデンティティ・プロバイダを見つけるようにOracle Identity Federationにリクエストできます。詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドを参照してください。 同様に、Oracle Identity FederationとOracle Access Managerの両方を含む環境にも類似の機能があります。 |
データ・ストア
Oracle Identity Federationは、次のものにアクセスするように構成できます。
LDAPディレクトリ
RDBMSデータベース
Oracle Identity Federation機能を詳しく見る前に、フェデレーテッド環境でユーザー・アクセスを管理する際の大まかな処理フローを考察しておくと参考になります。
通常、ユーザーは、会社のポータルを介して複数のドメインのアプリケーションにアクセスします。たとえば、Alpha Corporationが、Alphaのユーザー・ログイン、ページのパーソナライズなどを管理するポータル・サーバーを備えているとします。そのポータル・サーバーは、アプリケーション・サーバー内で動作する自社製ロジックで構成されている場合や、市販の製品の場合があります。パートナ会社であるBeta Corporationは、MyBeta.comというタイプのポータルを使用して、その技術的なデータベース・アプリケーションを提供できます。この場合、それぞれが自社ポータル・サーバーを運用していることになります。
プロセス・フローは次のようになります。
ユーザーは、Oracle Access Manager、Oracle Single Sign-Onやその他の製品などのWebアクセス管理(WAM)システムによりアクセスが管理されているAlphaポータルにログインします。
ユーザーは、実際にはBeta Corporationがホストしているリソースをクリックしてリクエストを開始します。
アイデンティティ・プロバイダ(IdP)として動作しているAlphaポータルのOracle Identity Federationインスタンスが、ユーザー情報をWAMシステムに送信します。
WAMシステムは、ローカル・アイデンティティ・ストアのアイデンティティにユーザーをマッピングした後、セッションを作成します。
WAMシステムにより、成功したレスポンスとセッション・トークンがAlphaポータルのOracle Identity Federation IdPサーバーに戻されます。
前述の情報を使用して、AlphaポータルのIdPはSAMLアイデンティティ・アサーションを作成し、プライベート署名キーを使用して署名します。このレスポンスは、Beta Corporationのサービス・プロバイダ(SP)として動作するOracle Identity Federationインスタンスに送信されます。
Beta CorporationのSPとして動作するOracle Identity Federationサーバーは、署名キーに関連付けられたIdPのパブリック証明書を使用して署名付きレスポンスを検証します。
Beta CorporationのOracle Identity Federationサービス・プロバイダはアサーションを抽出し、ユーザー・セッションをローカル認証システムにマッピングした後、アサーションに対するユーザー・セッションを作成します。
Oracle Identity Federationサービス・プロバイダは、ユーザーのブラウザにリクエストされたリソースへのリダイレクトを送信します。
ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。
Oracle Identity Federation処理フローの詳細は、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。
アイデンティティ・プロバイダとサービス・プロバイダは、SAMLやWS-Federation、OpenIDなどのフェデレーション・プロトコルで定義されているプロファイルやサービスを使用してアサーションを交換します。アサーション機能には、次の機能があります。
保護接続の確立
その接続を経由した認証データの運搬
他のドメインからのアサーションの受信と解釈
プロファイルは、IdPとSPの間でアサーションを転送するために必要な交換の種類を定義します。この項では、Oracle Identity Federationで利用できるアサーション・プロファイルを詳しく見ていきます。
|
注意: Liberty 1.xのサポートは非推奨です。 |
SAMLブラウザPOSTプロファイルは、アーティファクトを使用せずに、アイデンティティ・プロバイダからサービス・プロバイダへアサーション全体を送信します。Oracle Identity FederationはHTMLフォームの非表示変数としてユーザーのブラウザにアサーションを送信し、ブラウザが宛先サイトにアサーションをポストします。
SAMLおよびWS-Federationでは、実際の通信プロトコルに従ってSAMLプロトコル・メッセージの埋込みと転送を行うためのフレームワークとしてHTTP POSTバインディングを提供しています。
一部のブラウザで、取り扱えるURL文字の数に制限があることがあります。SAMLブラウザ・アーティファクト・プロファイルは、アサーション全体を送信せず、アーティファクトと呼ばれるアサーションへの簡易参照を使用してデータを伝達することによって、これに対処します。アーティファクトの受信者は、アーティファクト解決プロトコルを使用して、アーティファクトにより参照されたアサーション全体を入手します。
SAMLでは、実際の通信プロトコルに従ってアーティファクトの埋込みと転送を行うためのフレームワークとしてHTTP Artifactバインディングを提供しています。
バインディングとは、抽象的なメッセージ交換から、実世界のメッセージングや通信プロトコルへのマッピングです。たとえば、SAML SOAPバインディングは、SAMLプロトコル・メッセージがSOAPメッセージ内でどのように通信されるかを定義しています。
ブラウザHTTPリダイレクト・プロファイルは、リクエストされたリソースが異なるURLの下にあることをリクエスト元に示します。
SAMLおよびWS-Federationでは、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には、プリンシパルの属性を取得するための属性問合せ/レスポンス・プロトコルがあります。
このプロトコルがどのように使用されているかを見るには、サービス・プロバイダがメンテナンスしている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が、ユーザーがログインしているサービス・プロバイダやアイデンティティ・プロバイダにログアウト・リクエストを送信します。送信するメッセージの種類はシングル・サインオンのタイプにより異なります。
Oracle Identity Federationは、メッセージが送信されたプロバイダからログアウト・レスポンスを受け取ります。
Oracle Identity Federationが次のログアウト・リクエスト(手順1)を送信します。
ユーザーがすべてのプロバイダからログアウトすると、Oracle Identity Federationがユーザーをサーバーからログアウトさせます。
WS-Federationログアウトの場合、Oracle Identity Federationはユーザーに対して正常ログアウトのページを表示します。SAML 2.0のログアウト・プロファイルは、元のログアウト・リクエストを送信したピア・プロバイダにユーザーを送り返します。
Oracle Identity Federationは次のプロトコルのSOAP/HTTPおよびHTTPリダイレクト・グローバル・ログアウト・プロファイルをサポートしています。
IdPが開始するSAML 2.0のシングル・ログアウト・プロファイル
SPが開始するSAML 2.0のシングル・ログアウト・プロファイル
WS-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のシングル・ログアウト・プロファイル
Oracle Identity Federationは、次のOpenID拡張仕様とプロファイル仕様をサポートしています。
Attribute Exchange(AX)
AXはOpenID 2.0の拡張で、ユーザー属性をリクエストしたり、返したりすることができます。
Provider Authentication Policy Extension (PAPE)
PAPEはOpenID 2.0の拡張で、保証レベルなど、特定の認証タイプや強度をRPがリクエストできるようにします。
米国政府Federal Identity, Credentialing and Access Management (ICAM)プロファイル
このプロファイルは、OpenID 2.0の導入に対して米国政府が示したポリシー要件とセキュリティ要件をサポートしています。次のものが含まれます。
非個人識別情報
Private Personal Identifier
OpenIDのGSAプロファイル
NIST認証レベル
詳細は、第2.2項「プロファイルとバインディング」のOpenIDに関するトピックを参照してください。
SAML 2.0またはLiberty 1.2のアフィリエーションは、論理グループに参加しているサービス・プロバイダで構成されます。
|
注意: Liberty 1.xのサポートは非推奨です。 |
アフィリエーションは具体的なエンティティやサーバーではなく、論理上のプロバイダです。このため、アフィリエーションとして動作できるサーバーはありません。そのかわり、プロトコル・メッセージの交換を実行する際にサービス・プロバイダによってアフィリエーションIDが使用されます。この場合、メッセージはアフィリエーションの論理エンティティから送信されるように見えますが、メッセージの実際の送信者は具体的なサービス・プロバイダです。このようにして、アフィリエーションはアフィリエーション内のすべてのサービス・プロバイダの別名として機能し、それぞれのサービス・プロバイダはアフィリエーション・エンティティに関連付いたフェデレーション情報を使用できます。
Oracle Identity Federationは、署名処理や暗号化処理を実行する必要がある場合には、Java Cryptographic Extensionを使用します。
署名鍵および暗号鍵は、PKCS#12ウォレットまたはJavaキーストアとしてOracle Identity Federationに提供する必要があります。
|
注意: 署名鍵と暗号化鍵を提供する、特定のJCE Providerを使用するように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にアクセスして、My Oracle Supportにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Management」オプションを選択し、「Submit」をクリックします。
「General Oracle Identity Management Certification Information」で、「Oracle Identity Federation Certification」をクリックします。
