1回のユーザー認証で，異なるWebシステム（サーバー）にアクセスできるようにする「シングル・サインオン（SSO）」。既にいくつかの製品が市場に出ており，導入が進んでいる。しかしながら，異なる製品間の相互運用性（連携）の問題がある。この問題を解消するために，2002年後半以降，業界団体などでは新しい動きがある。「SAML」の策定や「Liberty Alliance Project」の結成である。今回の記事では，SSOの技術動向をまとめた。
SSOの標準化や認証連携の実現へ
SSOは，Webシステムごとに行っていたユーザー認証を，1回のユーザー認証で，権限のあるすべてのWebシステムにログオンできるようにする仕組みである。Webシステムごとに必要だったユーザーIDやパスワードを1つにできるので，ユーザーの利便性を向上できる。
利便性が高まる分，1回の認証をくぐり抜けられると，複数のシステムにアクセスされてしまう恐れはある。しかし，ユーザーとしては，1つのパスワードさえ管理すればよいので，複数持っている場合よりも，きちんと管理できるだろう。システム側でも，その“入り口”を強固にしておけばよいので，適切に運用すれば，SSOはセキュリティを確保しつつ，利便性を提供できる仕組みといえる。
このため，SSOは企業にとって有用なソリューションの一つであり，さまざまなベンダーが製品を出荷している。実際に導入も進んでいる。しかし，現状では問題がいくつかある。その一つが製品間の相互運用性の問題である。各ベンダーは独自の方法でSSOを実現させているので，異なるベンダーの製品間では，認証の連携を行えない場合がある。このため，閉じた企業内では問題なくSSOを実現できても，複数の企業間あるいは，Webサービスに代表されるビジネス連携フレームワークの中で，SSOを実現することが難しい。
そこで，2002年の後半以降，業界では，SSOの標準化や認証連携の実現へ向けた動きが始まっている。代表的なキーワードは，「SAML（Security Assertion Markup Language）」と「Liberty Alliance Project」である。
SAMLとは，ユーザー認証の情報をXML形式でやり取りするための技術である。SAMLを使えば，あるサーバーが認証した情報をほかのサーバーに伝えて，認証の連携を図ることが可能となる。業界団体「OASIS（Organization for the Advancement of Structured Information Standards）」が策定した。SAMLの使用を推進することで，SSOの標準化を進めることができる。
Liberty Alliance Projectとは，米Sun Microsystemsなどが2001年9月に設立した業界団体である。インターネットにおけるユーザー認証に関するオープンな技術の開発および普及を目的に設立された。具体的には，マイクロソフトの「.Net Passport」の認証サービスと同じような認証サービスを提供できる標準仕様（フレームワーク）を策定し，普及活動を行う。なお，SSOのフレームワークとしては，.Net Passportも含まれるが，今回はスペースの関係で触れない。機会があれば，いずれ改めて解説したいと思う。
SSOベンダーが，SAMLやLiberty Alliance Projectの仕様に対応することで，異なるベンダーの製品同士の連携が可能となるのだ。国内では，電子商取引推進協議会(ECOM)の認証公証WG（ワーキンググループ）でも，「SAML」の実用化に向けた検討を始めている（関連記事）。
SAMLやLiberty Alliance Projectの仕様は，Webサービスなどのビジネス連携フレームワークでSSOを実現するための，有力なソリューションの一つである。次に，SAMLおよびLiberty Alliance Projectをもう少し詳しく説明しよう。
XMLベースで認証の連携を実現する「SAML」
SAMLは，2002年11月にバージョン1.0が（関連記事），2003年3月には，バージョン1.1が「OASIS標準」として公開された（参考資料）。
SAMLでは，認証情報や属性／認可情報の記述仕様（XMLスキーマ）と，認証情報などを収めたXMLファイルをやりとりする，要求と応答のプロトコル仕様を規定している。やり取りされる認証情報などは，「アサーション（表明）」と呼ばれる。
アサーションには，（1）認証アサーション（本人を証明する情報），（2）属性アサーション（資格や組織などの属性情報），（3）認可決定アサーション（アクセス権限情報）――の3種類がある。
認証の流れをざっと説明すると次のようになる。まず，ユーザーからの認証要求を受けて，SAML認証サーバー上の「認証オーソリティ」は，要求したのがユーザー本人だと証明する「認証アサーション」を発行する。同じように，認証サーバー上の「属性オーソリティ」および「認可決定オーソリティ（PDP：Policy Decision Point）」は，それぞれ，「属性アサーション」および「認可決定アサーション（アクセス権限情報）」を発行する。
この時点で，「認証要求しているのが誰か」「そのユーザーの属性情報は何か」「そのユーザーに与えられているアクセス権限は何か」――といった情報を収めたXMLファイルが，SAML認証サーバーで生成されることになる。
次に，ユーザーから，あるWebシステムへの利用要求が出されると，SAML認証サーバーから，そのWebシステム上の「ポリシー実行ポイント（PEP：Policy Enforcement Point）」へアサーションを収めたXMLファイルが渡される。これに基づいて，そのWebシステムは，利用要求を出したユーザーにリソースのアクセスを許可する。
SAMLを実装したSSOのモデルには，「Pull型」「Push型」「認証サービス型」――がある。
例えば，Pull型の具体的な流れは，次のようになる。
- ユーザーが認証要求をSAML認証サーバーに送る（認証サーバーがユーザー本人かどうかを認証するには，適当なクレデンシャル――パスワードやトークン，デジタル証明書など――を用いる）
- SAML認証サーバーはユーザー認証を行った後，ユーザーが利用したいWebシステムへ利用要求を送る
- SAML認証サーバーは，認証アサーション，属性アサーション，認可決定アサーションを発行する
- 利用要求を送られたWebシステムは，SAML認証サーバに認証情報を要求する
- SAML認証サーバーからWebシステムへアサーションが送信される
- Webシステムがアサーションを基に認証する。認証が終了すれば，ユーザーは利用したいWebシステムへのアクセスできる
「Push型」「認証サービス型」については，関連記事に詳しいので，そちらを参照してほしい。
なお，SAMLの具体的なXMLスキーマについては，「OASIS/SSTC SAML 1.0 Specification」（ZIPファイル）などに記載されている。
認証サービスを提供するための標準仕様「Liberty」
「Liberty Alliance Project」では，Sun Microsystemsや米Hewlett-Packard，米RSA Securityをはじめ，160以上の企業や組織が参加して，認証サービスを提供するフレームワークの標準仕様の策定を進めている。2002年7月に最初の仕様「Liberty v1.0」が発表され，2003年1月には改訂版の「Liberty v1.1」が公開されている（関連記事）。Libertyには，SAMLの仕様が取り込まれている。
現在は，v1.2のドラフトとして，「Liberty Identity Federation Framework（ID-FF）」「Liberty Identity Web Services Framework（ID-WSF）」「Liberty Identity Service Interface Specifications（ID-SIS）」が公開されている（関連記事）。
Libertyのすべてをここで述べるのはスペースの都合で難しい。本記事では，Libertyの概要を紹介するにとどめる。
Libertyのモデルは，「トラスト・サークル（Circle of Trust）」という，認証情報を共有する“信頼の輪”を作り上げるものである。「ユーザー」「IdP（Identiy Provider，認証を管理するプロバイダー）」「SP（Service Provider，サービス提供者）」で，情報を共有する連携関係を作り上げる。
Libertyのフレームワークでは，ユーザー，IdP，SP間の通信パスを保護する「チャネル・セキュリティ」と，通信パス上のメッセージを署名および検証する「メッセージ・セキュリティ」で，機密性と完全性を担保する。
Libertyが提供する主な機能は以下の3つである。
- アイデンティティ連携
- シングル・サインオン（認証）
- シングル・ログアウト（グローバル・ログアウト）
アイデンティティ連携は，トラスト・サークルに基づいて，IdPとSP間での連携およびその解除を提供する機能。アイデンティティ連携は，1つのIdpと1つのSP間で行われるとは限らない。「複数のIdPと1つのSP」「1つのIdpと複数のSP」「IdP同士」など，さまざまな形態が考えられる。
シングル・サインオン（認証）は，IdPにログインしたことを別のSP（またはIdP）に伝える手段を提供する機能。シングル・ログアウト（グローバル・ログアウト）は，ユーザーがログアウトしたときに，そのことをIdPやSPに通知し，SPとのセッションを明示的に切断する機能である。
以上，駆け足になってしまったが，シングル・サインオンの動向を紹介した。既に主なSSOベンダーは，SAMLやLiberty Alliance Projectへの対応が表明され，実装が始まっている（関連記事）。今後は，単に対応するだけではなく，異なるベンダーの製品同士のSSO連携や相互運用性の確認が進むとともに，運用面での課題が明らかになっていくと考えられる。
大谷 俊一 (OHTANI Toshikazu) 
NECソフト株式会社 ITソリューション事業部
セキュリティ技術センター センター長
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，セキュリティ全般の話題（技術，製品，トレンド，ノウハウ）を取り上げる週刊コラムです。システム・インテグレーションやソフト開発を手がける「NECソフト株式会社」の，セキュリティに精通したスタッフの方を執筆陣に迎え，分かりやすく解説していただきます。
