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

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

印刷

通知 連載「Webサービスのセキュリティ」の新着をメールで通知

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

続きを読む

SAMLプロトコルとSAMLアサーション

　SAMLプロトコルは要求と応答の手順を定めたものである。実際のトランスポートのプロトコルはいろいろなものが使えるようにSAMLは下位のトランスポートプロトコルに独立に定めているが、1つのバインディングとしてSAML over SOAP over HTTPの仕様をOASISで定めている[SAML Bind]。

　SAMLプロトコルを図7に示す。SAMLクライアント（Requester）は要求プロトコル＜Request＞要素の子要素に各種の＜Query＞要素を指定して要求を送信する。SAMLレスポンダ（SAMLオーソリティ）は応答プロトコル＜Response＞要素の子要素に＜Status＞要素と＜Assertion＞要素を含めた応答を返す。＜Response＞処理で何らかのエラーが生じた場合、＜Response＞要素は＜Status＞要素にエラーコードを返すだけで＜Assertion＞要素は含まない。

図7　SAMLプロトコル

　SAMLの＜Request＞、＜Response＞および＜Assertion＞にはデジタル署名（XML署名）を付けることができる。デジタル署名はオプションであるが、デジタル署名を付けた場合、送信者の識別や否認防止を強力にサポートする（後述するSAMLのセキュリティの項参照）。

　SAMLではアサーション（saml）とプロトコル（samlp）のスキーマを定めた2つの名前空間を用いる（まだドラフト段階で最終版ではない）。

xmlns:saml="http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-27.xsd"
xmlns:samlp="http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-protocol-27.xsd"

●SAML要求プロトコル＜Request＞

　SAML＜Request＞要素は図8のような例に示す構文で構成される。

図8　SAML要求プロトコル

　SAML＜Request＞のQuery要素は要求の種類（認証、属性、認可など）に応じて以下に示すような各種のQuery要素のどれか1つを指定することになる。

• 認証問い合わせ要求＜AuthenticationQuery＞
• 属性問い合わせ要求＜AttributeQuery＞
• 認可決定問い合わせ要求＜AuthorizationDecisionQuery＞

　そのほかの一般の問い合わせに拡張でき、汎用用途に用いることができる「Query」要素などもあるが、詳しくはSAML仕様書[SAML Core]を参照のこと。

●SAML応答プロトコル＜Response＞

　SAMLの応答である＜Response＞要素は、図8に示した認証、属性、認可の要求に対して図9のような構文となる。

図9 SAML応答プロトコル

　応答プロトコルに含まれる＜saml:Assertion＞には認証、属性、認可決定の＜Query＞に対応する＜Assertion＞には、以下のような子要素が含まれる。

• 認証 ＜AuthenticationQuery＞ → ＜AuthenticationStatement＞
• 属性 ＜AttributeQuery＞ → ＜AttributeStatement＞
• 認可決定 ＜AuthorizationQuery＞ → ＜AuthorizationStatement＞

●各種問合わせと対応するSAMLアサーションの例

（1） 認証問い合わせ要求＜AuthenticationQuery＞と対応する認証アサーションの例

　図10に示す認証問い合わせは、X.509v3の証明書を使って認証アサーションを要求する例である。この認証要求に対して図11の認証アサーションが返される。

図10 認証問い合わせ

　図11に示す認証アサーションの例は図10に示した認証要求＜Request＞に対するもので、PKI（X.509v3の証明書）で主体を認証し、このアサーションの有効期間が20分であることを示している。

図11 認証アサーション

（2） 属性問い合わせ要求＜AttributeQuery＞と対応する属性アサーションの例

　図12に示す例では主体の認証について認証アサーションを添付し、主体の資格を問い合わせている。この要求に対して図13の示す属性アサーションが返される。

図12 属性問い合わせ

　図13に示す例は、図12に示した主体 “Suzuki”の資格の問い合わせ要求に対して属性値 “Manager”を含む属性アサーションである。

図13 属性アサーション

（3） 認可決定問い合わせ要求＜AuthorizationDecisionQuery＞と対応する認可決定アサーションの例

　図14に示す例では認証アサーションと属性アサーションを添付して資源へのアクセスを要求している。この認可要求に対して図15の認可決定アサーションが返される。

図14 認可決定問い合わせ

　図15に示す例は、図14で示した資格属性を指定した認可要求に対して、アクセスを許可（Permit）する認可決定アサーションの例である。この例では資源へのアクセスを許可（Permit）している。要求者に権限がなければ認可決定は不許可（Deny）となる。

図15　認可決定アサーション

・アサーションと公開鍵証明書

　SAMLアサーション（SA）はある主体についての認証や属性、認可権限についての問い合わせに対してSAMLオーソリティがそれぞれの内容を証明するステートメントである。PKIの公開鍵証明書（PKC）もCA（Certification Authority）が主体の本人性（Identity）と公開鍵の結合を証明するアサーションといえる。しかし、SAMLアサーションとPKCはいくつかの異なる側面を持っている。認証アサーションは主体の本人性だけを証明するのに対して、PKCは本人性と公開鍵の結合を証明する。

PKCは比較的長期（数年）使用を想定し何度も再利用できる。PKCは証明書の完全性を保証するためCAの署名が付けられるが、SAは短期の有効期間（セッションごとまたは数時間）で1つの目的のために発行される。

SAは安全性が保障されれば必ずしもSAMLオーソリティの署名を付ける必要がない。アサーションの使用期限が切れればまたSAMLオーソリティに要求すればよいのである。

・CP/CPSとSAML認証アサーションのポリシー

PKIでは、証明書に証明書ポリシーを（CP）指定し、CPS（認証実施規定）で安全な登録方法や証明書を発行するに当ってのセキュリティ基準や認証機関の責任や義務を明らかにする。

SAMLでは、アサーションの＜AuthenticationStatement＞要素のAuthenticationMethod 属性で指定するURIで示すところに、SAMLオーソリティがどのようなセキュリティ基準を備えているかを記述することができる。また＜Condition＞要素でSAML オーソリティの責任の範囲を規定し、＜Advice＞要素でSAMLアサーションの利用者への注意などを指定できるようにしている。また＜SubjectConfirmation＞要素にどのような認証方法をとっているか（パスワード、Kerberos、PKI、SSL/TLSなど）を指定することができる。

・SAMLのセキュリティ

SAMLはSAMLリクエスタが認証や属性、認可の権限を証明してもらうために＜request＞を送ると、SAMLレスポンダは処理の状態と要求に対する証明＜assertion＞を＜response＞として返すプロトコルを定めている。SAMLはこの＜request＞や＜response＞、＜assertion＞の内容の完全性と送信者や返信者の本人性を保証するためにPKIなどの特定の技術だけを想定していない。古典的なパスワードベースや対称鍵を使うKerberosや公開鍵ベースのPKIを使っても良いのである。しかし、パスワードベースの認証を行う場合はセキュアーな通信チャネルを使わなければならない。すなわち、IPsecまたはSSL/TLSのサーバ認証の環境は必須である。

SAMLではオプションとして＜request＞や＜response＞、＜assertion＞にXMLデジタル署名＜ds:signature＞を付けることが可能である。デジタル署名を使った場合はSAMLメッセージの完全性と発信源の確実な識別を可能にする。

SSL/TLSなどはリクエスタとレスポンダが対向する環境では十分なセキュリティを保証するが、もしレスポンダが応答する＜assertion＞を他のプロバイダから得て＜response＞に加える場合などでは＜assertion＞は必ずオリジネータのデジタル署名が付けられなければならない。

SOAPバインディングとプロファイル

　SAML仕様は下位のトランスポートプロトコルとして特定のプロトコルを想定していないが、SAML over SOAP over HTTPを必須のプロトコルバインディングとして規定している[SAML Bind]。SAMLをSOAPにバインドする際の基本的方針は以下のとおりである。

• SOAPバインディングではSOAPのHeaderは使わず、Body内にSAMLプロトコルを記述する。
• 1つのSOAPメッセージにはSAML＜Request＞は1つだけにする。
• 1つのSOAPメッセージにはSAML＜Response＞は1つだけにする。

●SOAP over HTTPを使ったSAML要求／応答

図16はSAML認証をSAML認証オーソリティに要求する場合の例である。

図16 SAML要求（SOAP over HTTP）バインディング（拡大）

　図17は図16のSAML認証要求に対する応答の例で、認証アサーションが返される。

図17 SAML応答（SOAP over HTTP）（拡大）

・SAML SSOプロファイル

　Binding and Profiles for the OASIS Security SAMLの仕様書ではSSOを実現するに当たってのSAMLのプロファイルを規定している。ここではブラウザベースのSAMLプロファイルとして、ブラウザ／artifactプロファイルとブラウザ／POSTプロファイルを定めている[SAML Bind]。

・ブラウザ／artifactプロファイル

　パスワードベースの認証を想定している。ブラウザはURIに認証要求をBase64でエンコードして認証オーソリティに尋ねる。認証オーソリティはパスワードのハンドルをブラウザに返し、目的Webサイトにリダイレクトさせる。目的Webサイトはブラウザユーザーのパスワードのハンドルの真偽を認証オーソリティに問い合わせてユーザーを認証する。正しいユーザーなら指定したページをアクセスさせる。これは図3のPullモデルに相当する。

・ブラウザ/POSTプロファイル

　デジタル署名の利用を前提にしている。ブラウザはSAML＜Request＞で認証オーソリティに認証要求＜AuthenticationQuery＞をHTTPのPOSTで問い合わす。認証オーソリティは認証アサーションにデジタル署名をしてブラウザに返す。ブラウザはこの認証アサーションを目的Webサーバに送る。目的Webサーバは署名を検証し、アサーションの完全性とブラウザユーザー認証を行い、正しければ指定したページをアクセスさせる。これはPushモデルの一形態である。これらのプロファイルはLiberty Alliance Projectの仕様のベースとなっている。

---

　SAMLはWebサービスにPKIとPMIすなわち、認証や認可のセキュリティを与えるフレームワークとして注目されているサービスである。最近Liberty Allianceが発表したLiberty仕様1.0（2002年7月現在）は企業間連携サービスのための強力なSSO（Federated SSO）を実現するものとして期待を集めている。Liberty仕様は完全にSAML認証に基づき実際のサービスを目指して、SAMLに若干の拡張とあいまい性のないプロファイルを定義したものである。またマイクロソフトの.NET PassportもSAML/SOAPをベースにしている。次世代のSSO、アクセス制御の製品もこれらの仕様を備えることになろう。EntrustのGetAccessやNetegrityなどの製品も近い将来SAMLやLiberty仕様に基づいた製品の提供を予定している。またVeriSignもまたサービスにSAMLベースのセキュリティを加えるであろう。

　次回はSAMLフレームワークに基づいて、特に資源へのきめ細かで柔軟なルールベースのアクセス制御サービス（PDPやPEPのサービス）を規定するXACMLについて述べることにする。

第5回」へ

「Webサービスのセキュリティ」バックナンバー

• XACMLのアクセス制御ルールとその仕様
• PKIとPMIを融合させる次世代言語XACML
• 強力なSSOを実現するXML認証・認可サービス（SAML）
• XML鍵管理サービス（XKMS）とXMLプロトコル（SOAP）
• XMLデジタル署名とXML暗号
• Webサービスのセキュリティ概要