3 認証技術の標準化動向
3.5. シングルサインオンシングルサインオン（SSO）
3.5.2 Liberty Alliance Project
シの漏洩やService Providerが利用者のプライバシ情報を再利用することがで きない仕組みを提供する。
・Libertyの機能
Libertyでは以下の機能を提供する
・本人性連携（Federated Identity）
・認証（SSO）
・グローバルログアウト
ここでは信頼の輪として合意したIdentity ProviderであるAirline.Incと Service ProviderであるCarRebtal.Inc及びHotel.Incがそれぞれ独自に異な る利用者のアカウントを管理しているとする。通常利用者はそれぞれのサイト に個別にログインしなければならない。Libertyではこれらのサイトの独立性 を保ちながらサイト間で本人性を連携させSSOを実現させる。それぞれのロ ーカルに管理しているアカウント情報はサイト間で共有することなく、本人性 を確認するためのハンドルのみを交換する。このことを実現するためにはまず、
利用者が本人性の連携のために上記の３つのProvider間で連携に同意するこ とから始まる。これが本人性の連携である。連携に同意した利用者はいつでも 連携を破棄することもできる。一旦連携が成立すると利用者はIdentity Providerにログインすることで３つのProvider間のSSOが可能になる。一連 のサービスの提供が終了したら、利用者はグローバルログアウトすることで SSOを終了する。
(1) 本人性連携
利用者がIdentity ProviderであるAirline.Incのサイトにローカルなアカウ ントでログインすると、Airline.IncのページでAirlineグループの信頼の輪の 中にあるサービスを提供するCarRentalやHotel.Incなど各サービスに利用者 を紹介していいかと聞いてくる。利用者が同意するとAirline.Incから
CarRental.Incのページにリダイレクトされ、ここで利用者はCarRentalのロ ーカルなログインを促される。ログインするとAireline.Incと連携するかと聞 いてくる。利用者がYesと答えるとCarRental.IncとAirline.Incの連携が成 立する（図 3-33参照)。同様に利用者が望めばHotel.Incとの連携を可能にす
る。ここで各Providerへのログインはそれぞれローカルなアカウントで行われ、
このローカルなアカウントは全体でユニークな仮名とリンクされる。
信 頼 の 輪 （Circle of
Air
Car
連 携 し た メ ン バ
Hotel.Inc
Service P id
Rental.Inc
Service
line.Inc
Identity P id
図 3-33 信頼の輪と連携 (2) 認証（SSO）
本人性が連携されたのち、SSOの認証は様々なメカニズムで行うことができ る。すなわち、ID、パスワードベース、Kerberos、PKIベースなど認証の各種 のクラスを実装できる。これらのどれかを使うこともできるし、またこれらを 認証の強度の要求において使い分けることも可能である。通常はパスワードベ ースの認証を行い、高額な取引の場合にはPKIベースの認証を要求することも 可能である。
(3) グローバルログアウト
Libertyでは明示的なグローバルログアウトのメカニズムを用意している。
利用者がどこかのProbiderでログアウトするとこの情報は関係するProvider に通知され、SSOの認証関係は切断される。SAMLではこの明示的なグローバ ルログアウトのメカニズムを用意していないが、Libertyでは利用者の明示的 な意思でログアウトする仕掛けを導入した。
・Libertyアーキテクチャのコンポーネント
Libertyでは以下の３つのアーキテクチャのコンポーネントを用意してい
る。
・Webリダイレクション
・Webサービス
・メタデータとスキーマ
図 3-32に上記の関係を図示する。
Identity Provider
Users
Service
Provider Web サ ー ビ
メ タ デ ー タ ＆ ス キ ー
Web リダイレクショ
図 3‑ 32 Li ber t y アーキテクチャ
・Webリダイレクション
リダイレクションには以下の2つの方法が可能である。
HTTPリダイレクト
HTTPのGETによりURIを指定してリダイレクトする。URIの載せる パラメータのサイズの制限がある。
フォームPOSTリダイレクト
POSTのパラメータに任意のサイズのデータを含めることができる。
Cookieの使用制限
LibertyではProvider間の状態情報を維持するためにCookieは基本的 に用いない。2.6で述べたようにCookieはセキュリティ上の問題と、
Cookie情報の伝達にDNSドメインの制限がある。したがって、Liberty ではHTTPリダイレクトかPOSTによるリダイレクトに伝達情報を埋め 込みCookieは用いない。
・Webサービス
Identity ProviderとService Provider間ではSORP-RPC over HTTPによる Webサービスを用いた認証情報の連携がとられる。ここではSAMLによるコ ンテクストが交換される。
・メタデータとスキーマ
Identity ProviderとService Provider間では互いの連携に必要な情報を交換 する。ここでは、以下の情報の交換が行われる。
アカウント／本人性：実際の本人情報ではなく、これにリンクした利用者の 乱数に近いハンドルのみである
認証コンテクスト：各Providerは互いが連携するときに必要などのようなセ キュリティメカニズムを使用するかなど認証のクラスを合意する必要がある。
例えば通常の連携はパスワードであるが、高額取引はPKIの認証クラスを用い ることなどを選択できる。
このような通信やネゴシエーションのプロトコルとスキーマがLiberty仕様 で定められている。
3.5.3 .Net Passport
マイクロソフト.Net Passportは多くのWebサイトのサービスプロバイダー をSSOで連携させるマイクロソフト社独自の方式である。マイクロソフト社 は自身がIdentity Providerとなって.Net Passportのサービスを行っているが、
企業がこの技術を自分で実装することもできる。Liberty Allianceがこれから の仕組みを用意しようとするのに対して、.Net Passportは既に1999年からリ リースされ多くのユーザーがこれを利用している。
.Net Passportの提供するサービスは、大まかにはLibertyの提供しようとす るサービスと同等である。.Net Passportに参加するWebサイトは自身の独自 のアカウントを持ち、これを.Net Passportのアカウントと共有させるのでは なく、それぞれのアカウントと64ビットの無意味なユニークなID（PUID： Passport Unique Identifier）とのリンクを作ることでサイト間のSSOのため の認証情報を伝達するので、サイト間や.Net Passportの認証センタとのプラ イバシ情報の共有はしないことになっている。
・.Net Passportの動作
.Net Passportは利用者の認証クレデンシャルにリンクしたPUIDを用いサ イト間の連携（SSO）を行う仕組みを提供する。.Net Passportの認証センタ
（Identity Provider）は、このSSOにサインイン／サインアウトするため
の.Net Passport共通のページを提供する。サイトにサインインした利用者は
安全に.Net Passportの認証センタにリダイレクトされ、利用者が自身のクレ
デンシャル（ID、パスワード）を入力して認証を受けると、認証センタはPUID を持って対象サイトにリダイレクトされ、サイトの用意したサービスのページ にアクセス出来るようになる。PUID等は安全のために暗号化されて送信され る。
.Net Passportのセキュリティレベル
.Net Passportではセキュリティ強度の要求の違いに対応するため3つレベ ルのサインインのメカニズムを用意している。
・標準サインイン
認証センタにID、パスワードを入力することで認証する方式で、利用の便宜
のためにID、パスワードの入力のときだけHTTPSのSSLサーバー認証を利 用する。一旦認証された後は通常のHTTPが用いられる。
・セキュアチャネル・サインイン
セキュアチャネル・サインインは認証のプロセス全体をSSLの環境下で行い、
安全性をより強化したサインインである。標準サインインではID、パスワード の入力画面のみがSSLで保護されるが、暗号化されたPUIDの送信は通常の HTTPリダイレクトで行われるため、リプレーアタックの危険性が残っている。
・ストロングクレデンシャル・サインイン
サービスプロバイダーがセキュアなコンテンツを保護するために2段階のサ インインを要求する。第１段階はセキュアチャネルのサインインを使い、第２ 段階ではSSLを用いて再度サインインを要求し、４桁のセキュリティキーを入 力させることにする。この２段階のサインインで高度なセキュリティを提供で きる。
.Net Passportの認証の流れ
以下に示す図 3-40 .Net Passportの認証フローで、標準サインインにしたが って行われる認証のプロセスを示す
Passport 利用者
（ブラウザ）
Passport
認証センタ
Passport参加サイト
Passport ログイン サーバ
Passport ユーザー
Web
サーバ
Web ペ ー ジ
assP por
１
２ ３
４
５ ６
図 3‑ 40 . Net Pas s por t の認証フロー
(1) 利用者がPassport参加サイトにアクセスし、認証を受ける要求をする (2) 参加サイトは.Net Passportの認証センタに参加サイトのIDを示してリ ダイレクトする。
(3) .NetログインサーバーはサイトIDが登録済みのものかをチェックし、
SSLの保護下で利用者にサインインページを示し、クレデンシャル入力をさせ る。サーバーはPassport DBを検索し利用者を認証する。
(4) ログインサーバーは利用者のPUIDと付属ユーザー属性情報を暗号化し て送り、利用者のブラウザにサイトへのリダイレクトをさせる。
(5) 参加サイトは、ログインサーバーが送ってきたPUIDを含むチケットを 復号しPUIDと必要な属性を得て利用者を認証する。
(6) 参加サイトのWebサーバーは利用者が認証されたことを示すページを送 り利用者にその後のページのアクセスを許可する。利用者が許可されたページ 間をアクセスするときWebサーバーはCookieを使って認証情報を保持する。
このとき利用者がいつでもログアウトできるようにサインアウトのアイコンも 表示させるようにする。利用者は何時でも認証されたページからログアウトで きる。
上記の⑤のプロセスで参加サイトのWebサーバーが利用者を認証するため に必要な情報として、参加サイトにあるPassport ManagerはPUIDが本当に 利用者のクレデンシャルとリンクしたものかを確かめるために、図3-36の破線 で示しように、Passport認証センタにある利用者のXMLで書かれた構成ファ イルを定期的にダウンロードし、これとPUIDとを比較することで参加サイト のWebサーバーが利用者を認証することが出来る。
.Net参加サイトのサーバー間では利用者の生のクレデンシャル情報は伝達 することは無く、プライパシが確保される。
.Net Passportをマイクロソフトのサービスとして利用することや自前
で.Net Passportの認証センタを運用してSSOを構築することは既に多くのサ イトで行われている。.Net Passportははじめはクレデンシャルとしてユーザ ーIDとパスワードのみがサポートされたが、.Net Passport 2.0ではより強力 なセキュリティのためにKerberosのセキュリティメカニズムを用意すること になった。