Comments
Description
Transcript
Airline.inc - Liberty Alliance
1 2 3 4 5 6 7 8 9 Liberty アーキテクチャ概要 10 バージョン 1.1 11 2003 年 1 月 15 日 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 文書名：liberty-architecture-overview-v1.1 32 告知 33 34 Copyright 2002, 2003 ActivCard; American Express Travel Related Services; America Online, 35 Inc.; Bank of America; Bell Canada; Catavault; Cingular Wireless; Cisco Systems, Inc.; Citigroup; 36 Communicator, Inc.; Consignia; Cyberun Corporation; Deloitte & Touche LLP; Earthlink, Inc.; 37 Electronic Data Systems, Inc.; Entrust, Inc.; Ericsson; Fidelity Investments; France Telecom; 38 Gemplus; General Motors; Hewlett-Packard Company; i2 Technologies, Inc.; Intuit Inc.; MasterCard 39 International; NEC Corporation; Netegrity; NeuStar; Nextel Communications; Nippon Telegraph 40 and Telephone Company; Nokia Corporation; Novell, Inc.; NTT DoCoMo, Inc.; OneName 41 Corporation; Openwave Systems Inc.; PricewaterhouseCoopers LLP; Register.com; RSA Security 42 Inc; Sabre Holdings Corporation; SAP AG; SchlumbergerSema; SK Telecom; Sony Corporation; 43 Sun Microsystems, Inc.; United Airlines; VeriSign, Inc.; Visa International; Vodafone Group Plc; 44 Wave Systems;. All rights reserved. 45 46 本書は、Liberty Alliance の参加企業によって作成されました。本書は、この仕様の実装以外 47 の目的で使用することはできません。この仕様を他で引用することは禁止されています。 48 それ以外の用途でこの文書の複製を希望する場合は、Liberty Alliance まで使用許可について 49 お問い合わせください。 50 51 この仕様の特定要素の実装には、特許権など、第三者が所有する知的所有権の使用許諾権 52 が必要な場合があります。それ以外において本仕様の策定に協力した企業は、かかる第三 53 者の知的所有権の有無を確認することまたは確認しなかったことについて一切責任を負い 54 ません。この仕様は、「無保証で」提供されるものであり、Liberty Alliance の参加企業は、 55 明示的または黙示的を問わず、商品性、第三者の知的所有権を侵害しないこと、特定目的 56 に対する適合性についていかなる保証もいたしません。この仕様の実装にあたっては、 57 Liberty Alliance Project の Web サイト (http://www.projectliberty.org/) にアクセスして、Liberty 58 Alliance 理事会がこれまでに受け取っている「Necessary Claims Disclosure Notices(必要な特許 59 請求範囲の開示に関する告知)」の情報をご確認ください。 60 61 （日本語訳はしがき） 62 この文書の日本語訳においては、原文（英語）で表現されている内容について RFC 文献の 63 日本語訳等を参考にできるだけ正確を期すよう務めましたが、あくまで Liberty 仕様の理解 64 の参考とするにとどめ、Liberty 仕様の実装を検討され、知的所有権を確認する場合、必ず 65 原文や参考文献を参照いただくようお願いいたします。 66 翻訳にあたった Liberty Alliance 参加企業は原文と同様、本文書に係る翻訳の正確性、翻訳 67 された仕様の商品性、第三者の知的所有権を侵害しないこと、特定目的に対する適合性に 68 ついていかなる保証もいたしません。 69 70 Liberty Alliance Project 71 Licensing Administrator 72 c/o IEEE-ISTO 73 445 Hoes Lane 74 Piscataway, NJ 08855-1331, USA 75 [email protected] 76 77 作成者 78 79 Jeff Hodges, Sun Microsystems, Inc. 80 Tom Wason, IEEE - ISTO 81 82 協力企業 83 84 仕様書の作成に協力した Liberty Alliance Project 参加企業は以下のとおりです。 ActivCard MasterCard International American Express Travel Related Services Nextel Communications America Online, Inc. Nippon Telegraph and Telephone Company Bank of America Nokia Corporation Bell Canada Novell, Inc. Catavault NTT DoCoMo, Inc. Cingular Wireless OneName Corporation Cisco Systems, Inc. Openwave Systems Inc. Citigroup PricewaterhouseCoopers LLP Cyberun Corporation Register.com Deloitte & Touche LLP RSA Security Inc EarthLink, Inc. Sabre Holdings Corporation Electronic Data Systems, Inc. SAP AG Entrust, Inc. SchlumbergerSema Ericsson Sony Corporation Fidelity Investments Sun Microsystems, Inc. France Telecom United Airlines Gemplus VeriSign, Inc. General Motors Visa International Hewlett-Packard Company Vodafone Group Plc i2 Technologies, Inc. Wave Systems Intuit Inc. 85 改訂履歴 86 版 日付 作成者 変更内容 1.0 2002 年 3 月 14 Jeff Hodges Liberty V1.0 に基づき初版草案を作成。 Jeff Hodges CR 1107: 埋め込みフォームを使用したログイン 日 1.1 2002 年 11 月 5 は、ユーザーのクレデンシャルを SP に開示するこ 日 とが「可能な」だけである。 「HTML フォームより ULR で使用可能なスペース が大きい」と述べている、949 行の論拠 CR 1103 を 倒置。 CR 1100: 「拒否不能のサポート」に言及。 CR 1102: フェーズ 1 でサポートされる図 17 か? CR 1101: 本書の第 1.1 節.の説明を追加。 CR 1104: 図 14 は、1 つだけでなく 2 つの関係を表 している。 CR 1099: 認証前にユーザーの同意を取得。 CR 1177: IDP2IDP 連携内における信用関係の確立 について未定義。 1.1 - 04 2002 年 11 月 Tom Wason 15 日 CR1217: 主体者の認証状態情報に関する注記を第 5.4.2 節に加筆。 CR1218: 共通クッキーに関する注記を第 5.6 節に 加筆。 CR1222: ローカルセッションにおける連携終了に 関する注記を第 5.4.1.2 節に加筆。 CR1226: 第 5.4.1 節の、ユーザーハンドルに関する 注記 2 を変更。 1.1 - 05 2002 年 11 月 25 日 Tom Wason CR1238: 第 5.4.2 節のポリシー/セキュリティに関 する注に、「IdP セッション状態のメンテナンス」 の項を挿入。 CR1247: 第 5.4.1.2 節のポリシー/セキュリティに関 する注に含まれる推奨事項を小文字に変更。 1.1 – 06 2002 年 12 月 Tom Wason 20 日 CR1179: 第 5.7.1.3 節から無関係な[1107]を削除。 CR1270: 第 6 節の参考文献の正規化とフォーマッ ト整形。 87 88 1.1 最 終 2003 年 1 月 15 版 日 John Kemp 不要な参照先を削除。 89 目次 90 92 1 はじめに........................................................................................................... 9 1.1 本書について ........................................................................................... 9 1.2 Liberty Alliance とは .............................................................................. 10 93 1.2.1 Liberty のビジョン ......................................................................................... 10 94 1.2.2 Liberty のミッション ..................................................................................... 10 91 95 1.3 ネットワークアイデンティティとは ..................................................... 11 96 1.3.1 Liberty の目標 ................................................................................................ 11 97 101 2 Liberty Version 1.0 におけるユーザー体験の例 ............................................. 13 2.1 アイデンティティ連携のユーザー体験の例 .......................................... 14 2.2 シングルサインオンのユーザー体験の例 .............................................. 19 3 Liberty の技術要件の概要............................................................................... 21 3.1 全般的な要件 ......................................................................................... 21 102 3.1.1 クライアントデバイス/ユーザーエージェントの相互運用性 ........................ 21 103 3.1.2 オープン性に関する要件 ............................................................................... 22 98 99 100 104 3.2 機能に関する要件.................................................................................. 22 105 3.2.1 アイデンティティ連携................................................................................... 22 106 3.2.2 認証 ............................................................................................................... 23 107 3.2.3 仮名 ............................................................................................................... 23 108 3.2.4 グローバルログアウト................................................................................... 23 109 111 4 Liberty のセキュリティフレームワーク ......................................................... 24 5 Liberty アーキテクチャ .................................................................................. 26 5.1 Web リダイレクトのアーキテクチャコンポーネント ........................... 28 112 5.1.1 HTTP リダイレクトによるリダイレクト ...................................................... 28 113 5.1.2 フォーム POST によるリダイレクト ............................................................ 29 114 5.1.3 クッキー ........................................................................................................ 30 115 5.1.4 Web リダイレクトのまとめ .......................................................................... 31 116 118 5.2 Web サービスのアーキテクチャコンポーネント................................... 32 5.3 メタデータとスキーマのアーキテクチャコンポーネント ..................... 32 5.4 シングルサインオンとアイデンティティ連携 ....................................... 33 119 5.4.1 アイデンティティ連携................................................................................... 33 120 5.4.2 シングルサインオン ...................................................................................... 40 121 5.4.3 シングルサインオンおよび連携プロトコルのプロファイル ......................... 44 122 5.5 IdP イントロダクション ........................................................................ 49 110 117 123 124 125 5.6 シングルログアウト .............................................................................. 52 5.6.1 シングルログアウトのプロファイル ............................................................. 54 5.7 ユーザー体験のシナリオ例 ................................................................... 55 126 5.7.1 シナリオ：いずれにもログインしていない、共通ドメインクッキーなし ... 55 127 5.7.2 シナリオ：いずれにもログインしていない、共通ドメインクッキーあり ... 60 128 5.7.3 シナリオ：ログイン済み、共通ドメインクッキーあり ................................ 60 129 6 参考文献......................................................................................................... 61 130 131 1 はじめに 132 133 インターネットは、企業、コミュニティ、および個人間の通信の主要な手段となっていま 134 す。アイデンティティの概念は、この手段の重要な構成要素です。現在、インターネット 135 上におけるアイデンティティは、事業主、ポータル、さまざまなコミュニティ、ビジネス 136 サービスなどのさまざまなアイデンティティプロバイダ（IdP）で断片化して扱われます。 137 この断片化のせいで、１対１の企業と顧客との関係や使用感がばらばらで抵抗感があるも 138 のとなっています。 139 140 連携ネットワークアイデンティティは、新しい規模の経済と組み合わさることで、この抵 141 抗感を軽減し、新しいビジネス領域とビジネス機会を実現するための鍵となります。この 142 ような真新しい連携された商取引の世界では、ユーザーのオンラインアイデンティティ、 143 個人情報、個人用のオンライン環境設定、購買傾向と購買実績、商品の嗜好などがユーザ 144 ーによって管理され、ユーザーの選択した組織との間で安全に共有されます。連携ネット 145 ワークアイデンティティモデルでは、適切な当事者によって重要な個人情報が適切に使用 146 されることを保証できるようになります。 147 148 多くの機能を果たす連携アイデンティティ基盤の実現には、段階的なアプローチが可能で 149 す。第 1 段階は、現在一般的に導入されている技術に基づくシンプルな連携アイデンティ 150 ティを使用して、標準化されたマルチベンダー対応の Web ベースのシングルサインオンを 151 確立することです。この文書では、連携アイデンティティを使用してそのようなシングル 152 サインオンを実現するための実行可能なアプローチを提示した Liberty Version 1.0 アーキテ 153 クチャの概要について説明します。この概要では、初めに連携ネットワークアイデンティ 154 ティを要約し、Liberty Version 1.0 において想定される２つのシナリオを例として示し、 155 Liberty の技術要件とセキュリティフレームワークについてまとめた後、Liberty Version 1.0 156 アーキテクチャについて説明します。 157 158 1.1 本書について 159 本書は、標準規定文書ではありません。しかし、ポリシー/セキュリティおよびテクニカル 160 ノートという形で、この仕様を実装または配布する方のためのガイダンスを提供していま 161 す。Liberty アーキテクチャの詳細は、この概要に関連するいくつかの技術文書、特に 162 [LibertyAuthnContext]、[LibertyBindProf]、[LibertyArchImpl]、[LibertyProtSchema]に記載され 163 ています。注：Liberty の技術文書では、ユーザー（User）よりも、より広い概念として主 164 体者（Principal）が使用されます。Liberty 独自の用語の定義は、[LibertyGloss]に記載されて 165 います。また、この文書では、HTTP や SSL などの略語は、既に広く使用されると考え、多 166 くの略語を直接定義することなく使用しています。ただし、これらの略語の定義は、 167 [LibertyGloss]にも記載されています。注：[ ]のかっこ内に示された語句および数字は、他の 168 文書を指しています。これらの参考文書の詳細については、6 章（この文書の最後）を参照 169 してください。本書は標準規定ではないため、RFC-2119 に準拠した「MUST (しなければな 170 らない)」、「MAY (することができる)」、「SHOULD (すべきである)」などのことばは使用し 171 ません。 172 173 1.2 Liberty Alliance とは 174 175 Liberty Alliance Project は、インターネット上での新しい水準の信頼、商取引、通信を推進す 176 るために結成された幅広い産業団体です。 177 178 1.2.1 Liberty のビジョン 179 180 Liberty Alliance のメンバーは、個人や企業が重要なアイデンティティ情報のプライバシーや 181 セキュリティを犠牲にすることなく、仮想的に取引に参加できるネットワーク化された世 182 界を描きます。 183 184 1.2.2 Liberty のミッション 185 186 Liberty Alliance では、ビジョンを実現するため、広範なネットワークアイデンティティベー 187 スのやりとりを支援し、企業に以下の機能を提供するオープンな技術仕様を策定します。 188 189 190 191 192 193 ・顧客およびビジネスパートナーとの関係を経済面において強化する新しい収益機会 の基盤 ・企業が顧客に対して、インターネットに接続されたデバイスを使用する場合の選択 肢、利便性、制御性を提供できるようなフレームワーク 194 1.3 ネットワークアイデンティティとは 195 196 ユーザーがインターネット上のサービスとやりとりする場合、一般に個人の用途に合わせ 197 てサービスをカスタマイズします。たとえば、ユーザーがユーザー名とパスワードを使用 198 してアカウントを作成し、ユーザーが何の情報を表示して欲しいか、どのように表示して 199 欲しいかの好みを設定する場合があります。各ユーザーのネットワークアイデンティティ 200 は、さまざまなアカウントを構成するこれらの属性のグローバルセットです（図 1 を参照）。 201 202 ネットワークアイデンティティとは 203 204 顧客名 Eメールアドレス PIN 205 206 207 208 個人の様々なアカウン トから構成されるグロ ーバルセット 209 210 211 212 213 214 John Smith [email protected] [email protected] クレジットカード番号 社会保障番号 運転免許証 パスポート 娯楽の嗜好 通知の嗜好 従業員認定 業務カレンダー 食事の嗜好 アフィニティプログラム 友人と同僚 学歴 金融資産 215 216 217 218 図 1：ネットワークアイデンティティは、ユーザーのアカウントから構成される属性のグローバルセット 219 である 220 現在、ユーザーのアカウントは、ばらばらなインターネットサイトに分散しています。そ 221 のため、ユーザーがまとまった明確なネットワークアイデンティティを持つという概念が 222 実現されていません。 223 224 1.3.1 Liberty の目標 225 226 Liberty Alliance は、以下の主な目標を掲げています。 227 228 229 230 231 232 233 234 ・消費者がネットワークアイデンティティ情報のプライバシーとセキュリティを保護 できるようにする ・企業が第三者の介入を受けることなく、顧客との関係を維持し、管理できるように する ・複数ベンダーからの分散型の認証と認可を行えるオープンなシングルサインオン規 格を提供する ・現行および新規のすべてのネットワークアクセスデバイスをサポートするネットワ ークアイデンティティインフラを構築する 235 236 上記の機能は、第 1 に企業が Liberty 対応技術と企業間の信頼関係を定義した運用協定に基 237 づくトラストサークルに参加し、第 2 にユーザーがこれらの企業との間で設定した分散し 238 がちな（ローカルなアイデンティティとして知られる）アカウントを連携させることで達 239 成できます。言い換えると、トラストサークルとは、Liberty アーキテクチャと運用協定に 240 基づいた事業関係を持つためのサービスプロバイダ（SP）と IdP の連携のことで、これに 241 よりユーザーは安全かつシームレスな環境で取引を行うことができます。図 2 を参照して 242 ください。注：運用協定の定義は、Liberty Version 1.0 仕様の範囲に含まれていません。 連携ネットワークアイデンティティ 企業トラストサークル 名前: Joe Self アイデンティティ プロバイダ (会社) 買掛金勘定 アプリケーション サプライヤ サプライヤ サプライヤ B A C サプライチェーン アグリゲーター カレンダー 職場での プロファイル サービスプロバイダ ニュース ニュース 情報源 情報源 名前: Joe Self NI対応 小売店 アイデンティティ プロバイダ (例：銀行) 家での プロファイル NI対応 サービス NIサービス アグリゲーター ニュース 情報源 友人と家族に 関する通知 サービスプロバイダ 243 消費者トラストサークル 244 245 246 図 2：連携ネットワークアイデンティティとトラストサークル 247 Liberty から見た場合、図 2 における中心的な関係者はユーザー、SP、および IdP です。 248 249 SP は、Web ベースのサービスをユーザーに提供する組織です。この広範な分類には、イン 250 ターネットポータル、小売店、輸送業者、金融機関、娯楽企業、非営利団体、政府機関な 251 ど、事実上 Web 上のあらゆる組織が含まれます。 252 253 IdP は、他の SP がこのサービスと連携するようにビジネスインセンティブを提供する SP で 254 す。そのような関係を確立することで、図 2 に示したトラストサークルが生み出されます。 255 たとえば、企業トラストサークルの場合、IdP は従業員のネットワークアイデンティティを 256 企業全体で活用する企業そのものとなります。他の例には、ユーザーの銀行が他のさまざ 257 まな SP と事業関係を構築し、ユーザーが銀行で利用するネットワークアイデンティティを 258 それらの SP で使用できるような消費者トラストサークルがあります。注：1 つの組織が全 259 てのまたは特定のやりとりで IdP と SP を兼ねる場合もあります。 260 261 これらのシナリオは、Liberty 対応製品をインフラとして運用する SP および IdP によって実 262 現されますが、ユーザーが現在使用している Web ブラウザ以外、特別なものを用意する必 263 要はありません。 264 2 Liberty Version 1.0 におけるユーザー体験の例 265 266 このセクションでは、ユーザーの視点から見た Liberty Version 1.0 におけるユーザー体験の 2 267 つの簡単な例を示し、セクション 5 で Liberty アーキテクチャの技術詳細を解説するための 268 全般的な前準備をします。そのため、実際の技術詳細は省略されているか、または簡略化 269 されています。 270 271 注：このセクションのユーザー体験の例は必須仕様ではなく、例を示す目的でのみ記載さ 272 れています。 273 274 以下のユーザー体験の例は、以下の関係者に基づきます。 275 276 ・Joe Self 277 ・Airline.inc Web ベースのオンラインサービスのユーザー 278 279 280 パートナーの系列グループを運営する航空会社。Airline.inc が IdP と なります。 ・CarRental.inc 航空会社の系列グループのメンバーとなっているレンタカー会社。 CarRental.inc が SP となります。 281 282 Liberty Version 1.0 におけるユーザー体験には、主に以下の 2 つの側面があります。 283 284 ・アイデンティティ連携 285 ・シングルサインオン 286 287 アイデンティティ連携は、SP と IdP に分散されがちなユーザーのアカウントをリンクする 288 ことで行われます。このアカウントのリンク、つまりアイデンティティ連携は、Liberty 289 Version 1.0 におけるユーザー体験の他の側面の基盤をなし、それらの実現を可能にします。 290 291 全体的なポリシー/セキュリティに関する注：アイデンティティ連携は、必ず IdP と SP 間の事前の承 292 諾を前提とします。さらに、ユーザーに通知し、ユーザーの承諾を得て、それらの通知と承諾を監査 293 可能な形で記録することも前提となります。監査可能な通知と承諾の記録を用意することで、ユーザ 294 ーとプロバイダは、通知と承諾が行われたことを確認し、その承諾が特定の取引に限定して適用され 295 ることを記録できます。そのような記録によって、オンラインサービスにおける消費者の信頼が増し 296 ます。Liberty 対応技術の実装者および運用者は、通知とユーザーの承諾が、ユーザーとの Liberty 対 297 応のやりとりの中において、監査可能な形で適切に記録されていることを確実にしておかなければな 298 りません。 299 300 シングルサインオンを使用すると、ユーザーが IdP と SP の連携グループのメンバー（ある 301 いは、プロバイダから見た場合はトラストサークルのメンバー）に 1 度サインオンするだ 302 けで、再度サインオンすることなく、グループ内のさまざまな Web サイトを利用できるよ 303 うになります。 304 2.1 アイデンティティ連携のユーザー体験の例 305 306 通常、Liberty Version 1.0 におけるユーザー体験のアイデンティティ連携は、図 3 に示す通 307 り、Joe Self が Liberty 対応 IdP である Airline.inc の Web サイトにログインした時から始まり 308 ます。 309 310 注：Joe Self は意識していませんが、この場面の裏側では IdP が Joe Self のクレデンシャル 311 （この場合はユーザー名とパスワード）を使用して、アイデンティティを認証しています。 312 正常に完了すると、Joe Self が認証されたことになります。 Airline.inc “Proud Home of the Airline.inc Affinity Group” ログイン: JoeS パスワード: xxxx Airline.inc JoeS: 認証済 ユーザー 313 (Joe Self) 314 図 3：ユーザーが Liberty 対応 Web サイトにログインする 315 Airline.inc.は、 （系列グループ内にトラストサークルを構築する他の IdP と同様に）系列グル 316 ープのメンバー間でローカルアイデンティティを連携できることを正規ユーザーに通知し、 317 そのようなイントロダクション（導入手続き）を進めるための許可を求めます。図 4 を参 318 照してください。 Airline.inc “Proud Home of the Airline.inc Affinity Group” 注：ご利用のAirline.incのアイデ ンティティを系列グループのメン バーで使用する他のアイデンティ ティと連携させることができます。 Airline.inc JoeS: 認証済 アイデンティティ連携：はい このようなイントロダクションを 承諾しますか？ はい サービスを選択してください。 ユーザー 319 320 (Joe Self) 図 4：ユーザーがアイデンティティ連携の通知を受け、イントロダクションの許可を選択する 321 322 ポリシー/セキュリティに関する注：図 4 は、ユーザーがイントロダクションを承諾した場合を示し 323 ています。イントロダクションは、SP がトラストサークル内のどの IdP がユーザーを認証したかを判 324 断するための手段です。注：図 4 では、ユーザーはアイデンティティをいかなる SP と連携させるこ 325 とも承諾していません。図 5 に示すとおり、アイデンティティ連携の承諾を求めることは別の手順と 326 なります。 327 328 イントロダクションの手順は、（[LibertyBindProf]に記載されているとおり）IdP イントロダクション 329 プロファイル（Identity Provider Introduction Profile）経由で実行されるか、またはユーザーエージェン 330 トが Liberty 対応クライアントまたはプロキシであるなどの場合には仕様には規定されていない別の 331 手段で実行されるかもしれません。 332 333 その後数分から数時間が経過して、Joe Self は、CarRental.inc という Web サイトを運営する 334 CarRental, Inc.などの系列グループのメンバーの Web サイトを訪問したとします。実際、Joe 335 Self は元の Airline.inc Web サイトから張られた CarRental.inc Web サイトへのリンクをたどる 336 可能性もあります。どちらの場合も、CarRental.inc（Liberty 対応 SP）は、Joe Self がイント 337 ロダクションを許諾する選択をしたので、Joe Self が最近 Airline.inc Web サイトと対話操作 338 を行ったことを識別できます。 339 340 テクニカルノート：イントロダクションの実行に実際に使われる手段は、実行および配布の決定です。 341 1 つの可能な手段、IdP のイントロダクションプロファイルについては、[LibertyBindProf]に規定して 342 います。イントロダクションを進行させるために、ユーザーのログインが必要となる場合とそうでな 343 い場合があることに注意します。これは、使用されるイントロダクション技法によって異なります。 344 345 サービスプロバイダが、次の例のように、ローカルアカウントを維持している場合は、通 346 常、Joe Self のアクセス時にログインを要求し、Joe Self は、ローカルに保存された 347 CarRental.inc のアイデンティティを使用してログインします。図 5 を参照してください。 CarRental.inc “Proud Member of the Airline.inc Affinity Group” CarRental.incのアイデンティティを使 用してログインしてください。 Airline.inc JoeS: 認証済 アイデンティティ連携: はい ログイン: Joe123 パスワード:xxxxxx CarRental.inc ユーザー Joe123: 認証済 アイデンティティ連携: はい (Joe Self) 348 349 図 5：ユーザーが SP のローカルアイデンティティを使用してサインオンする 350 CarRental.inc “Proud Member of the Airline.inc Affinity Group” ようこそ 現在、あなたはAirline.inc Webサイトにサ インオンしています。 CarRental.inc の ア イ デ ン テ ィ テ ィ を Airline.incのアイデンティティと連携させ ますか？ はい ユーザー (Joe Self) 351 352 Airline.inc JoeS: 認証済 アイデンティティ連携: はい CarRental.inc アイデンティティ連携: はい Joe123: 認証済 図 6：ローカルアイデンティティの連携を確認後、 「はい」を選択 353 354 その後、Joe Self は、Airline.inc と CarRental.inc との間で彼のローカルアイデンティティを 355 連携させる機会を与えられます。図 7 を参照してください。 356 357 セキュリティ/ポリシーに関する注： SP がローカルでユーザーを認証する前後に、そのユーザーに対 358 してローカルアイデンティティ連携の同意を求めるかどうかは、ローカル配布ポリシーによります。 359 360 CarRental.inc. Web サイトへのログインの一環として、CarRental.inc.における Joe Self のロー 361 カルアイデンティティが Airline inc.における彼のローカルアイデンティティと連携されま 362 す。図 7 を参照してください。 CarRental.inc “Proud Member of the Airline.inc Affinity Group” Airline.inc JoeS: 認証済 アイデンティティ連携: はい CarRental.inc Joe123 Airline.incとCarRental.incのアイデ ンティティを連携させています （しばらくお待ちください） ................ ユーザー (Joe Self) 363 364 CarRental.inc Joe123:認証済 アイデンティティ連携: はい Airline.inc JoeS 図 7 ：Web サイトがユーザーのローカルアイデンティティを連携 365 366 ログインとアイデンティティ連携操作が完了すると、Joe Self の CarRental.inc Web サイトへ 367 のログインが完了し、CarRental.inc から通常どおりサービスが提供されます。さらに、Joe Self 368 の SP（CarRental.inc）のローカルアイデンティティが IdP（Airline.inc）のローカルアイデン 369 ティティと連携されたため、Web サイトに新しい選択肢が表示されます。図 8 を参照して 370 ください。 371 372 テクニカルノート：一部の図はユーザー体験を表しています（例、図 7）。これらの図は、アイデン 373 ティティ連携の影響についてユーザーの視点から簡略化して図示したものです。実際には「JoeS」や 374 「Joe123」などの直接意味のある文字列の識別子が IdP と SP の間で交換されることはありません。む 375 しろ、特定困難なユーザーハンドルが交換されます。詳細については、5.4.1 を参照してください。 376 377 また、認証および連携またはそのいずれかの処理でエラーが発生した場合、SP はユーザーに適切な通 378 知を表示する必要があります。 CarRental.inc “Proud Member of the Airline.inc Affinity Group” Joe123さん、ようこそ。あなたの CarRental.incのアイデンティティ はAirline.incのアイデンティティと 連携されています。 Airline.inc JoeS:認証済 アイデンティティ連携：はい CarRental.inc Joe123 以下からサービスを選択してくだ さい。 ・車を予約する ・Airline.incのマイルを確認する ・その他 ユーザー (Joe Self) CarRental.inc Joe123:認証済 アイデンティティ連携：はい Airline.inc JoeS 379 380 図 8：SP が通常どおりユーザーにサービスを提供する 381 382 ポリシー/セキュリティに関する注：アイデンティティ連携を提供するには、ビジネスの必要条件を満 383 たさなければなりません。2 つの必要条件は、連携についてユーザーに通知することと、イントロダ 384 クションの進行について承諾を求めることです。ほかに、アイデンティティの認識と相互認証の受け 385 入れに関するポリシーを確立するために、系列グループメンバー間で取り決めを作成することがあり 386 ます。 387 2.2 シングルサインオンのユーザー体験の例 388 389 シングルサインオンは、アイデンティティ連携に基づいて行われ、シンプルなユーザー体 390 験をもたらします。Joe Self は Airline.inc Web サイトにログインし、その後にアイデンティ 391 ティ連携を設定した CarRental.inc Web サイトを訪問します。Joe Self の Airline.inc Web サイ 392 トにおける認証状態は CarRental.inc Web サイトで相互に受け付けられ、 Joe Self は 393 CarRental.inc のサイトへも同じようにログインできます。図 9 および図 10 を参照してくだ 394 さい。 Airline.inc Airline.inc “Proud Home of the Airline.inc Affinity Group” ログイン : JoeS xxxx パスワード: JoeS: 認証済 アカウント連携: はい CarRental.inc Joe123 ユーザー 395 (Joe Self) 396 397 図 9: ロ ー カ ル ア イ デ ン テ ィ テ ィ を 使 用 し て ユ ー ザ ー が IdP の Web サ イ ト に ロ グ イ ン CarRental.inc “Proud Member of the Airline.inc Affinity Group” Joe123さん、ようこそ。サインオ ンは完了しています。 以下からサービスを選択してくだ さい。 ・車を予約する ・Airline.incのマイルを確認する ・その他 ユーザー (Joe Self) Airline.inc JoeS:認証済 アイデンティティ連携：はい CarRental.inc Joe123 CarRental.inc Joe123:認証済 アイデンティティ連携：はい Airline.inc JoeS 398 399 図 10：ユーザーが SP の Web サイトに移動し、その認証状態を SP の Web サイトで相互に受け付ける 400 401 Joe Self が洞察力のある人であれば、CarRental.inc のセッションに表示される名前がローカ 402 ルアイデンティティを連携させた Airline.inc のローカルアイデンティティではなく、 403 CarRental.inc のローカルアイデンティティであることに気付きます。 404 405 テクニカルノート：ユーザーの実際のアカウント識別子は連携時に交換されないため、SP はユーザー 406 の IdP の識別子を表示できません。 407 408 また、多くの SP の Web サイトでは、ユーザーに応答する際に個人を特定可能な識別子を使用しない 409 場合があります。たとえば、スポーツイベントのスケジュールサイトのように、ユーザーが表示の好 410 みを指定できる、広告運営のサイトがあるとします。このようなサイトでは、 「（あなたの）希望の表 411 示方法を設定してください」、「（あなたの）興味のあるイベントの一覧です」など、ユーザーを単に 412 「あなた」と呼ぶことがあります。 413 414 セキュリティ/ポリシーに関する注：ユーザーがシングルサインオンメカニズムによって認証された場 415 合でも、ユーザーによる SP の Web サイト利用はローカルポリシーに従います。たとえば、サイトに 416 1 日の利用時間の制限がある場合、サイトがメンテナンスを実施中の場合、ユーザーと SP の関係が特 417 定の状態にある場合（たとえば、大切なユーザーに対しては特典ページを表示し、問題のある顧客に 418 は、未払いの料金を通知してアクセスを制限する）などがあります。 419 420 3 Liberty の技術要件の概要 421 422 このセクションでは、Liberty の一般的および機能的な技術要件について要約します。 423 424 3.1 全般的な要件 425 426 Liberty 対応システムは、3.1.1 および 3.1.2 に示された一般的な原則に従わなければなりませ 427 ん。これらの原則はすべての分野の機能に適用されます。 428 429 3.1.1 クライアントデバイス/ユーザーエージェントの相互運用性 430 431 Liberty Version 1.0 クライアントには、現在採用されている広範な Web ブラウザ、その他の 432 Web 対応クライアントアクセスデバイス、さらに新しく設計され、特定の Liberty 対応機能 433 を持つ Web 対応ブラウザやクライアントが含まれます。 434 435 Liberty Version 1.0 アーキテクチャおよびプロトコル仕様は、すべての Liberty Version 1.0 ク 436 ライアントに対して、基本的レベルの機能性をサポートしなければなりません。 437 438 439 3.1.2 オープン性に関する要件 440 441 Liberty アーキテクチャおよびプロトコル仕様では、以下の項目をできる限りサポートしな 442 ければなりません。 443 444 ・オペレーティングシステム 445 ・プログラム言語 446 ・ネットワークインフラ 447 448 さらに、トラストサークルの境界を越える相互運用性など、Liberty クライアントおよびサ 449 ービス間のマルチベンダーによる相互運用性を妨げてはなりません。 450 451 3.2 機能に関する要件 452 453 Liberty アーキテクチャおよびプロトコルは、Liberty 対応の実装で以下の処理を実行できる 454 ように規定されなければなりません。 455 456 ・アイデンティティ連携 457 ・認証 458 ・仮名の使用 459 ・グローバルログアウト 460 461 3.2.1 アイデンティティ連携 462 463 アイデンティティ連携に関する要件には、以下の項目が明記されています。 464 465 ・プロバイダは、アイデンティティ連携と解除について、ユーザーに通知する 466 ・SP および IdP は、アイデンティティの連携解除を相互に通知する 467 ・IdP は、IdP でのユーザーアカウントの終了を関係する SP に通知する 468 ・SP および/または IdP は、IdP または SP におけるユーザーの連携アイデンティティの 469 一覧を各ユーザーに提供する 470 471 3.2.2 認証 472 473 認証に関する要件には、以下の項目が含まれます。 474 475 ・ユーザー側で IdP と SP 間のサイトを変更する方法を提供すること。つまりユーザー 476 が A から B にサイトを変更する方法（クリック、お気に入りまたはブックマーク、URL 477 アドレスバーなど）をサポートしなければならない 478 ・ユーザーがクレデンシャルや、他の個人識別情報を IdP に提供する前に、IdP の認証 479 済みアイデンティティをユーザーに与えること。 480 ・認証とシングルサインオン処理時に、IdP および SP のアイデンティティを相互に認 481 証する時にはもちろん、IdP、SP、ユーザーエージェントの間で交換される情報の機密 482 性、完全性、真正性を保証すること。 483 ・幅広い認証方法をサポートし、認証方法を特定し、認証方法を認証クラスにまとめ、 484 認証クラスを引用して交換できること。ただし、この情報を交換するためのプロトコ 485 ルは、Liberty Version 1.0 仕様の範囲に含まれていません。 486 ・認証状態、認証方法、仮名など、ユーザーに関連する最低限の認証情報を交換する 487 ・IdP で同じまたは異なる認証クラスを使用して、ユーザーを再認証できるよう要求す 488 る機能を SP に持たせること。ただし、IdP に対して、ユーザーが登録されている認証 489 クラスをプログラムによって交換する方法は、Liberty Version 1.0 仕様の範囲には含まれ 490 ていません。 491 492 3.2.3 仮名 493 494 Liberty 対応の実装では、すべての IdP および SP 間の ID 連携で一意な仮名の使用をサポー 495 トしなければなりません。 496 497 3.2.4 グローバルログアウト 498 499 Liberty 対応の実装では、ユーザーが IdP からログアウトした時点で SP に通知する機能をサ 500 ポートしなければなりません。 501 502 4 Liberty のセキュリティフレームワーク 503 504 表 1 に、Liberty 仕様、つまり Liberty 対応の実装に組み込まれるセキュリティメカニズムを 505 チャネルセキュリティとメッセージセキュリティという 2 つの観点からまとめます。また、 506 Liberty の実装で要求されるセキュリティに関する処理要件について要約します。注：この 507 セクションは標準を定義するのが目的ではないため、セキュリティメカニズムに関する標 508 準の説明については、[LibertyProtSchema]および[LibertyBindProf]を参照してください。 509 510 511 表 1 ：Liberty のセキュリティメカニズム セキュリティメカニズム チャネルセキュリティ メッセージセキュリティ（リ クエスト、アサーション） 機密性 必要 任意 メッセージごとのデータ完 必要 必要 - 必要 IdP- 必要 SP - 任意 - データ発信元の認証 - 必要 否認防止 - 必要 全性 トランザクションの完全性 ピアエンティティの認証 512 513 チャネルセキュリティでは、IdP、SP、ユーザーエージェント間の通信を保護する方法を取 514 り扱います。 Liberty の実装では、セキュリティ特性が TLS や SSL に相当するのであれば IPsec 515 などの他の通信セキュリティプロトコルが採用される可能性も残していますが、基本的に 516 はチャネルセキュリティには TLS1.0 または SSL3.0 を使用しなければなりません。注：TLS、 517 SSL、および同等のプロトコルでは、認証だけでなく、当事者間の通信の機密性と完全性が 518 保護されます。 519 520 チャネルセキュリティには、以下の重要点があります。 521 522 ・認証に関しては、SP は IdP のサーバー側の証明書を使用して、IdP を認証する必要が 523 あります。また、IdP は、SP のクライアント側の証明書を使用して、SP の認証を要求 524 するオプションがあります。 525 526 ・さらに、それぞれの SP は、認可された IdP の一覧を作成する必要があり、それぞれ 527 の IdP は、認可された SP の一覧を作成する必要があります。このようにして、SP と IdP 528 の組み合わせは、Liberty のやりとりを開始する前に、相互に認可されなければなりま 529 せん。このような認可は、認証に加えて行われます（注：この構成の形式は実装依存 530 の問題であり、たとえば、名前の一覧として、または他のトラストサークルのメンバ 531 ーの X.509 証明書のセットとして表示されます）。 532 533 ・その IdP で認証されたアイデンティティは、ユーザーが個人認証データをその IdP に 534 提示する前に表示されなければなりません。 535 536 メッセージセキュリティでは、IdP、SP、ユーザーエージェント間で渡される個別の Liberty 537 プロトコルのメッセージに適用されるセキュリティメカニズムを取り扱います。これらの 538 メッセージは、上記でセキュリティ特性を説明した通信チャンネルで交換されます。 539 540 メッセージセキュリティには、以下の重要点があります。 541 542 ・Liberty プロトコルのメッセージと一部コンポーネントは、一般的にデジタル署名さ 543 れ検証される必要があります。メッセージを署名し検証することで、データ完全性、 544 データ送信元の認証、および否認防止を提供できます。そのため、IdP および SP は、 545 TLS および SSL チャネル保護に適用される鍵の組み合わせとは異なり、長期の署名に 546 適した鍵の組み合わせを使用する必要があります。 547 548 セキュリティ/ポリシーに関する注：特に、[LibertyProtSchema]に定義されたシングルサインオン 549 および連携プロトコルの<AuthnRequest>メッセージは、IdP と SP 間の合意で指定されたとおり 550 に署名される場合とそうでない場合があり、プロバイダのメタデータの<AuthnRequestSigned>要 551 素によって示されます。Liberty アーキテクチャの範囲に含まれない手段でネットワークとシス 552 テムへのアクセスが管理/制御される企業ネットワークなどの場合は、このメッセージに署名し 553 ない方が妥当と考えられます。 554 555 ・SP と IdP 間のトランザクションでは、リクエストが再実行されないことを保証し、 556 受信したレスポンスが発行されたリクエストと正しく対応するかどうかをチェックす 557 る必要があります。時間による有効期限の保証が行われる場合があります。これらの 558 技術によって、トランザクションの完全性が図られます。 559 560 トラストサークルのメンバーになるには、証明書発行機関の選択、X.509 クレデンシャルの 561 取得、信頼された公開鍵の作成および管理、対応するクレデンシャルの有効期間の管理に 562 関して各プロバイダが相互に合意する必要があります。 563 564 セキュリティ/ポリシーに関する注： SSL や TLS など、多くのセキュリティメカニズムは、DNS、タイム 565 サービス、ファイアウォールなどの他のネットワークサービスや機能に依存したり、相互にやりとりしな 566 がら機能したりします。これらのサービスやファシリティには、Liberty 対応システムが依存するそれぞれ 567 独自のセキュリティ検討項目があります。 568 569 5 Liberty アーキテクチャ 570 571 Liberty の全体的なアーキテクチャは、以下の 3 つの相互に関連するコンポーネントから構 572 成されます（図 11 を参照）。 573 574 ・Web リダイレクト 575 ・Web サービス 576 ・メタデータとスキーマ 577 578 Web サービス 579 アーキテクチャのコンポーネント 580 581 582 Identity Providers メタデータとスキーマ アーキテクチャのコンポーネント Service Providers 583 584 585 586 587 ユーザー 588 589 Web リダイレクト 590 591 アーキテクチャのコンポーネント 592 図 11： Liberty の全体的なアーキテクチャ 593 表 2 に、アーキテクチャの各コンポーネントの役割をまとめます。 594 595 表 2：Liberty アーキテクチャのコンポーネント 596 Web リダイレクト 既に導入されているユーザーエージェントに よって Liberty 対応エンティティがサービスを 提供できるようにする操作 Web サービス Liberty 対応エンティティが直接通信できるよ うにするためのプロトコルのプロファイル メタデータとスキーマ さまざまなプロバイダ固有およびその他の情 報を伝えられるようにするために Liberty 対応 サイトで使用される一般的なメタデータとフ ォーマットの組み合わせ 597 598 5.1 節から 5.3 節では、アーキテクチャの各コンポーネントについて説明します。5.4 節から 599 5.6 節ではアーキテクチャのコンポーネントを[LibertyProtSchema]および[LibertyBindProf]に 600 詳述されている具体的なプロトコルとプロファイルに関連付け、5.7 節ではユーザー体験の 601 例を示します。 602 603 5.1 Web リダイレクトのアーキテクチャコンポーネント 604 605 Web リダイレクトのアーキテクチャコンポーネントは、HTTP リダイレクトによるリダイレ 606 クトとフォーム POST によるリダイレクトの 2 種類があります。これらの 2 種類のリダイレ 607 クトでは、ユーザーエージェントを介して IdP と SP の間に通信チャネルが作成されます。 608 図 12 を参照してください。 609 610 611 Service Provider Identity Provider 612 613 1. 2. 5. 3. 4. 614 615 616 ユーザーエージェント 617 618 619 図 12：ユーザーエージェントを経由する SP と IdP 間の Web リダイレクト 620 621 5.1.1 HTTP リダイレクトによるリダイレクト 622 623 HTTP リダイレクトによるリダイレクトは、HTTP プロトコルの HTTP リダイレクトクラス 624 の応答（リダイレクト） （[RFC2616]を参照）と、URI（[RFC1738]および[RFC2396]を参照） 625 の文法を使用して、IdP と SP 間に通信チャネルを提供します。そのため、図 12 に示された 626 手順では、以下のように SP と IdP 間に通信チャネルが作成されます。 627 628 1. ユーザーエージェントが SP に HTTP リクエスト（通常は GET）を送信します。通 629 常はここでユーザーがユーザーエージェントに表示された Web ページのリンクをク 630 リックしています。 631 632 2. SP が状態コード 302（リダイレクト）の HTTP 応答を返し、Location ヘッダーフィー 633 ルドの URI を変更します。この例の場合、Location URI は IdP をポイントし、その 634 URI には SP をポイントするために埋め込まれた別の URI が含まれています。 635 636 3. ユーザーエージェントが IdP に HTTP リクエスト（通常は GET）を送信し、GET の 637 引数として手順 2 で返された応答の Location フィールドから取得した URI 全体を指 638 定します。注：この URI には、SP をポイントする 2 つ目の埋め込まれた URI が含ま 639 れます。 640 641 4. IdP が Location ヘッダーフィールドに（手順 3 で提供された GET 引数の URI から抽 642 出した）SP をポイントする URI を含むリダイレクトで応答し、自分自身をポイント 643 する 2 つ目の埋め込まれた URI を任意で含めます。 644 645 5. ユーザーエージェントが SP に HTTP リクエスト（通常は GET）を送信し、GET の 646 引数として手順 4 で返された応答の Location フィールドから取得した完全な URI を 647 指定します。注：この URI には、IdP をポイントする 2 つ目の埋め込まれた URI が 648 含まれる場合があります。 649 650 注：両方の URI が HTTP GET リクエストの引数として渡され、リダイレクト応答の Location 651 応答ヘッダーフィールドには埋め込み URI とその他の任意データのいずれかまたは両方を 652 含めることができます。そのため、IdP と SP は、このチャネルで比較的自由に任意の情報 653 を交換することができます。表 3 を参照してください。 654 655 表 3：HTTP リダイレクトへのパラメータの埋め込み 656 Location：http://www.foobar.com/auth Location http://www.foobar.com/auth?XYZ=1234 foobar.com にリダイレクトします。 ： foobar.com にリダイレクトして、パ ラメータ"XYZ"の値として"1234"を 渡します。 657 658 5.1.2 フォーム POST によるリダイレクト 659 660 フォーム POST によるリダイレクトでは、図 12 の手順が以下のように変更されます。 661 662 2. SP がユーザーエージェントに対し、HTML フォームを返して応答します。この際 663 HTML フォームには IdP をポイントする action パラメータと POST 値を持つ method 664 パラメータが含まれます。他のフォームフィールドに任意のデータが含まれる場合 665 もあります。またフォームには、ユーザーの操作なしで次の手順を実行するような 666 JavaScript や ECMAscript フラグメントが含まれる場合もあります。 667 668 3. ユーザーが Submit ボタンをクリックするか、JavaScript または ECMAscript が実行さ 669 れます。どちらの場合も、フォームとその任意データの内容が HTTP POST メソッド 670 によって IdP に送信されます。 671 672 手順４、５では、フォーム POST による通信方向が逆になるように、IdP と SP の立場を入 673 れ替えることになります。 674 675 5.1.3 クッキー 676 677 ポリシー/セキュリティに関する注：特に個人識別情報と認証情報の片方または両方がクッキーに含ま 678 れる場合は、実装者および導入者のクッキー使用には十分な検討を行う必要があります。クッキーは、 679 短命（このセッションのみ）または永続的のいずれかになります。永続的なクッキーはディスクに書 680 き込まれ、ユーザーエージェントの呼び出しによって持続されるため、特に注意を要します。セッシ 681 ョンの認証トークンが永続的なクッキーにキャッシュされ、ユーザーがブラウザを終了した後、2 人 682 目のユーザーがシステムを使用してブラウザを再起動すると、（認証メカニズムによって課された認 683 証期限が切れていない場合）2 人目のユーザーが 1 人目のユーザーになりすますことができます。 684 685 さらに、永続的なクッキーは、ユーザーの承諾が得られた場合に限って使用されるべきです。この承 686 諾手順を踏むことで、たとえば公共のコンピュータを使用するユーザーが使用を終了した後もユーザ 687 ーエージェントのクッキーのキャッシュに残る永続的なクッキーを禁止できます。 688 689 5.1.3.1 なぜクッキーを一般的に使用しないのか 690 691 クッキーは、[RFC2965]に規定された HTTP 状態管理メカニズムであり、Web サーバーが情 692 報を保存する、つまりユーザーエージェントに状態を維持させるための手段です。ただし、 693 普及率の高いユーザーエージェントのデフォルトのセキュリティ設定では、書き込んだ Web 694 サイトだけがクッキーを読み込めるようになっています。この時のサイトの識別は、読み 695 込みと書き込みを行うサイトの DNS ドメインに基づいて行われます。 696 697 DNS ドメインの異なる複数の IdP および SP でクッキーを使用して通信できるようにするに 698 は、ユーザーがユーザーエージェントのデフォルトのセキュリティ設定を低く設定しなけ 699 ればなりません。このオプションは、たいてい受け入れられない条件となります。 700 701 また、ユーザーおよび/または組織にとって、ユーザーエージェントでクッキーをオフにす 702 ることは珍しくありません。 703 704 5.1.3.2 クッキーの使用場所 705 706 Liberty では、クッキーはローカルセッションの状態を保持するために使用され、イントロ 707 ダクションの問題に対応する際に使用されることがあります（5.5 を参照）。 708 709 IdP がクッキーを使用して SP にデータを任意で送信できないといっても、IdP と SP がロー 710 カルセッションの状態や、おそらく永続的な他の情報を保存するためにクッキーを書き込 711 めなくなるわけではありません。 712 713 5.1.4 Web リダイレクトのまとめ 714 715 Web リダイレクトは、理想的な分散システムアーキテクチャではありません。 716 717 ポリシー/セキュリティに関する注：5.1.1 から 5.1.3 で説明した Web リダイレクトチャンネルによる通 718 信には、十分に検証された多くのセキュリティの脆弱性が存在するため、Web リダイレクトを使用す 719 る プ ロ トコ ルを 設 計 する 際に は 注 意しながら検討する必要があります。そのような注意点は 720 [LibertyBindProf]に規定されたプロファイルの設計に組み入れられており、その文書の中で（平文での 721 転送やキャッシュの脆弱性などに関する）特定の注意点が必要に応じて参照されています。以下に、 722 セキュリティの脆弱性の例を挙げます。 723 724 ・傍受：5.1.1 から 5.1.3 までのすべての手順を SSL または TLS セッション、あるいは IPsec を使 725 用する VPN などのセキュリティ保護されたその他の通信トランスポートで実行しない限り、こ 726 のような通信は平文で送受信されます。 727 728 ・ユーザーエージェントの漏洩：チャンネルはユーザーエージェントを経由してリダイレクトさ 729 れるため、ユーザーエージェントに情報がキャッシュされ、後で漏れる可能性があります。伝達 730 された情報は平文でブラウザに保持されるため、セキュリティ保護されたトランスポートを使用 731 しても、このキャッシュが実行される可能性があります。そのため、この方法で機密情報を伝達 732 するには、チャネルで送信する前に暗号化する必要があります。 733 734 テクニカルノート：Web リダイレクトの主な制限は、GET リクエストの引数およびリダイレクトの 735 Location フィールドの値として渡された URI の全体のサイズです。この要素は、ブラウザによって異 736 なり、特に一部の携帯端末では特に小さいサイズ制限が存在します。これらの制限は、 737 [LibertyProtSchema]および[LibertyBindProf]に規定されたプロトコルの設計に組み込まれています。 738 739 Web リダイレクトには脆弱性と制限があるにもかかわらず、このメカニズムを使用すると、 740 インターネット上に展開されている HTTP インフラでシングルサインオンなどのドメイン 741 を越えた分散型のやりとりを実現できます。 742 743 Web リダイレクトのバリエーションは、シングルサインオン、アイデンティティ連携終了 744 通知、IdP イントロダクション、シングルログアウトなど、[LibertyBindProf]に規定されたい 745 くつかのプロファイルの基盤となっています。 746 747 5.2 Web サービスのアーキテクチャコンポーネント 748 749 さまざまな Liberty プロトコルのインタラクション手順は、Web リダイレクトで行われる他 750 の手順に加え、システムエンティティ間で直接実行され、SOAP で伝達される RPC に似た 751 プロトコルメッセージに基づきます（[SOAP1.1]を参照）。SOAP は RPC に似た対話管理と 752 XML および HTTP を使用するメッセージ通信のために一般的に実装された仕様であり、こ 753 のアーキテクチャコンポーネントにもともと適しています。 754 755 5.3 メタデータとスキーマのアーキテクチャコンポーネント 756 757 メタデータとスキーマは、SP と IdP 間でプロトコルまたはプロトコル以外の方法で交換さ 758 れるさまざまな情報のサブクラスとそのフォーマット全般を示す包括的な用語です。交換 759 される情報のサブクラスは、以下のとおりです。 760 761 ・アカウント/アイデンティティ：Liberty Version 1.0 でのアカウント/アイデンティティ 762 は、単に SP と IdP が通信時にユーザーを参照する際に使用する名前として機能する 763 特定困難なユーザーハンドルです。今後の Liberty フェーズで、さまざまな属性が含 764 まれる予定です。 765 766 ・認証コンテキスト：Liberty は、IdP による任意の認証メカニズムおよび技術の使用に 767 明示的に適応します。さまざまな IdP が異なる技術を選択し、異なる手順に従い、ユ 768 ーザーの認証方法に関する異なる法的責任を負います。IdP が行う選択は、主に IdP 769 が連携する SP の要件によって決まります。これらの要件は、SP がユーザーに提供す 770 るサービスの性質（つまり、交換される情報の機密性、関連する金銭的価値、SP の 771 リスク許容度など）によって決められます。その結果、小規模なサービスを除いて 772 は、SP が IdP から受け取る認証アサーションを十分に信頼するには、SP は認証アサ 773 ーションの基盤となる元の認証メカニズムで使用されたり準拠したりする技術、プ 774 ロトコル、および手順を知っておく必要があります。認証コンテキストスキーマに 775 よ っ て 、 SP と IdP に そ の よ う な 情 報 を 伝 え る 手 段 が 提 供 さ れ ま す 776 （[LibertyAuthnContext]を参照）。 777 778 ・プロバイダのメタデータ：IdP および SP が相互に情報を伝えるには、各々に関する 779 メタデータを概念的に持っていなければなりません。これらのプロバイダのメタデ 780 ー タ に は 、 X.509 証 明 書 や サ ー ビ ス エ ン ド ポ イ ン ト な ど が 含 ま れ ま す 。 781 [LibertyProtSchema]には、プロバイダのメタデータ交換に使用される IdP と SP のメタ 782 データスキーマが定義されています。ただし、プロバイダのメタデータ交換プロト 783 コルは、Liberty Version 1.0 仕様の範囲に含まれていません。 784 785 5.4 シングルサインオンとアイデンティティ連携 786 787 Liberty のシングルサインオンとアイデンティティ連携については、[LibertyProtSchema]に規 788 定されたシングルサインオンおよび連携プロトコル（Single Sign-On and Federation Protocol） 789 によって進められます。一連のプロトコルの流れで、アイデンティティ連携（5.4.1 を参照） 790 およびシングルサインオン（5.4.2）の両方が進められます。[LibertyBindProf]で定義された 791 全体的なプロトコルの流れのさまざまなプロファイルについては、5.4.3 で説明しています。 792 793 5.4.1 アイデンティティ連携 794 795 ユーザーが IdP を初めて使用して SP にログインする場合には、シングルサインオンの中で 796 既存の情報を守るために、SP の既存のローカルアイデンティティを IdP のログインと連携 797 させることをオプションとして提供しなければなりません。図 13 を参照してください。複 798 数の IdP と SP が含まれるシステムでは、プロバイダ間において、ユーザーが（自分の判断 799 で）一意に識別されうるメカニズムが存在することが重要です。ただし、特定の IdP に結び 800 つかないようなグローバルに一意なアイデンティティを作成することは技術的に困難であ 801 り、グローバルに一意なアイデンティティの可搬性を確保することはビジネス上困難です。 802 803 804 805 806 807 808 Identity Provider A 連携を開始 Joe123@IDP_A.com Service Provider A JoeS@SP_A.com 図 13：ユーザーが 2 つのアイデンティティの連携を開始する 809 810 ユーザーが IdP を使用して初めて SP にログインした際にアイデンティティ連携を選択する 811 と、明示的な信頼関係、つまり連鎖が作成されます。複数のアイデンティティを相互に連 812 携できますが、それぞれのアイデンティティ間ごとにだけ明示的なリンクが存在します。 813 信頼の連鎖では、手順ごとにユーザーのアイデンティティ情報をチェックしなければなら 814 ないため、プロバイダが相互にスキップしてユーザーへの情報またはサービスを要求する 815 ことはできません。そのため、信頼の連鎖において 2 つの要素が情報をやりとりする場合 816 に、ユーザーを識別できることが唯一の要件となります。 817 818 トラストサークルのメンバーは、ユーザーに実際のアカウント識別子を提供する必要はな 819 く、その代わりにあるユーザーにハンドルを提供できます。メンバーは、特定のユーザー 820 に複数のハンドルを作成することもできます。ただし、IdP は、複数の Web サイトを持つ 821 SP がハンドルを Web サイト間で解決できるように、このような SP に対しては、１つのハ 822 ンドルを作成しなければなりません。 823 824 このような連携に含まれる IdP と SP は他のユーザーハンドルを記憶する必要があるため、 825 ユーザーディレクトリにエントリを相互に作成し、互いのユーザーハンドルを記録します。 826 図 14 および図 15 を参照してください。 827 828 Identity Provider A 829 Service Provider A 830 831 Joe123@ IDP_A.com JoeS@SP_A.com 832 <alias="mr3tTJ340ImN2ED" <alias="dTvIiRcMlpCqV6xX" 833 SecurityDomain="SP_A.com" SecurityDomain=" IDP_A" 834 Name="dTvIiRcMlpCqV6xX" Name="mr3tTJ340ImN2ED" 835 /> /> 836 837 838 図 14：アイデンティティ連携における IdP および SP のユーザーディレクトリ 839 840 テクニカルノート：図 14 はそれに続く３枚の図とともに二者相互間のアイデンティティ連携、すな 841 わち SP と IdP の両者がユーザーのためにハンドルを交換することを説明しています。しかしながら、 842 二者相互間のハンドル交換は Liberty シングルサインオン連携プロトコルのオプショナルな機能です。 843 あるシナリオにおいては、IdP のハンドルのみが SP に伝達されます。このシナリオでは、SP が自身 844 のユーザーリポジトリを別途維持しない場合、典型的なケースとなるでしょう。 845 846 前述の図において IdP と SP を結ぶ直線は、通信のやりとりというよりはむしろ連携関係を表してい 847 ます。 848 849 850 Service Provider A 851 852 853 854 855 Identity Provider A 856 857 858 859 860 861 Joe123@ IDP_A.com <alias="mr3tTJ340ImN2ED" SecurityDomain="SP_A.com" Name="dTvIiRcMlpCqV6xX" /> <alias="xyrVdS+xg0/pzSgx" SecurityDomain="SP_B.com" Name="pfk9uzUN9JcWmk4RF" /> JoeS@SP_A.com <alias="dTvIiRcMlpCqV6xX" SecurityDomain=" IDP_A" Name="mr3tTJ340ImN2ED" /> Service Provider B JSch@SP_B.com <alias="pfk9uzUN9JcWmk4RF" SecurityDomain=" IDP_A.com" Name="xyrVdS+xg0/pzSgx" /> 862 863 図 15：アイデンティティ連携における IdP および複数の SP のユーザーディレクトリ 864 865 ポリシー/セキュリティに関する注： 866 867 1. 図 15 では、SP_A と SP_B が Joe Self に関する情報を直接伝えられません。これらの SP は、IdP と 868 個別に情報をやりとりすることしかできません。ポリシーとセキュリティの観点では、この機能は 869 妥当です。Joe Self が SP 間で自分の情報を交換できるように希望するならば、実際に選択して、２ 870 つの SP のアイデンティティを明示的に連携させなければなりません。 871 872 この機能のもう 1 つの側面は、ユーザーのローカルアイデンティティがたとえば SP_A で危険にさ 873 らされても、IdP_A または SP_B のローカルアイデンティティは必ずしも危険にさらされない点で 874 す。 875 876 2. mr3tTJ340ImN2ED などのユーザーハンドル（名前識別子とも呼ばれます）のプロパティは、注意し 877 て取り扱う必要があります。特定困難にするだけでは十分とは言えません。名前識別子の作成に関 878 する注意点については、[LibProtSchema]に記載されています。また、ユーザーハンドルは定期的に 879 更新する必要があります。SP は、[LibertyBindProf]に定義された名前識別子登録プロファイルによ 880 って、IdP に任意で提供するユーザーハンドルを更新できます。Liberty Version 1.0 には、IdP によっ 881 て発行される名前識別の自動更新メカニズムについての規定はありません。 882 883 ユーザーはもちろん 1 つの IdP を使用して複数の SP にサインインできますが、さらに複数 884 の IdP を特定の SP にリンクすることもできます。図 16 を参照してください。この機能は、 885 職場のコンピュータから家庭のコンピュータに、あるいはコンピュータからモバイルデバ 886 イスに切り替える場合のような、ユーザーが別の IdP およびトラストサークルにそれぞれ関 887 連付けられている場合に便利です。 888 889 890 Identity Provider A 891 892 893 894 Joe123@IDP_A.com <alias="mr3tTJ340ImN2ED" SecurityDomain="SP_A.com" Name="dTvliRcMlpCqV6xX" /> Service Provider A 895 896 897 898 899 900 901 Identity Provider B JoeS987@IDP_B.com <alias="UIK34srW465AXKL" SecurityDomain="SP_A" Name="2df6ghUI46EcduM" /> JoeS@SP_A.com <alias="dTvliRcMlpCqV6xX" SecurityDomain="IDP_A" Name="mr3tTJ340ImN2ED" /> <alias="2df6ghUI46EcduM" SecurityDomain="IDP_B" Name="UIK34srW465AXKL" /> 902 903 図 16：SP と連携する 2 つの IdP を使用するユーザー 904 905 ポリシー/セキュリティに関する注：ここで、ユーザーがいかに簡単にアイデンティティを切り替えら 906 れ、この機能がどのように実現されるかについて、微妙な問題が発生します。IdP_A は、ユーザーの 907 複数のデバイスに結び付けられた同じトラストサークルに属するかもしれません。この場合、ユーザ 908 ーがどの（または両方の）IdP にログインしているかを知ればよいのかといった疑問が生じます。そ 909 のような疑問を満たす機能は、IdP とトラストサークルが自分自身を区別する方法です。 910 911 図 16 に示されるように、2 つの IdP を 1 つの SP に連携させると、ユーザーはどちらかの 912 IdP を使用して SP にログインできますが、新しい SP を両方の IdP に連携させなければな 913 らず、これが煩わしい手順となります。ユーザーにとっての代替策は、複数の IdP を連携 914 させ、IdP が相互の情報にアクセスできるようなポリシーを設定することです。図 17 とポ 915 リシー/セキュリティに関する注を参照してください。ユーザーは好みとする IdP を使用し 916 て SP にログインできますが、いつでも IdP を SP に追加することができます。 917 918 Identity Provider A 919 920 921 922 923 924 925 926 927 928 929 930 Joe123@ IDP_A.com <alias="mr3tTJ340ImN2ED" SecurityDomain="SP_A.com" Name="dTvIiRcMlpCqV6xX" Service Provider A /> <alias="2df6ghUI46EcduM" SecurityDomain=" IDP_B" Name="UIK34srW465AXKL" JoeS@SP_A.com /> <alias="dTvIiRcMlpCqV6xX" 931 Identity Provider B 932 933 JoeS987@ IDP_B.com 934 <alias="UIK34srW465AXKL" 935 SecurityDomain=" IDP_A" 936 Name="2df6ghUI46EcduM" 937 /> SecurityDomain=" IDP_A" Name="mr3tTJ340ImN2ED" /> <alias="2df6ghUI46EcduM" SecurityDomain=" IDP_B" Name="UIK34srW465AXKL" /> 938 939 図 17：2 つの IdP を連携させたユーザー 940 941 テクニカルノート：図 17 において IdP A は SP・IdP の双方として動作します 942 943 ポリシー/セキュリティに関する注： 944 945 1. このような IdP 間の連携関係（図 17）の意味は、基盤となる Liberty プロトコルに規定されてい 946 ませんが、除外されているわけでもありません。これらの意味については、IdP 間の契約と、展開さ 947 れた Liberty 対応の実装の機能によって言及される必要があります。 948 949 2. 加えて、どのように IdP 間の信頼関係が確立され、SP に対しそれらの関係を伝えるかについては 950 規定されていません。IdP が図 17 に示すような関係を可能とするためには IdP が相互に管理ポリシ 951 ーを定義する必要があり、かつ、そのような信頼関係を（図 17 における SP A のような）信頼側の 952 SP に示す手段について定義しておく必要があります。 953 954 3.トラストサークルの合意の中で、連携の失敗をユーザーに提示する方法について言及すべきです。 955 956 957 4. 連携を実現するために、IdP と SP の間で交わされるアサーションの該当部分は記録に残すべきで す。 958 959 5. SP および/または IdP に多くのローカルアイデンティティを作成して連携させると、ユーザーは、 960 シングルサインオンで多くの SP に認証するための基準として使用される多くのローカルクレデン 961 シャルを持つことになります。この状態はリスクを生みます。たとえば、ユーザー名とパスワード 962 などの繰り返し使用可能なユーザークレデンシャルを持つすべての IdP は、そのアカウントに連携 963 する SP でユーザーになりすますことができます。 964 965 通常の場合、ユーザーは他の IdP からシングルサインオンによってローカルアカウントを使用する 966 ため、一部のローカルクレデンシャルが一定期間中に使用されない可能性があります。そのため、 967 ユーザーのローカルクレデンシャルの増加を制御する手段として、アイデンティティ連携時と、そ 968 れらを使用せずに Web サイトを一定の回数訪問した後に、ユーザーにローカルクレデンシャルを 969 無効にするオプションを提供するなどが考えられます。 970 971 5.4.1.1 グローバルアカウント/アイデンティティ名前空間が不要 972 973 ユーザーがさまざまな IdP および SP でアイデンティティを連携させることを選択できる上 974 記のアーキテクチャがあれば、すべての関係者を網羅するグローバル名前空間は必要あり 975 ません。トラストサークルのメンバーは、ユーザーがローカルアイデンティティ間に特定 976 の連携を作成し、その連携にポリシーを設定した場合に限り、ユーザーに代わって相互に 977 情報を伝えることができます。IdP と SP の長い連鎖を作成することはできますが、ユーザ 978 ーのアイデンティティが連鎖内のそれぞれのリンクで連携されるため、連鎖のすべての要 979 素でそのユーザーのグローバルに一意なアイデンティティが存在する必要がなくなります。 980 図 17 を参照してください。 981 982 5.4.1.2 連携管理：連携の解除 983 984 ユーザーは、連携を終了、つまりアイデンティティ連携を解除することができます。 985 [LibertyProtSchema]および[LibertyBindProf]には、連携終了通知プロトコルと関連するプロフ 986 ァイルが規定されています。このプロトコルを使用して、SP が IdP との連携解除を開始し 987 たり、またはその逆を行うことができます。標準的なユーザー体験は、SP または IdP の Web 988 ページ上にある連携解除のリンクを選択することです。このリンクによって、他の特定の 989 IdP または SP に関する連携解除が開始されます。 990 991 IdP で連携解除が開始された場合、IdP はユーザーに代わって、IdP がユーザーアイデンティ 992 ティ情報を SP に提供できなくなり、SP の要求に応答できなくなったことを SP に伝えます。 993 994 SP で連携解除が開始された場合、SP はユーザーに代わって、今後、ユーザーアイデンティ 995 ティ情報を IdP から SP に提供しないよう、そして、今後 SP も IdP に何の要求もしないよ 996 う、ユーザーの指示があったことを IdP に伝えます。 997 998 999 ポリシー/セキュリティに関する注：連携解除に関して、いくつかの問題を検討しなければなりません。 1000 1001 1002 ・ユーザーは、アイデンティティ連携の解除が開始されるプロバイダで認証を受ける必要があり ます。 1003 1004 1005 ・プロバイダは、連携の解除を実行する前にユーザーに確認を求め、イベントとユーザーの認証 情報の適切な部分を記録する必要があります。 1006 1007 ・SP はある主体者の連携終了通知を開始したり受け取った後、連携終了通知を交換した IdP か 1008 らのアサーションに基づいて主体者が現在も SP にログインしているかどうかをチェックする 1009 ことが推奨されます。もしそうであれば、IdP のアサーションに基づくローカルセッション情 1010 報を無効にする必要があります。 1011 1012 ・もし連携終了通知を交換した IdP からのアサーションに基づかない主体者のローカルセッショ 1013 ン状態の情報を SP が持っているのであれば、SP はその情報を引き続き保持することができま 1014 す。 1015 1016 1017 ・もし主体者が引き続き同じ IdP とシングルサインオンセッションを開始したならば、SP は IdP の認証と同様に連携をリクエストする必要があります。 1018 1019 ・SP と IdP 間の契約における連携の失効と終了など、他の連携終了の手段も考えられます。 1020 1021 5.4.2 シングルサインオン 1022 1023 シングルサインオンは、ユーザーの IdP および SP のアイデンティティが連携されると有効 1024 になります。ユーザーから見ると、シングルサインオンは、ユーザーが IdP にログインし、 1025 再度サインオンすることなく提携する複数の SP を使用した場合に認識されます（図 18 を 1026 参照）。このような利便性は、該当する IdP と SP 間でユーザーのローカルアイデンティテ 1027 ィを連携することで得られます。5.4.1 に、基本的なシングルサインオンのユーザー体験を 1028 示します。 1029 1030 1031 Identity Provider Service Provider 1032 1033 1034 2. SP がユーザーを認識 1. ユーザーがログイン 1035 1036 1037 ユーザーエージェント 1038 1039 1040 図 18：ユーザーが IdP にログインして、SP に認識される 1041 1042 [LibertyBindProf]には、SAML（[SAMLBind]を参照）の「Browser/Artifact Profile」および 1043 「Browser/Post Profile」によるシングルサインオンが規定されています。 1044 1045 ポリシー/セキュリティに関する注：認証、シングルサインオン、クレデンシャルなどについて、いく 1046 つかの問題を検討する必要があります。 1047 1048 認証メカニズムはシングルサインオンと直交状態にある 1049 1050 シングルサインオンは、SP または IdP がユーザーが実際に認証されたことを別の SP または IdP に伝 1051 える手段です。ユーザーが最初に認証された手段は、認証メカニズムと呼ばれます。認証メカニズム 1052 の例には、ユーザー名とパスワード（HTTP 基本認証ではない）、証明書ベース（SSL や TLS など）、 1053 Kerberos があります。 1054 1055 IdP セッション状態のメンテナンス 1056 1057 IdP は主体者に対する認証状態情報を保持する必要があります。これは「ローカルセッション状態の 1058 保持」として知られ、ここでいう「ローカル」は「IdP にとってローカル」を意味します。Web ブラ 1059 ウザとして広く知られる HTTP ベース[RFC2616]のユーザーエージェントのコンテキストにおいて、 1060 ローカルセッション状態の保持を行うメカニズムはいくつか存在します。クッキーはそのメカニズム 1061 の１つで、[RFC2965]で規定されています。IdP はローカルセッション状態の情報をユーザーエージェ 1062 ントにマッピングし、IdP に対してシングルサインオン連携プロトコル[LibertyBindProf]を実行する SP 1063 に対し認証アサーションを発行するための土台とします。それに従い、主体者がユーザーエージェン 1064 トを使用し他の SP と対話したとき、その SP は IdP に対し<AuthnRequest>を送信します。IdP はその 1065 ユーザーエージェントにおけるローカルセッション状態の情報をチェックし、そのユーザーエージェ 1066 ントの IdP のセッションが現在でもアクティブであるとローカルセッション状態の情報が示している 1067 場合、SP に対して認証アサーションを含む<AuthnResponse>を返すこととなります。 1068 1069 クレデンシャル 1070 1071 クレデンシャルは、シングルサインオンシステムの様々な局面で信頼の源とされ、しばしばクレデン 1072 シャルが持ち主との信頼を確立するための基盤となります。クレデンシャルは、所有者のアイデンテ 1073 ィティなど、持ち主のセキュリティ関連の属性を表す場合があります。秘密暗号鍵などの特別な保護 1074 を必要とする機密なクレデンシャルは、権限のない漏洩から保護しなければなりません。一部のクレ 1075 デンシャルは、公開鍵の証明書のように共有されることを目的としています。 1076 1077 クレデンシャルは、アサーションを証明するために必要なデータの一般的な概念です。たとえば、パ 1078 スワードによる認証システムでは、ユーザー名とパスワードがクレデンシャルと見なされます。ただ 1079 し、クレデンシャルの使用は認証行為だけに限定されません。クレデンシャルは、認可の決定を行う 1080 際にも信頼されます。 1081 1082 上記のように、一部のクレデンシャルは機密にしなければなりません。ただし、一部のクレデンシャ 1083 ルは、機密にするだけでなく、整合性を保護して改ざんや偽造から保護しなければなりません。5.4.3.1 1084 で説明するアーティファクトのような他のクレデンシャルには、ノンスのプロパティを持たせる必要 1085 があります。ノンスは、通常はデータが動的に変化することを保証し、再実行攻撃を検出して防止す 1086 る目的で、プロトコルによって交換されたデータに含まれるランダムまたは繰り返し現れない値です。 1087 1088 認証タイプ、複数階層での認証 1089 1090 すべての認証アサーションは、クレデンシャルのクオリティを示す認証タイプと、それらを調べるた 1091 めのメカニズムを含んでいなければなりません。ユーザーの認証に使用されたり、トランザクション 1092 を認可するために提供されたりするクレデンシャルおよび/またはクレデンシャルを調べるための認 1093 証メカニズムは、トランザクションを完了させるだけの質を備えていない場合があります。 1094 1095 たとえば、ユーザーがユーザー名とパスワードを使用して IdP で認証を受けたとします。続いてユー 1096 ザーは、より強力な認証が必要な銀行預金の引き出しなどのトランザクションを実行しようとしたと 1097 します。この場合、ユーザーは、公開鍵証明書や誕生日や母方の旧姓といった補助的な情報など、よ 1098 り強力なアイデンティティのアサーションを示さなければなりません。この操作が再認証であり、全 1099 体的な機能は多層化された認証となります。多層化された認証を使用するかどうかは、SP におけるポ 1100 リシーの決定であり、SP の判断に委ねられます。あるいは、トラストサークルの契約上の取り決めの 1101 一部として確立される場合もあります。この場合、トラストサークルのメンバーは、さまざまな認証 1102 タイプや、相互の認証アサーションに対する信頼について契約を交わすことができます。そのような 1103 契 約 は 、 現 在 の 証 明 書 運 用 規 定 （ CPS ） の よ う な 形 態 に な り ま す （ た と え ば 、 1104 http://www.verisign.com/repository/cps20/cps20.pdf を参照）。このような文書には、以下の情報が含まれ 1105 ます。 1106 1107 ・クレデンシャル登録時のユーザーの識別方法 1108 ・クレデンシャルの更新頻度 1109 ・クレデンシャルの保存および保護方法（スマートカード、電話、ハードディスクドライ 1110 ブ上の暗号化ファイルなど） 1111 1112 注：現在の Liberty 仕様では、SP、IdP、およびユーザーエージェントがさまざまな方法を使用す 1113 る認証をサポートできますが、関連するプロトコル交換は Liberty 文書に規定されていません。 1114 さらに、現在の Liberty 仕様には、IdP とユーザーエージェントとやりとりして、両者が共にサ 1115 ポートする方法を識別する手段が含まれていません。結果的に、Liberty 仕様のサポートは、そ 1116 れ自体で任意の方法を使用する任意の IdP とユーザーエージェント間の効率的な相互運用性を 1117 確保するほど十分ではないため、他のソースから入手したデータで補完しなければなりません。 1118 1119 また、現在の Liberty 仕様の範囲には、SP が IdP に質問する手段やユーザーが IdP に登録してい 1120 る認証プロファイルを決定するための手段が含まれていません。そのため、SP が特定のプロフ 1121 ァイルを効率的に選択して、特定のユーザーを認証するには、ユーザーの機能が記述された外の 1122 情報にアクセスする必要があります。 1123 1124 たとえば、トラストサークルのメンバーは、登録時に PKI 技術と、相応の文書を用いた面接によるユ 1125 ーザーアイデンティティ検証に基づく認証アサーションに、「強」のラベルを付けることに同意する 1126 場合があります。その後、これらのポリシーと手順を実装する IdP が指定された PKI ベースの認証メ 1127 カニズムを使用してユーザーがログインしたことを表明すると、SP がアサーションを一定の程度まで 1128 信頼します。この信頼の程度は、同じ PKI ベースの認証メカニズムを使用しながら、登録時に同じよ 1129 うな検査をユーザーに要求しない IdP がアサーションに含める程度とは異なってきます。 1130 1131 この問題には、誰が再認証を行うのか、あるいは IdP や SP がそれを実施するのかという側面もあり 1132 ます。この疑問は、実装および運用の問題であり、運用ポリシーの問題でもあります。実装および運 1133 用において、ビジネス上の要件（つまり運用ポリシー）に指定する場合に、IdP または SP で再認証を 1134 行うことをサポートする必要があります。たとえば、トラストサークルでは、特定の高額の取引で IdP 1135 が再認証を行うにはリスク要因が大きすぎ、取引のリスクを引き受ける SP が再認証を行うべきと判 1136 断される可能性があります。 1137 1138 相互認証 1139 1140 認証タイプと質の空間のもう 1 つの側面に、相互認証があります。IdP で認証を受けるユーザーにとって、 1141 相互認証は、IdP のサーバー自体がユーザーを認証し、またその逆を行うことを意味します。相互認証は、 1142 特定の認証メカニズムの機能です。たとえば、SSL または TLS ではデフォルトでサーバーがクライアント 1143 に対して認証されるため、SSL または TLS で実行されるユーザー認証は相互認証です。この機能は、ある 1144 程度の保証の基盤になりますが、いくつかの脆弱性を含んでいます。サーバーが偽の証明書を使用する可 1145 能性や、ユーザーが適切に検査したり重要性を理解することができない可能性があります。 1146 有効性の検証 1147 1148 有効性は、時刻 t0 に認証を受けたユーザーが時刻 t1 に一定の操作を実行しようとするユーザーと同 1149 じかどうかに関連します。たとえば、ユーザーがログインしてさまざまな操作を実行し、SP が高額と 1150 判断する一定の操作を実行しようとするかもしれません。SP は再認証を開始して、システムを操作し 1151 ているユーザーが最初に認証したユーザーと同じかどうかを検証しようとします。そのような手法に 1152 は多くの脆弱性が存在する、つまり悪意のあるユーザーの場合は完全に失敗するとしても、少なくと 1153 も SP の監査証跡は増加します。そのため、少なくとも一部の SP はこれを実施することを要望します。 1154 1155 IdP からの認証アサーションには、<ReauthenticationOnOrAfter>要素が含まれます。この属性が指定さ 1156 れ、ユーザーの要求時刻が指定された再認証の時刻を過ぎている場合、SP は再認証のためにユーザー 1157 を IdP にリダイレクトする必要があります。 1158 1159 通信セキュリティ 1160 1161 SP は、さまざまな理由で IdP との通信を拒否することができます。たとえば、SP のポリシーとして、 1162 クレデンシャルの持ち主とのあらゆるプロトコル交換を双方向の認証、完全性の保護、メッセージの 1163 機密性などの一定の質を満たす通信プロトコルで開始することを要求する場合があります。 1164 1165 1166 5.4.3 シングルサインオンおよび連携プロトコルのプロファイル 1167 [LibertyProtSchema]に規定されたシングルサインオンおよび連携プロトコルには、SP と IdP 1168 間で交換されるメッセージが定義されています。これらのメッセージの特定の転送（HTTP 1169 など）とメッセージ（SOAP）プロトコルへの具体的なマッピングと、正確なプロトコルフ 1170 ローは、[LibertyBindProf]に規定されています。これらのマッピングは、プロファイルと呼 1171 ばれます。シングルサインオンおよび連携プロトコルには、４つのプロファイルが規定さ 1172 れています。以下の節に、それぞれのプロファイルをまとめます。これらのプロファイル 1173 に共通するやりとりとプロファイルの処理ルールに関する議論と、各プロファイルの詳細 1174 については、[LibertyBindProf]を参照してください。 1175 1176 テクニカルノート：シングルサインオンおよび連携プロトコルと関連するプロファイルには、SP が採 1177 用したい特定のプロファイルを IdP に示す手段が規定されています。主な手段は、シングルサインオ 1178 ンおよび連携プロトコルのすべてのプロファイルで採用される<lib:AuthnRequest>メッセージの 1179 <lib:ProtocolProfile>要素です。注：Liberty 対応クライアントおよびプロキシのプロファイルでは、別 1180 の手段も採用されます。 1181 1182 5.4.3.1 Liberty ブラウザのアーティファクトプロファイル 1183 1184 Liberty ブラウザのアーティファクトプロファイルでは、Web リダイレクトによって 1185 IdP と SP 間で交換される URI へのアーティファクトの埋め込みが規定され、さらに SP と 1186 IdP 間の直接通信が必要となります。アーティファクト自体は、SP が IdP に照会して完全な 1187 SAML アサーションを受け取ることのできる特定困難なユーザーハンドルです。この方式 1188 の目的は、アーティファクトが URI エンコードされたフォーム内で小さくなるため、サイ 1189 ズ制限を心配することなく URI に適合することです。アーティファクトには、一度しか使 1190 用されない不透明かつ擬似的にランダムなノンスのプロパティがあります。これらのプロ 1191 パティは、再実行攻撃への対応策です。ランダムなプロパティのため、アーティファクト 1192 が敵から推測されなくなります。 1193 1194 5.4.3.2 Liberty ブラウザの POST プロファイル 1195 1196 JavaScript や ECMAscript をサポートする最近のブラウザは、自動的にフォームをポストす 1197 る JavaScript や ECMAscript データを含むフォーム要素のある HTML ページを送信して、リ 1198 ダイレクトを実行できます。古いブラウザや、スクリプトを無効にしたブラウザでは、URI 1199 内にデータを埋め込む必要があります。 1200 1201 Liberty ブラウザの POST プロファイルは、フォーム POST によるリダイレクト（5.1.2 を参照） 1202 ごとに HTTP フォーム内にアサーションを埋め込みます。その結果、このプロファイルでは、ア 1203 サーションを取得するために SP と IdP 間で直接通信する必要がありません。HTML フォームを 1204 使用することで、URL に比べて、サイズ制限が大きくなるため、完全な認証アサーションを含 1205 めることができます。図 19 を参照してください。 1206 1207 <HTML> 1208 <BODY ONLOAD="javascript:document.forms[0].submit()"> 1209 <FORM METHOD="POST" ACTION="www.foobar.com/auth"> 1210 <INPUT TYPE="HIDDEN" NAME="FOO" VALUE="1234"/> 1211 </FORM> 1212 </BODY> 1213 </HTML> 1214 1215 図 19：JavaScript を使用した非表示フィールドを含む HTML フォームの自動送信の 1216 例 1217 1218 テクニカルノート：JavaScript（または ECMAscript）への依存性のため、Liberty ブラウザの POST プ 1219 ロファイルは、Liberty ブラウザのアーティファクトプロファイルを補う意味でのみサポートします。 1220 1221 ポリシー/セキュリティに関する注：実装者および運用者は、認証アサーションの該当する部分を記録 1222 する必要があります。 1223 1224 5.4.3.3 Liberty WML の POST プロファイル 1225 1226 Liberty WML の POST プロファイルは、WML イベントに依存して、WML ブラウザに HTTP 1227 フォームの送信を命令します。WML ブラウザは、携帯端末で一般的です。そのような携帯 1228 端末のブラウザは、専用のプロキシである WAP ゲートウェイを経由して通信します。この 1229 プロキシは、端末のワイヤレスセッションプロトコル（Wireless Session Protocol）を HTTP 1230 に変換します。注：SP および IdP は、HTTP のみを使用して情報をやりとりします。 1231 1232 テクニカルノート：このプロファイルと Liberty ブラウザの POST プロファイルの主な違いは、SP お 1233 よび IdP からユーザーエージェントへの特定の応答に、HTML ではなく WML が含まれることです。 1234 1235 このプロファイルと Liberty 対応のクライアントやプロキシプロファイルの違いは、このプロファイ 1236 ルが標準的な無修正の WML ブラウザに対応するように設計されている一方で、Liberty 対応クライア 1237 ントおよびプロキシのプロファイルが Liberty プロトコルの機能を組み込んだブラウザおよび/または 1238 プロキシを想定していることです。 1239 1240 5.4.3.4 Liberty 対応クライアントおよびプロキシのプロファイル 1241 1242 Liberty 対応クライアントおよびプロキシのプロファイルでは、Liberty 対応クライアントお 1243 よび/またはプロキシ、SP、IdP 間のやりとりが規定されます。Liberty 対応クライアントは、 1244 ユーザーが SP で使用する IdP を認識しているか、または認識する方法を知っているクライ 1245 アントです。また、Liberty 対応クライアントは、HTTP リダイレクトに依存したり、URL 1246 にプロトコルパラメータをエンコードしたりするのではなく、POST を使用して HTTP リク 1247 エストおよび応答の本体で Liberty メッセージを送受信します。そのため、Liberty 対応クラ 1248 イアントには、Liberty プロトコルメッセージのサイズ制限がありません。 1249 1250 Liberty 対応プロキシは、Liberty 対応クライアントをエミュレートする HTTP プロキシ（通 1251 常は WAP ゲートウェイ）です。 1252 1253 テクニカルノート：このプロファイルと他の Liberty POST によるプロファイルの違いは、以下のとお 1254 りです。 1255 ・HTTP リダイレクトに依存しません。 1256 ・ユーザーエージェントと IdP 間のやりとりが SOAP ベースです。 1257 ・Liberty 対応クライアントおよびプロキシのプロファイルには、IdP と SP に Liberty 対応である 1258 ことを知らせ、Liberty に対応しない一般のユーザーエージェントでサポートされない機能も 1259 サポートできることを伝えるために、送信されるプロトコルメッセージに Liberty で規定した 1260 HTTP ヘッダーを含みます。 1261 1262 1263 5.4.3.5 シングルサインオンプロトコルのフローの例：Liberty ブラウザのアー ティファクトプロファイル 1264 1265 Liberty ブラウザのアーティファクトプロファイルにおけるシングルサインオンの第 1 段階 1266 は、ユーザーが SP を訪問して、ユーザーの好みの IdP を選択してログインすることです。 1267 このログインは、SP のログインページに表示される一覧から好みの IdP を選択することで 1268 実行されます。 1269 1270 テクニカルノート：SP は、5.5 節で説明する IdP イントロダクションメカニズムや、 1271 Liberty 対応クライアントまたはプロキシがあれば、実装依存の手段および仕様で規定 1272 されていない手段で、好みの IdP を検出しても良い。 1273 1274 ユーザーが IdP を選択すると、発信元の SP を示すパラメータが埋め込まれた状態で、ユー 1275 ザーのブラウザが IdP にリダイレクトされます。ユーザーは、通常どおりの方法で IdP にロ 1276 グインできます。図 20 を参照してください。 1277 1278 1279 Identity Provider Service Provider 2. SP が IdP に対する HTTP 1280 リダイレクトまたはフォー 1281 1282 3. ユーザーが IdP にリダイレクト 1283 され、ログインする ム Post を使用する 1. ユーザーがログインオプションとして IdP を選択する 1284 1285 1286 ユーザー 1287 1288 図 20：HTTP リダイレクトまたはフォーム POST を使用したシングルサインオン（1/2） 1289 1290 IdP は通常どおりログインを処理し、ログインが完了すると、アーティファクトと呼ばれる 1291 暗号化された一時的なクレデンシャルを URI に埋め込んで、ユーザーのブラウザを発信元 1292 の SP にリダイレクトします。SP は URI のアーティファクトを解析し、直接使用して、IdP 1293 にユーザーを照会します。応答で IdP がユーザーを保証し、SP がローカルな意味でのセッ 1294 ションの状態を確立します。図 21 を参照してください。 1295 1296 7. SP が IdP にユーザーを照会する 1297 1298 Identity Provider 1299 1300 1301 Service Provider 4. IdP がログインを処理する 1302 1303 1304 5. IdP が URL または Post にクレデ 1305 ンシャルを埋め込んで、SP にリダ 1306 イレクトする 6. SP が HTTP リダイレクトを受け取 り、URL または Post からクレデンシ ユーザー ャルを解析する 1307 1308 1309 図 21：HTTP リダイレクトまたはフォーム POST を使用したシングルサインオン（2/2） 1310 1311 5.5 IdP イントロダクション 1312 1313 複数の IdP が存在するトラストサークルでは、ユーザーがどの IdP を使用しているかを SP 1314 が確認するための手段が必要となります。本来は、SP が読み取れるクッキーを IdP が書き 1315 込めることが理想的です。しかし、クッキーには 5.1.3 で説明した制約が存在するため、あ 1316 る DNS ドメインの IdP が別の DNS ドメインの SP で読み取り可能なクッキーを書き込むた 1317 めの標準的な手段がありません。 1318 1319 このイントロダクションの問題の解決策は、AirlineAffinityGroup.inc や AAG.inc のような、 1320 該当するトラストサークルに共通するドメインを使用して、すべての参加者がアクセスで 1321 きるようにすることです。この DNS ドメイン内のエントリは、系列グループのそれぞれの 1322 メンバーが指定する IP アドレスをポイントします。たとえば、SP である CarRental.inc は、 1323 自身の指定する IP アドレスをポイントするサードレベルドメインの「CarRental.AAG.inc」 1324 を取得します。この共通ドメインサービスをホスティングするコンピュータは、状態を保 1325 持しません。それらは、リダイレクト URL 内で渡されるパラメータに基づいて、クッキー 1326 の読み取りと書き込みだけを行います。これは[LibertyBindProf]3.6.2 において、共通クッキ 1327 ーの設定方法として提案されているいくつかの手法のうちの１つです。 1328 1329 ユーザーが IdP に認証を行うと、IdP はユーザーがその IdP を使用していることを示すパラ 1330 メータを付けて、ユーザーのブラウザを IdP の共通ドメインサービスのインスタンスにリダ 1331 イレクトします。共通ドメインサービスは、クッキーにその設定を書き込み、ユーザーの 1332 ブラウザを再び IdP にリダイレクトします。その後、ユーザーはトラストサークル内の SP 1333 にサイトを変更することができます。図 22 を参照してください。 1334 1335 「AAG」...「AirlineAffinityGroup」 1336 1337 Identity 1338 Provider 1339 Airline.inc 1340 Airline.AAG.inc Service Provider CarRental.inc CarRental.AAG.inc 2. 共通ドメインサー ビスがクッキーを書 1341 1. ユーザーが IdP にログイ 1342 ンし、IdP がユーザーエージ 3. ユーザーが SP 1343 ェントを共通ドメインにリ にサイトを変更す 1344 ダイレクトする る 1345 1346 き込む ユーザーエージェント 図 22：共通ドメインを利用したイントロダクションの推進（1/2） 1347 1348 ユーザーがトラストサークル内の SP にサイトを変更すると、SP はユーザーのブラウザを共 1349 通ドメインサービスのインスタンスにリダイレクトします。共通ドメインサービスがクッ 1350 キーを読み取って、ユーザーの IdP を URL に埋め込んだ状態でユーザーのブラウザを再び 1351 SP にリダイレクトし、そして SP の DNS ドメイン内で SP のシステムが稼働できるように 1352 なります。図 23 を参照してください。 1353 1354 「AAG」...「AirlineAffinityGroup」 1355 Airline.AAG.inc Service 1356 Identity Provider 1357 Provider CarRental.inc 1358 Airline.inc 1359 1360 1361 1362 1363 CarRental.AAG.inc 4. SP が共通ドメインサービスにリダイレク 5. 共通ドメインサービスが URL に トし、共通ドメインサービスがクッキーから IdP の一覧を埋め込み、ユーザーエー IdP の一覧を読み取る ジェントを再度 SP にリダイレクトす る 1364 1365 ユーザーエージェント 6. SP が、その IdP を経由してログインす 1366 るかどうかを確認する画面をユーザーに 1367 表示する 1368 1369 図 23：共通ドメインを利用したイントロダクションの推進（2/2） 1370 1371 1372 この時点で、SP はユーザーがトラストサークル内のどの IdP に認証を行ったかを把握し、 1373 ユーザーの代理を務めるその IdP と共に、シングルサインオンなどの Liberty プロトコルの 1374 運用を進めることができます。 1375 1376 ポリシー/セキュリティに関する注： 1377 1378 共通ドメインクッキーの影響 1379 1380 IdP は、セッションごとの共通ドメインクッキー（たとえば、そのセッション限定のもの、実際には 1381 非常に持続期間が短いもの、[RFC2965]を参照）または永続的な共通ドメインクッキーのどちらかを 1382 生成します。セッションクッキーとは、ユーザーがログアウトするか（このログアウトは明示的に実 1383 装されるべきであるけれども）、またはユーザーエージェントを終了すると、ユーザーエージェント 1384 のクッキーキャッシュから消去されるものを指します。一部のユーザーにとって、この機能は不便で 1385 す。ただし、セッションクッキーと永続的なクッキーのどちらを使用するかは、「保存しますか」と 1386 いうチェックボックスの形式で IdP へのログイン時にユーザーに表示されます。チェックしない場合 1387 はセッションクッキーが使用され、チェックすると永続的なクッキーが使用されます。 1388 1389 ユーザーのセキュリティ面における永続的なクッキーの影響は、別のユーザーがそのコンピュータを 1390 使用すると、すでにユーザーエージェントが終了されていても永続的な共通ドメインクッキーが残る 1391 ことです。実際、すべての永続的なクッキーが残ります。5.1.3.のポリシー/セキュリティに関する注 1392 を参照してください。 1393 1394 しかし、共通ドメインクッキーに含まれる情報が IdP の一覧だけであれば、つまり個人識別情報や認 1395 証情報が含まれなければ、ユーザーの不注意で情報が漏洩するセキュリティリスクは低く抑えられま 1396 す。 1397 1398 共通ドメインクッキーの取り扱い 1399 1400 共通ドメインクッキーの書き込みサービスで共通ドメインクッキーを取り扱う方法は、 1401 [LibertyBindProf]の 3.6.2 に規定されています。ユーザーが最近に認証した IdP は、クッキーの IdP 一 1402 覧の最後に記載されます。ただし、SP が共通ドメインクッキーを解釈し、ユーザーに選択肢を表示す 1403 る方法については規定されていません。これが指定されていないため、各 SP がさまざまな方法で表 1404 示する可能性があります。1 つには、共通ドメインクッキーと逆の順序で IdP の一覧を表示する方法 1405 があります。この方法では、共通ドメインクッキーの書き込みサービスが上記のガイドラインに準拠 1406 している場合、SP は最近使用された順に IdP を表示します。または、一覧の最後に記載された IdP だ 1407 けを表示します。あるいは、何らかの理由から、別の順序で IdP を表示します。 1408 1409 5.6 シングルログアウト 1410 1411 シングルログアウトプロトコルおよび関連するプロファイルは、特定の IdP によって認証さ 1412 れたすべてのセッションでセッションのログアウト機能と同期します。シングルログアウ 1413 トは、IdP（図 24 を参照）または SP（図 25 を参照）のいずれかで開始されます。どちらの 1414 場合でも、IdP はその後、ユーザーのためにセッションを確立したそれぞれの SP にログア 1415 ウトを通知します。 1416 1417 ポリシー/セキュリティに関する注：シングルサインオンシステムを採用する場合、ユーザーが SP で 1418 ログアウトする際に、IdP からログアウトするのか、あるいはその SP だけからログアウトするのかに 1419 ついて、ユーザーが予測できるようにすることが重要です。Web サイトにはシングルログアウトおよ 1420 びサイトログアウトの両方のボタンまたはリンクを表示して、ユーザーが予測できるようにしなけれ 1421 ばなりません。ただし、サイトログアウトは、ユーザーが以前にシングルサインオンに関連付けたサ 1422 イトで現在の認証アサーションを使用するような積極的な行動をとる必要がある場合にだけ役に立 1423 つものと考えられます。 1424 1425 2. IdP が SP A からユーザーをログアウト 3. IdP が SP B からユーザーをログアウト 1426 1427 1428 1429 Service Provider A Identity Provider Service Provider B 1430 1431 1432 1433 1434 1435 1. ユーザーがログアウト 1436 1437 1438 1439 ユーザー 1440 1441 1442 1443 図 24： IdP からのシングルログアウト 1444 1445 1446 1447 2. SP A が IdP にユーザーの 3. IdP が SP B からユーザーを ログアウトを通知 ログアウト 1448 1449 1450 Service Provider A Identity Provider Service Provider B 1451 1452 1453 1454 1455 1456 1457 1458 1. ユーザーがグローバルに 1459 ログアウト 1460 1461 ユーザー 1462 1463 1464 図 25：SP からのシングルログアウト 1465 1466 5.6.1 シングルログアウトのプロファイル 1467 1468 [LibertyBindProf]には、SP と IdP 間でログアウトを通知するための以下の 3 つの全般的なプ 1469 ロファイルが指定されています。 1470 1471 ・HTTP リダイレクトによるもの：HTTP 302 リダイレクトの使用に依存 1472 ・HTTP GET によるもの：IMG タグの HTTP GET リクエストの使用に依存 1473 ・SOAP/HTTP によるもの：HTTP メッセージによる非同期 SOAP に依存 1474 1475 IdP では、これらの 3 つのプロファイルすべてが開始されます。SP では、1 つ目および 3 つ 1476 目だけが開始されます。詳細については、[LibertyBindProf]を参照してください。 1477 1478 テクニカルノート：ユーザーが認識できるログアウトプロファイルの大きな違いは、HTTP リダイレ 1479 クトおよび SOAP/HTTP によるプロファイルを使用した場合には、ログアウトプロセスが実行される 1480 とユーザーがログアウトプロセスを開始した時の Web ページがそのまま表示され続ける（すなわち各 1481 SP に順番にログアウトが通知されている）のに対し、HTTP-GET によるプロファイルを使用した場合 1482 には、IdP がログアウト処理の進行に合わせて（SP ごとに１つの完了チェックマークなどのように） 1483 画像をリロードすることでユーザーに進捗を報告することもできることです。 1484 1485 5.7 ユーザー体験のシナリオ例 1486 1487 この節では、Liberty Version 1.0 アーキテクチャの連携、イントロダクション、およびシング 1488 ルサインオンの側面に基づき、いくつかのユーザー体験のシナリオ例を紹介します。目的 1489 は、ログイン時のユーザー体験のより微妙な側面を明らかにし、ユーザーのクレデンシャ 1490 ルを要求、収集する際に使用される可能性がある共通の Web 専用のユーザーインターフェ 1491 ース技術について説明することです。特有のポリシーおよびセキュリティ要素に注意して 1492 ください。 1493 1494 5.7.1 シナリオ：いずれにもログインしていない、共通ドメインクッキーなし 1495 1496 このシナリオでは、Joe Self はいずれの Web サイトにもログインしていなく、共通ドメイン 1497 クッキーも持たない（たとえば、ユーザーエージェントを再起動したり、クッキーのキャ 1498 ッシュを消去した）状態で、最初に IdP の Airline.inc を訪問せずに CarRental.inc に接続して 1499 います。 http://www.CarRental.inc/ CarRental.inc “Proud Member of the Airline.inc Affinity Group” ようこそ。まずログインしてくだ さい。当社のIdPの一覧は以下のと おりです。 • Airline.inc • CarRental.inc • Hotel.inc • Bank.inc ユーザー CarRental.inc (Joe Self) 1500 1501 図 26：認証を受けた証拠や共通ドメインクッキーを持たずに、ユーザーが SP の Web サイトを訪問する 1502 1503 CarRental.inc が、IdP の選択肢を記載した Welcome ページを Joe Self に表示します（図 26 を 1504 参照）。Joe Self が、リストから Airline.inc を選択します。 1505 1506 5.7.1.1 から 5.7.1.3 までの節では、CarRental.inc が Airline.inc と共同で Joe Self のログインを 1507 進めるために使用する以下の 3 種類の Web 特有のユーザーインターフェース技術について 1508 説明します。 1509 1510 ・IdP の Web サイトへのリダイレクト 1511 ・IdP のダイアログボックス 1512 ・埋め込まれたフォーム 1513 1514 テクニカルノート：これらのユーザーインターフェース技術は、Web を使用したシステムに一般的に 1515 採用されています。Liberty に固有ではなく、Liberty が指定するものでもありません。これらは、例を 1516 示す目的でのみ記載されています。 1517 1518 5.7.1.1 IdP の Web サイトへのリダイレクトによるログイン 1519 1520 IdP の Web サイトへのリダイレクトによるログインの場合、SP は（大部分の場合はリダイ 1521 レクトによって）IdP の適切なログインページへ直接リンクします。Joe Self のブラウザに 1522 IdP の Web ページが表示され（図 27 を参照） 、ログインが正常に完了すると、ブラウザが 1523 SP の Web サイトに再びリダイレクトされ、Joe Self は SP のサイトにアクセスできます（図 1524 30 を参照）。 http://www.Airline.inc/login/ Airline.inc Airline.inc ようこそ。CarRental.inc経由の訪問を 確認しました。ログインしてください。 JoeS: 認証済 アイデンティティ連携： はい CarRental.inc Joe123 “Proud Home of the Airline.inc Affinity Group” ログイン: JoeS パスワード: xxxx 直接 CarRental.inc にリダイレクトし ます。 CarRental.inc ユーザー (Joe Self) リダイレクト先: http://www.Airline.inc/login/ 1525 1526 図 27：SP が IdP のログインページにリダイレクト 1527 1528 ポリシー/セキュリティに関する注：ユーザーがクレデンシャルを直接 IdP に提示するため、IdP の 1529 Web サイトへのリダイレクトによるログインは比較的安全です。当然、ログインおよび認証イベント 1530 に伴う通常のセキュリティに対する考慮が適用されます。 1531 1532 5.7.1.2 IdP のダイアログボックスによるログイン 1533 1534 IdP のダイアログボックスでログインする場合、SP の Web ページに記載されたリンクをク 1535 リックすると、ダイアログまたはポップアップボックスが呼び出されます。Joe Self のブラ 1536 ウザに IdP のポップアップが表示され（図 28 を参照）、ログインが正常に完了すると、ポッ 1537 プアップボックスが閉じ、Joe Self は SP のサイトにアクセスできます（図 30 を参照）。 1538 1539 1540 http://www.CarRental.inc/ CarRental.inc “Proud Member of the Airline.inc Affinity Group” http://www.Airline.inc/loginPopup/ http://www.Airline.inc/loginPopup/ ようこそ。まずログインしてくだ Airline.inc さい。当社のIdPの一覧は以下のと “Proud “Proud Home of the おりです。 Airline.inc Affinity Group” Airline.inc • Airline.inc よう ようこ こそ。CarRental.inc経由の訪問を確認 そ。CarRental.inc経由の訪問を確認 • CarRental.inc しました。ログインしてください。 しました。ログインしてください。 • Hotel.inc ログイン: JoeS • Bank.inc パスワード: xxxx ユーザー (Joe Self) JoeS: 認証済 アイデンティティ連携: はい CarRental.inc Joe123 CarRental.inc 1541 1542 図 28：SP が IdP のダイアログまたはポップアップボックスを呼び出す 1543 1544 ポリシー/セキュリティに関する注：ユーザーがクレデンシャルを直接 IdP に提示するため、IdP から 1545 のダイアログボックスによるログインは比較的安全です。当然、ログインおよび認証イベントに伴う 1546 通常のセキュリティ要素に対する考慮が適用されます。 1547 1548 5.7.1.3 埋め込まれたフォームによるログイン 1549 1550 埋め込まれたフォームによるログインの場合、SP の Web ページに記載されたリンクをクリ 1551 ックすると、SP は埋め込まれたログインフォームを表示します。つまり、表示されるペー 1552 ジは SP からのものですが、Joe Self が Submit ボタンをクリックすると、 通常その情報は POST 1553 によって IdP に伝達されます（図 29 を参照）。Joe Self には、SP の Web ページから離れて 1554 いないように見えます。ログインが正常に完了すると、Joe Self は SP の Web サイトにアク 1555 セスできます（図 30 を参照）。 http://www.CarRental.inc/AirlineLogin/ CarRental.inc Airline.inc “Proud Member of the Airline.inc Affinity Group” JoeS: 認証済 アイデンティティ連携: はい CarRental.inc Joe123 ようこそ。以下に、Airline.incのクレデ ンシャルを入力してください。 JoeS ログイン: パスワード: xxxx フォーム POST ユーザー CarRental.inc (Joe Self) 1556 1557 図 29：埋め込まれたフォームによるログイン 1558 1559 ポリシー/セキュリティに関する注： ユーザーはこの埋め込まれたフォームのメカニズムのシームレ 1560 ス性を好み、サイト運営者はユーザーが運営者の Web サイトから離れない点を好むかもしれませんが、 1561 これにはポリシーおよびセキュリティ上の重大な問題があります。このメカニズムでは、ユーザーが 1562 IdP のクレデンシャルを平文のままで SP に提供します。そのため、ユーザーの IdP アカウントに関わ 1563 るプライバシーが損なわれます。さらに、悪意のある SP がそれらのクレデンシャルを使用してユー 1564 ザーになりすますことができます。そのため、埋め込まれたフォームによる認証を採用する場合、運 1565 営者は IdP と SP 間でこのリスクに対処するための適切な契約条件を検討する必要があります。 1566 1567 5.7.1.4 ユーザーが CarRental.inc にログイン 1568 1569 次に CarRental.inc と Airline.inc が共同でログインを進め、CarRental.inc の Web サイトが 1570 Airline.inc との Joe Self のアイデンティティ連携に基づいてセッションを確立します（図 30 1571 を参照）。 CarRental.inc “Proud Member of the Airline.inc Affinity Group” Joe123さん、ようこそ。サインオンは 完了しています。 Airline.inc JoeS: 認証済 アイデンティティ連携: はい CarRental.inc Joe123 以下からサービスを選択してください。 • 車を予約する. • Airline.inc のマイルを確認する • その他 ユーザー (Joe Self) CarRental.inc Joe123: 認証済 アイデンティティ連携: はい Airline.inc JoeS 1572 1573 図 30：SP の Web サイトがアイデンティティ連携に基づいてサービスを提供 1574 1575 5.7.2 シナリオ：いずれにもログインしていない、共通ドメインクッキーあり 1576 1577 このシナリオは、上記のシナリオとほぼ同じです。唯一異なる点は、すでに Joe Self のブラ 1578 ウザに共通ドメインクッキーがキャッシュされていることです。したがって、CarRental.inc 1579 の Web ページを訪問すると、CarRental.inc は Joe Self がどの IdP と提携しているか（この場 1580 合は Airline.inc）を即座に把握します。CarRental.inc は、上記の例で説明した 3 種類のメカ 1581 ニズムのいずれかによって即座にログインを進めるか、または先にユーザーに確認する画 1582 面を表示します。 1583 1584 ポリシー/セキュリティに関する注：実装者および運営者は、即座に IdP に認証するのか、それとも、 1585 取り消して SP にローカル認証したり、SP の提携する IdP の一覧から選択したりするのかをユーザー 1586 が判断することを考慮に入れておかなければなりません。 1587 1588 5.7.3 シナリオ：ログイン済み、共通ドメインクッキーあり 1589 1590 1591 このシナリオについては、2.2 で説明しました。 1592 6 参考文献 1593 [LibertyArchImpl] Kannappan, L., “Liberty Architecture Implementation Guidelines.” 1594 [LibertyAuthnContext] Madsen, P., “Liberty Authentication Context Specification.” 1595 [LibertyBindProf] Rouault, J., “Liberty Bindings and Profiles Specification.” 1596 [LibertyGloss] Mauldin, H., “Liberty Glossary.” 1597 [LibertyProtSchema] Beatty, J., “Liberty Protocols and Schemas Specification.” 1598 [RFC1738] “Uniform Resource Locators (URL),” 1599 1600 http://www.ietf.org/rfc/rfc1738.txt [RFC2119] S. Bradner, “Key words for use in RFCs to Indicate Requirement 1601 Levels,” http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1602 1997. 1603 [RFC2246] “The TLS Protocol Version 1.0,” http://www.ietf.org/rfcs/rfc2246.html. 1604 [RFC2396] “Uniform Resource Identifiers (URI): Generic Syntax,” 1605 1606 http://www.ietf.org/rfc/rfc2396.txt. [RFC2616] 1607 “Hypertext Transfer Protocol — HTTP/1.1,” http://www.ietf.org/rfc/rfc2616.txt. 1608 [RFC2617] “HTTP Authentication,” http://www.ietf.org/rfc/rfc2617.txt. 1609 [RFC2965] “HTTP State Management Mechanism,” 1610 1611 http://www.ietf.org/rfc/rfc2965.txt. [SAMLBind] P. Mishra et al., “Bindings and Profiles for the OASIS Security 1612 Assertion Markup Language (SAML),” 1613 http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings- 1614 model-11.pdf, OASIS, January 2002. 1615 [SOAP1.1] D. Box et al., “Simple Object Access Protocol (SOAP) 1.1,” 1616 http://www.w3.org/TR/SOAP, World Wide Web Consortium Note, 1617 May 2000. 1618 [SSLv3] “The SSL Protocol 1619 http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt. Version 3.0,”