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

» 2002年10月02日 00時00分公開

[鈴木優一，エントラストジャパン]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　﹁第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へのバインディングについて解説する。

※関連記事 XML暗号化の基礎と実践前編　XML暗号化と正規化と電子署名

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︶であり、もう1つはアクセス制御情報の伝達︵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 1.0（XML Security Assertion Markup Language）

http://www.oasis-open.org/committees/security/#documents

Assertions and Protocol［SAML Core］

　- SAMLのAssertionsのスキーマと要求／応答プロトコルを定めた仕様

　　・ Assertion Achema［SAML-.Xsd］

　　・ Protocol Schema［SAMLP-.Xsd］

Bindings and Profiles［SAML Bind］

　- SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定

Security and Privacy Considerations［SAML Sec］

　- SAMLのセキュリティ要件を考察したもの

Conformance Program Specification［SAML Conform］

　- SAMLの相互運用性を確保するために適合性要件をまとめたもの

Glossary［SAML Gross］

　- SAMLで用いる用語の定義

表1 SAML 1.0の仕様

SAML用語 　以下の解説で使用するSAML特有の術語を定義しておくことにする。これはSAML仕様書のGlossaryで定義しているものの一部である。同じ用語でもPKI用語とニュアンスを異にするものもあり、また異なる用語でも似た内容を持っているものもあるので注意する必要がある。 ・アサーション︵Assertion︶

翻訳しづらい用語であるが、アサーションとはSAMLオーソリティによって発行され、対象とする主体の認証や属性あるいは資源に関する認可権限の証明である。PKIの公開鍵証明書と違って長期の有効期限をもたず、アサーションの有効期間は短期︵数時間︶で、問い合わせに対してオーソリティが応答として返すものである。

・オーソリティ（Authority）

オーソリティには認証オーソリティ、属性オーソリティ、ポリシー決定点の3つがあり、問い合わせにその正当性を証明する応答︵アサーション︶を返すシステム・エンティティである。ここで認証オーソリティはPKIでいうCA︵Certification Authority︶ではない。認証オーソリティは主体︵Subject︶に関する問い合わせに対しその本人性︵Identity︶を確認するため、背後の認証環境︵パスワードファイル、KerberosトークンやPKIの証明書︶を検証して本人性を証明する﹁認証アサーション﹂を発行する信頼できるサーバである。また属性オーソリティもX.509でいう事前に属性証明書を発行するAA︵Attribute Authority︶とは異なり、認証を受けた主体に関する問い合わせに対し、﹁属性アサーション﹂を発行する信頼できるサーバのことである。・認証オーソリティ︵Authentication Authority︶はユーザーの認証を証明するもので、PKIのCAの機能を提供するものではなく、︵例えばCAの発行した証明書などを検証して︶認証権限の許可をアサーションとして返す。・属性オーソリティ︵Attribute Authority︶はユーザーの登録された属性情報の証明をアサーションとして返す。・ポリシー決定点︵Policy Decision Point‥PDP︶はPEPの要求に対してユーザーのPolicyに従ったアクセス制御の権限が何であるかの証明をアサーションとして返す。

・ポリシー実行点（Policy Enforcement Point：PEP）

PDPの証明に従ってアクセス制御を実行しその結果を返すところ。

SAMLのモデル

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

認証オーソリティは認証情報の再利用（SSO）を可能にする「認証アサーション」を提供する
属性オーソリティはポリシーに定めた資格や役職などの「属性アサーション」を提供する
認可決定オーソリティはポリシーで定めた規則に従った「認可決定アサーション」を提供する

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

本人性（Identity）を認証し、指定したWebサイトにアクセスさせる
本人の資格属性によって特定のページへのアクセスを許可する
本人の認可権限によって特定の資源へのアクセス（読み、書き、実行など）をさせる

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

(一)まずSAML 認証オーソリティにSAML認証要求としてクレデンシャル︵パスワードや鍵情報など︶を示す。認証オーソリティは認証ポリシーや外部の認証環境︵PKIなど︶を検証して、主体の本人性を証明する認証アサーション︵Authentication Assertion︶を発行する。 (二)次にこの認証アサーションを属性オーソリティまたはPDP︵Policy Decision Point︶に示して認可権限を問い合わせる。属性オーソリティはポリシーに沿った主体の資格などの属性アサーションを発行し、PDPに主体のアクセス権限を問い合わせる。PDPはあらかじめ登録された認可権限をポリシーデータベースから検索して属性決定アサーションを発行し、実際にアクセス制御を行うPEPに渡しアプリケーション要求に沿ったWebページへのアクセスや資源へのアクセスを実行させるのである。

図1 SAMLフレームワーク

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

・SAMLとPKI SAMLオーソリティは、特定の認証のモデル︵パスワードベースやKerberosやPKIベースなど︶を仮定していない。しかし、SAMLをPKI環境で用いることで強力なセキュリティを提供できる。SAML認証オーソリティは主体の本人性の問合せに対して、主体のクレデンシャル︵公開鍵証明書など︶を検証し、応答のアサーション︵Assertion︶でその主体の本人性︵Identity︶を証明する。SAML認証オーソリティの背後には前回述べた鍵情報を検証するXKMSなどを使うこともできる。SAML属性オーソリティやポリシー決定点の背後にもPKIベースの属性証明書を使うこともできる。またアサーションにデジタル署名を付けること、オーソリティへの問い合わせやその応答にデジタル署名を付けることでそれらの完全性や発信者の真正性を確認できる。このように、PKI環境でSAMLを用いるとPKIとPMIを融合した強力なセキュリティ環境が提供できる。

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認証の手順を取る。

Webユーザーがクレデンシャル（パスワードまたは公開鍵または認証の参照先）を示す。
ソースWebサイトで認証を受ける。
目的Webサイトにアクセスする。
目的WebサイトはWebユーザーの認証情報をソースWebサイトに問い合わせる。
認証アサーションを引き出す（Pull）。
その後Webユーザーは目的Webサイトの資源を利用できるようになる。

図3 SSO　Pullモデル

・SSO Pushモデル

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

WebユーザーがソースWebサイトへ認証と目的Webサイトへのリンク要求を出す。
ソースWebサイトはWebユーザーのために目的Webサイトへアクセス権限を証明するアサーションを出す（Push）。
目的Webサイトはアクセスを許可したソースWebサイトへアクセス決定の参照先を提供する。
ソースWebサイトはWebユーザーに決定の参照先を提供し、目的Webサイトへのリダイレクトを促す。
Webユーザーは認証決定の参照を提示し目的Webサイトにアクセス要求を出す。
目的Webサイトは資源へのアクセスを提供する。

図4　SSO　Pushモデル

（2）認可サービス

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

Webユーザーはアクセス制御を実行するWebサイトのPEP（Policy Enforcement Point）へアクセスを要求する。
PEPはPDPに問い合わせ、Webユーザーのアクセス権限をチェックし、資源へのアクセス制御を実行する。

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

・認可モデル 　このモデルは図6に示すような1つのセキュリティゾーン内の認可手順に示される。Webユーザーはセキュリティシステムで認証した後に、Webサーバへ動的な資源を要求する。Webサーバはアプリケーションにユーザーの認可の権限をチェック出来るように認証情報を提供する。　このモデルではセキュリティシステムはユーザーのクレデンシャルを収集し、SAMLオーソリティ︵認証オーソリティや属性オーソリティおよびポリシー決定点︶として機能する。アプリケーションはPEPとしての機能を持つ。