強力なSSOを実現するXML認証・認可サービス（SAML）：Webサービスのセキュリティ（4）（1/2 ページ）

　「第1回 Webサービスのセキュリティ概要」ではWebサービス・セキュリティのフレームワークについて、「第2回 XMLデジタル署名とXML暗号」ではXML署名とXML暗号について述べた。「第3回 XML鍵管理サービスとXMLプロトコル」は鍵情報の登録と検証を外部のサービスに依頼する仕組みであるXKMSと、これらの情報を伝達するためのXMLプロトコルSOAPについて述べた。

　今回はシングルサインオン（SSO）や、それに続いて属性情報やアクセス制御情報を伝達するプロトコルSAML（Security Assertion Markup Language）について述べる。SAMLは連携した企業間のWebサービスのSSOを目指して最近策定されたLiberty Allianceの仕様や、マイクロソフトの.NET Passportに用いられる基本的な技術として注目されているものである。さらにSAMLの上できめの細かなアクセス制御を行うための記述言語XACML（eXtensible Access Control Markup Language）については次回に述べることにする。SAMLやXACMLは、PKIと権限管理のインフラストラクチャであるPMI（Privilege Management Infrastructure）を融合させる次世代のフレームワークである。

　今回は、前半でSAMLの概要とその利用法について述べ、後半にSAML要求／応答プロトコルとアサーションの構文およびメッセージングプロトコルSOAPやHTTPへのバインディングについて解説する。

SAMLの特徴

　関連する多くのWebサイトやページにアクセスするとき、それぞれから独立した認証を求められるのでは極めて面倒であるばかりではなく、それぞれのIDやパスワードを個別に覚えておくことは難しい。例えば、旅行の予約を取る場合、航空会社やレンタカー会社、ホテルのWebサービスがそれぞれ別の認証を求めてくるのでは利用者にとって極めて不便である。一度航空会社のWebサイトで認証されたら航空会社と連携しているレンタカー会社やホテルのWebサイトにはSSOでアクセスできると便利であろう。

　従来このようなSSOは、認証クッキーを使って実現してきた。しかし、認証クッキーは同じクッキードメイン内でのSSOに制限されている。SAMLはクッキーを用いず、またクッキーの持つ制限を超えてグローバルなSSOとより強力なセキュリティを可能にするメカニズムを提供する。Libertyの仕様やマイクロソフトのPassportに多くの注目が集まるのも、企業間のそれぞれ独立したサービスをグローバルなSSOで連携させることが可能になるからである。

　本来Webアプリケーションはページ間やWebサイト間でまったく情報を共有しないステートレスなサービスで、この特徴が多くのアプリケーションをシンプルにし爆発的な普及を促してきた。しかし実際の業務アプリケーションにはページ間やWeb間で状態を共有したいという要求がある。クッキーは、この要求に対してアプリケーション間で直接情報を共有するステートフルな仕掛けを提供するのではなく、状態情報を保持したクッキーを、ブラウザを介して伝達することによって異なるページやWebアプリケーション間で状態を共有する仕掛けを提供する。

　この方法はシステムをシンプルにしたままの状態で共有させる極めて有用な仕掛けである。クッキーによるSSOは認証クッキーの伝達により実現されている。しかし、クッキーはその伝達範囲が同じ認証ドメイン内に制限されている。またクッキーは伝達する認証クッキーをブラウザにキャッシュすることができるため、この認証クッキーを第三者が不正使用してなりすましを許す可能性があることからセキュリティ上の問題が指摘されてきた。

　SAMLはクッキーを用いず、クッキーの柔軟性を継承し、クッキーの持つスケーラビリティの制限とセキュリティ問題を解決することを目指して設計された。SAMLの第1の目的は柔軟でかつ強化されたセキュリティのSSOを実現することである。しかし、実際のセキュリティアプリケーションでは、認証の後に利用者の資格などの属性によってアクセスできるページやWebサイトを制限したり、また与えられたアクセス権限により資源へのアクセスを制御するいわゆる認可サービスが必要である。SAMLには認証情報伝達サービス（Authentication Assertion）に加えて2つの認可サービスが加えられている。1つは属性情報の伝達（Authorization Assertion）であり、もう１つはアクセス制御情報の伝達（Authorization Decision Assertion）である。

　SAML仕様はPKIのセキュリティ環境での利用のみを前提にしたものではなく、セキュリティを強化したID／パスワードから対称鍵を使った認証までを扱うことができる幅の広いものとなっている。しかし、SAMLにPKIを導入することによって強力なセキュリティを持つSSOと柔軟で強力な属性制御を実現できるのである。またSAMLは、次回に述べるXACMLと結合することによって、きめの細かなポリシーによる極めて柔軟で拡張性の高いアクセス制御のメカニズムを提供する。

　SAML標準の1つの目的は、異なるベンダのアクセス制御製品間の相互運用性を推進することである。現状では異なるベンダ製品ですでに大規模に展開されたサイト間でのSSOを実現することが難しい。しかし、SAML標準を実装したアクセス制御製品間では連携SSOが可能となる。Liberty Alliance仕様もこのような環境の実現を目指している。

　SAML 1.0は、OASIS（Organization for the Advancement of Structured Information Standards）によって2002年5月に以下のような最終段階の仕様書群が発表されている。これらの仕様書は背景にあるセキュリティ技術を抽出して記述したもので、この仕様書だけを直接読んでも分かりにくい。従って、本稿ではこれら仕様書を単に解説するのではなく、SAMLがどのように使われるのかが見えるように記述することに努める。SAMLスキーマ仕様や関連する仕様の正確な情報は以下の一連の仕様書を参照してほしい。

SAMLのモデル

　SAMLはセキュリティ情報交換のためのXMLベースのフレームワークであり、要求と応答のプロトコルと応答に含まれるアサーションの構文仕様を定めたものである。このセキュリティ情報は対象とする主体（Subject：人またはコンピュータ）のあるセキュリティドメインにおける認証情報や属性情報や認可情報をアサーションの形式で表現する。SAMLオーソリティには以下の3つがあり、要求者の問い合わせに対して、以下の提供を行う。

　アサーションの提供を受けた要求者は、これらのアサーションをそれぞれのポリシーを実行するアプリケーション（PEP：Policy Enforcement Point）に渡して要求を実行する。すなわち、以下のような行動を行う。

　図1にSAMLのフレームワークを示す。図に示すようにSystem Entity（主体のクライアントまたはクライアントからアクセス要求を受けたサーバ）は、以下のような手順で実行する。

図1 SAMLフレームワーク

　図1に示した3つのSAMLオーソリティはいつも必要というわけではない。SSOを実現するだけなら、認証オーソリティを用いるだけでよい。しかし、属性や認可制御を行うためには、本人の確認を必要とするため、認証オーソリティの認証アサーションを属性オーソリティやポリシー決定点に必ず提示しなければならない。

SAMLの利用例

　SAMLの主要な利用法にはシングルサインオン（SSO）がある。また属性や認可情報を使ったRoleベースやRuleベースのアクセス制御への利用が可能である。ここではいくつかの典型的な利用例について述べる。この利用例はSAML仕様の補助ドキュメントとして「OASIS Security Service Use Case and Requirements」に述べられている。

（1）SSO

　SSOの概念は図2に示すように、Webユーザーは最初にソースWebサイト（認証オーソリティ）で認証を受ける（Step1）。その後この認証情報を用いてほかのWebサイトに再度認証することなくアクセスできる（Step2）。

図2 シングルサインオン・モデル

　SSOにはSAMLを用いると以下の2つのモデル（PullモデルとPushモデル）が考えられる。Pullモデルはアクセス要求を受けたサイトが主体の認証情報をオーソリティに問い合わせるモデルであり、Pushモデルは要求者の依頼でオーソリティがアクセス予定のサイトに認証情報を事前に伝えるモデルである。例えていえば、Pullモデルは知らないユーザーがeコマースに購入要求してきたら、eコマースサイトはこのユーザーが本当に正しい権限を持っているかをクレジット会社に問い合わせるもので、Pushモデルは問い合わせユーザーの認証情報をクレジット会社が事前にeコマースサイトに知らせておく形式である。このほかPKIの第三者認証方式も用いられる。

・ SSO　Pullモデル

　Pullモデルでは、図3に示すようなSSO認証の手順を取る。

図3 SSO　Pullモデル

・SSO Pushモデル

　SSO PushモデルではPullモデルと違って、図4に示すような手順を取る。

図4　SSO　Pushモデル

（2）認可サービス

　アクセス制御サービスのモデルを図5に示す。基本的に2つのステップを必要とする。

図5　アクセス制御サービス

・認可モデル

　このモデルは図6に示すような1つのセキュリティゾーン内の認可手順に示される。Webユーザーはセキュリティシステムで認証した後に、Webサーバへ動的な資源を要求する。Webサーバはアプリケーションにユーザーの認可の権限をチェック出来るように認証情報を提供する。

　このモデルではセキュリティシステムはユーザーのクレデンシャルを収集し、SAMLオーソリティ（認証オーソリティや属性オーソリティおよびポリシー決定点）として機能する。アプリケーションはPEPとしての機能を持つ。

図6　アクセス制御の手順