SAML 2.0
Security Assertion Markup Language 2.0 (SAML 2.0)はsecurity domain間の認証と認可アイデンティティをやりとりするための SAML規格のバージョンである。SAML 2.0 は アサーション を含む セキュリティトークン を利用して、SAMLオーソリティ(アイデンティティ・プロバイダ)とSAMLコンシューマ(サービス・プロバイダ)との間で本人(通常はエンドユーザ)に関する情報をやり取りするXML-ベースのプロトコルである。SAML 2.0はウェブベースのクロスドメインシングルサインオン (SSO)を可能にし、複数の認証トークンをユーザに配布する際の管理負荷を減らす。
SAML 2.0は、SAML 1.1に代わり、2005年3月にOASIS標準として承認された。SAML 2.0の重要な側面は、公式ドキュメントであるSAMLCore、 SAMLBind、 SAMLProf、、SAMLMetaに詳細に記載されている。
SAML 2.0の策定には、24以上の企業・団体から約30名が参加した。特筆すべきはLiberty AllianceがそのIDフェデレーション・フレームワーク(ID-FF)仕様をOASISに寄贈したことであり、これがSAML 2.0の仕様のベースとなった。したがって、SAML 2.0は、SAML 1.1、、 が収れんしたものと言える。
アサーションとは、SAMLオーソリティーが作成した 0 個以上のステートメントを提供する情報のパッケージである。SAML のアサーションは通常、 要素で表されるサブジェクトについて行われる。SAML 2.0 仕様では、SAMLオーソリティーが作成できる 3 種類のアサーション・ステートメントを定義している。SAML で定義されたステートメントはすべて、サブジェクトに関連付けられている。 定義されている3種類のステートメントは以下のとおりである:
認証アサーション(Authentication Assertion):アサーション・サブジェクトは、特定の時間に特定の方法で認証された。
属性アサーション(Attribute Assertion): アサーション・サブジェクトは、提供された属性に関連付けられている。
認可決定アサーション(Authorization Decision Assertion):アサーション対象者が指定されたリソースにアクセスする許可を求める要求が、許可または拒否された。
SAML アサーションの重要なタイプは、Web ブラウザの SSO を促進するために使用される、いわゆる "bearer"  アサーションである。
以下は、アイデンティティ・プロバイダ (https://idp.example.org/SAML2) からサービス・プロバイダ (https://sp.example.com/SAML2)に対 して発行された短命のベアラ・アサーションの例である。このアサーションには、認証アサーション  および属性アサーションの両方が含まれており、サービス・プロバイダはこれらを使用してアクセス・コントロールの決定を行うはずである。接頭辞 saml:は、SAML V2.0アサーションの名前空間を表す。
なお、上記の例では、要素に以下の子要素が含まれている:
要素:アイデンティティ・プロバイダの一意の識別子を含む。
<ds:Signature>要素:要素に対する整合性保持のデジタル署名(表示せず)を含む
要素:認証されたプリンシパルを識別する。ただし、この場合、プライバシー保護の観点から、プリンシパルの身元は不透明な一時的な識別子で隠されてる。
要素:アサーションが「有効」とみなされる条件を示す。
要素:IDプロバイダでの認証行為を記述する。
要素:これは認証されたプリンシパルに関連する多値の属性を主張する。
言い換えれば、アサーションは以下の情報をエンコードしたものである:
サービス・プロバイダ (https://sp.example.com/SAML2)専用のサブジェクト(3f7b3dcf-1674-4ecd-92c8-1544f346baf8)について、アサーション("b07b804c-7c29-ea16-7300-4f3d6f7928ac")が"2004-12-05T09:22:05Z"の時点でアイデンティティ・プロバイダ (https://idp.example.org/SAML2) によって発行された。
特に、認証ステートメントは以下のように主張している:
要素で特定されたプリンシパルは、保護されたチャネル上で送信されたパスワードによって、"2004-12-05T09:22:00Z"の時点で認証された。
同様に、属性ステートメントは次のように主張する。
要素で特定されるプリンシパルは、この機関のスタッフである。
SAMLCoreでは以下のプロトコルが規定されている。
これらのプロトコルのうち、最も重要な「認証要求プロトコル」について、以下に詳しく説明する。
SAML 1.1 WebブラウザSSOプロファイルはIdentity Provider (IDP)によって開始(initiate)される。つまり、 一方的な要素がアイデンティティ・プロバイダから(ブラウザ経由で)サービスプロバイダに送信される。(接頭辞 samlp:はSAMLプロトコルの名前空間を示す。)
ただし、SAML 2.0 では、流れはサービス・プロバイダから始まり、サービス・プロバイダは アイデンティティ・プロバイダに明示的な認証要求を発行する。結果として生じる「認証要求プロトコル」は、SAML 2.0 の重要な新機能である。
プリンシパル(またはプリンシパルの代理を務めるエンティティ)が認証ステートメントを含むアサーションの取得を希望する場合、要素がアイデンティティ・プロバイダに送信される:
上記の要素は、暗黙的に 認証ステートメントを含むアサーションを要求するものであり、サービス・プロバイダー(https://sp.example.com/SAML2) によって明確に発行され、その後(ブラウザを介して)アイデンティティ・プロバイダに提示された。 アイデンティティ・プロバイダは(必要であれば)プリンシパルを認証し、認証応答を発行する。認証応答は、(再びブラウザを介して)サービス・プロバイダに送信される。
SAML メッセージは、あるエンティティから別のエンティティへ、「値」または「参照」によって送信される。SAML メッセージへの参照は「アーティファクト」と呼ばれる。
アーティファクトの受信者は、 要求をアーティファクトの発行者に直接送信することによって参照を解決し、発行者はアーティファクトによって参照される実際のメッセージで応答する。
たとえば、アイデンティティ・プロバイダが次の リクエストを(バック・チャネルを介して)サービス・プロバイダに直接送信したとすると、次のようになる:
応答として、サービスプロバイダは、封入されたアーティファクトによって参照されるSAML要素を返す。 このプロトコルは、HTTP Artifact Bindingの基礎を形成している。
SAML 2.0 がサポートする「バインディング」の概要は、Bindings 仕様((SAMLBind)に記載されている:
SAML SOAP Binding (based on SOAP 1.1)
Reverse SOAP (PAOS) Binding
SAML URI バインディング
Web ブラウザ SSO では、HTTP リダイレクト・バインディングと HTTP POST バインディングがよく使われる。 たとえば、サービス・プロバイダは HTTP リダイレクトを使用して要求を送信する一方で、アイデンティティ・プロバイダは HTTP POST を使用して応答を送信することができる。 この例は、エンティティのバインディングの選択が、パートナーのバインディングの選択とは無関係で あることを示している。
SAML プロトコルメッセージは、HTTP GETリクエストのURLクエリ文字列で直接伝えることができる。URLの長さは実際には限られているので、HTTPリダイレクト・バインディングは、 メッセージなどの短いメッセージに適している。長いメッセージ(例えば、SAMLレスポンスのように、署名済みまたは暗号化されたSAMLアサーションを含むメッセージ)は、通常、 HTTP POSTバインディングのような他のバインディングを介して送信される。
HTTPリダイレクトで送信される SAMLリクエストまたはレスポンスには、それぞれSAMLRequest またはSAMLResponse クエリ文字列パラメータがある。メッセージは送信される前に、deflated (ヘッダーとチェックサムなし)、base64エンコード、URLエンコードが順に行われる。受信時には、元のメッセージを復元するために、このプロセスを逆に行う。
例えば、上記の メッセージをエンコードすると、次のようになる:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
上記のメッセージ(可読性のためにフォーマットされている)は、追加のセキュリティのために署名される場合もある。実際には、に含まれるすべてのデータ(SP ID を含むIssuerやNameIDPolicyなど)は、事前に IdP と SP の間で(手動での情報交換や SAMLメタデータを介して)合意されている。その場合、リクエストへの署名はセキュリティ上の制約とはならない。に、アサーション・コンシューマー・サービスのURLなど、IdPが事前に把握していない情報が含まれている場合、セキュリティの観点からリクエストへの署名が推奨される。
以下の例では、サービス・プロバイダと アイデンティティ・プロバイダの両方が HTTP POST バインディングを使用している。最初に、サービス・プロバイダはuser agent からの要求に、XHTML フォームを含むドキュメントで応答する。
SAMLRequestパラメータの値は、要素のbase64エンコードであり、ブラウザ経由でアイデンティティ・プロバイダに送信される。アイデンティティ・プロバイダの SSO サービスは要求を検証し、別の XHTML フォームを含む文書で応答する:
SAMLResponseパラメータの値は、要素のbase64エンコーディングであり、同様にブラウザを介してサービスプロバイダに送信される。
フォームの送信を自動化するためには、次のようなJavaScriptの行をXHTMLページの任意の場所に加える:
これは、ページ内の最初のform要素に、上記のSAMLResponseを含むform要素(forms[0])が含まれていることを前提としている。
HTTP アーティファクトバインディングは、Artifact Resolution Protocolと SAML SOAP バインディング(HTTP上)を使用して、SAML メッセージを参照により解決する。以下の具体例を考えてみる。サービスプロバイダーが、アイデンティティ・プロバイダーに メッセージを送信したいとする。最初に、サービス・プロバイダーは、HTTPリダイレクトを介してアイデンティティ・プロバイダーにアーティファクトを送信する。
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact
次に、アイデンティティ・プロバイダーは、バック・チャネルを介してサービス・プロバイダに直接リクエスト(先に示したArtifactResolveRequest など)を送信する。最後に、サービス・プロバイダは、参照されたメッセージを含む 要素を返す:
もちろん、フローは逆方向にも可能である。つまり、アイデンティティ・プロバイダーはアーティファクトを発行することができ、実際にはこれがより一般的である。 たとえば、このトピックで後述する「double artifact」のプロファイル例を参照。
一般に、SAML 2.0のアーティファクトは以下のように定義される(SAMLBind):
SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
TypeCode      := Byte1Byte2
EndpointIndex := Byte1Byte2
したがって、SAML 2.0のアーティファクトは、2バイトのTypeCode、2バイトのEndpointIndex、およびRemainingArtifactと呼ばれる任意のバイト列の3つのコンポーネントから構成される。 これらの3つの情報は連結され、base64エンコードされて完全なアーティファクトとなる。
TypeCodeは、アーティファクトの形式を一意に識別する。 SAML 2.0では、このようなアーティファクトを1つだけ定義しており、タイプは 0x0004である。 EndpointIndexは、アーティファクトの発行者(前述のようにIdPまたはSPのいずれかである)が管理する特定のアーティファクト解決エンドポイントへの参照である。 RemainingArtifactは、タイプの定義によって決定され、アーティファクトの「肉」となるものである。
また、「type 0x0004 artifact」のフォーマットは以下のように定義される:
TypeCode            := 0x0004
RemainingArtifact   := SourceId MessageHandle
SourceId            := 20-byte_sequence
MessageHandle       := 20-byte_sequence
したがって、タイプ 0x0004のアーティファクトは、サイズが44 バイト(エンコードされていない)である。 SourceIdは任意のバイト列であるが、実際には、SourceIdは発行者のentityIDのSHA-1ハッシュである。 MessageHandleはランダムなバイト列で、アーティファクト発行者がオンデマンドで作成することを望んでいるSAMLメッセージを参照する。
例えば、この16進法のタイプ 0x0004のアーティファクトを考える:
よく見ると、アーティファクトの先頭にTypeCode(0x0004)とEndpointIndex(0x0000)が表示されている。 次の20 バイトは、発行者のentityID(https://idp.example.org/SAML2)のSHA-1ハッシュで、その後に20のランダムバイトが続いている。 この44 バイトをbase64エンコードしたものが、上記のArtifactResolveRequestの例で見られる。
SAML 2.0 では、SAML 1.1 と同様に、主要なユースケースは依然として Web ブラウザによる SSO であるが、SAML 2.0 のスコープは、以下のプロファイルの網羅的なリストに示されているように、以前のバージョンの SAML よりも広くなっている。
SSO Profiles
Enhanced Client or Proxy (ECP) Profile
Single Logout Profile
Name Identifier Management Profile
Artifact Resolution Profile
Name Identifier Mapping Profile
SAML Attribute Profiles
Basic Attribute Profile
X.500/LDAP Attribute Profile
UUID Attribute Profile
DCE PAC Attribute Profile
XACML Attribute Profile
サポートされているプロファイルの数は非常に多いものの、各プロファイルのバインディング面が別のBindings仕様(SAMLBind)に集約されているため、Profiles仕様(SAMLProf)は簡素化されている。
SAML 2.0は、アイデンティティ・プロバイダー(IdP)、サービス・プロバイダー(SP)、およびHTTPユーザー・エージェントを操るプリンシパルを含む「WebブラウザSSOプロファイル」を規定している。 サービス・プロバイダには4つのバインディングがあり、アイデンティティ・プロバイダーには3つのバインディングがあるため、12の展開シナリオが考えられる。 以下では、これらの展開シナリオのうち3つを概説する。
これは、最も一般的なシナリオの 1 つである。サービス・プロバイダは、HTTPリダイレクト・バインディングを使用して、SAML リクエストを IdP SSO サービスに送信する。アイデンティティ・プロバイダは、HTTP-POST バインディングを使用して SAML レスポンスを SP アサーション・ コンシューマー・サービスに返す。
メッセージのフローは、サービス・プロバイダのセキュアなリソースに対するリクエストから始まる。
1. SPにターゲット・リソースをリクエスト
プリンシパルは、(HTTPユーザーエージェントを介して)サービスプロバイダにターゲットリソースを要求する。
https://sp.example.com/myresource
サービス・プロバイダは、ターゲット・リソースに代わってセキュリティ・チェックを実行する。 サービスプロバイダーに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–7をスキップする。
サービス・プロバイダは、使用するアイデンティティ・プロバイダを発見するために、あらゆる種類のメカニズムを使用する。例:ユーザに尋ねる、事前に設定された IdP を使用する、など。
2. IdP SSO サービスにリダイレクト
サービスプロバイダは、適切な SAMLRequest(およびあれば RelayState)を生成し、標準的な HTTP 302リダイレクトを使用してブラウザを IdP SSO サービスにリダイレクトする。
RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、要素のdeflate、base64エンコード、URLエンコードされた値である。
SAMLRequest は、SP の署名鍵を用いて署名することができる。しかし、通常はその必要はない。
3. IdPへのSSOサービスのリクエスト
ユーザ・エージェントは、アイデンティティ・プロバイダの SSO サービスに GET リクエストを発行する:
ここで、SAMLRequestおよびRelayStateパラメータの値は、リダイレクトで提供されたものと同じである。アイデンティティ・プロバイダのSSOサービスは、要素を処理して(URL復号、Base64復号、リクエストのinflateの順に行う)、セキュリティチェックを実行する。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダは任意のメカニズムでユーザーを識別する(詳細は省略)。
4. XHTMLフォームで回答する
SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する。
RelayStateパラメータの値は、ステップ 3から保存されている。 SAMLResponseパラメータの値は、次の要素のbase64エンコーディングである:
5. SPにアサーション・コンシューマー・サービスを要求する
ユーザ・エージェントは、サービス・プロバイダのアサーション・コンシューマー・サービスにPOSTリクエストを発行する。
ここで、SAMLResponseおよびRelayStateパラメータの値は、ステップ 4のXHTMLフォームから取得される。
6. ターゲット・リソースにリダイレクト
アサーション・コンシューマー・サービスは、レスポンスを処理し、サービス・プロバイダでセキュリティ・ コンテキストを作成し、ユーザ・エージェントをターゲット・リソースにリダイレクトする。
7. SPにターゲット・リソースを再リクエスト
ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする(再度):
https://sp.example.com/myresource
8. 要求されたリソースを応答する
セキュリティ・コンテキストが存在するので、サービス・プロバイダはリソースをユーザ・エージェントに返す。
これは、SAML 2.0 WebブラウザSSOプロファイル(SAMLProf)を比較的簡単に導入したもので、サービス・プロバイダー(SP)とアイデンティティ・プロバイダー(IdP)の両方がHTTP POSTバインディングを使用している。
メッセージ・フローは、SPのセキュアなリソースへのリクエストから始まる。
1. SPでターゲット・リソースをリクエスト
プリンシパルは、(HTTPユーザーエージェントを介して)サービスプロバイダにターゲットリソースを要求する:
https://sp.example.com/myresource
サービス・プロバイダは、ターゲット・リソースに代わってセキュリティ・チェックを実行する。 サービスプロバイダーに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–7をスキップする。
2. XHTMLフォームで回答する
サービス・プロバイダは、XHTMLフォームを含むドキュメントで応答する:
RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、以下の要素のbase64エンコーディングである。
要素がXHTMLフォームに挿入される前に、まずbase64エンコードされる。
3.IdP での SSO サービスのリクエスト
ユーザーエージェントは、アイデンティティ・プロバイダの SSO サービスに POST リクエストを発行する:
ここで、SAMLRequestおよびRelayStateパラメータの値は、ステップ 2のXHTMLフォームから取得される。SSOサービスは、要素を処理して(リクエストのURLデコード、base64デコード、inflateの順に行う)、セキュリティ・チェックを実行する。 ユーザが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザを識別する(詳細は省略)。
4. XHTMLフォームで応答する
SSOサービスはリクエストを検証し、XHTMLフォームを含むドキュメントで応答する:
RelayStateパラメータの値は、ステップ 3から保存されている。 SAMLResponseパラメータの値は、次の要素のbase64エンコーディングである:
5. SPにアサーション・コンシューマー・サービスを要求する
ユーザ・エージェントは、サービス・プロバイダのアサーション・コンシューマ・サービスに POST リクエストを発行する。
ここで、SAMLResponseおよびRelayStateパラメータの値は、ステップ 4のXHTMLフォームから取得される。
6. ターゲット・リソースへのリダイレクト
アサーション・コンシューマー・サービスは、レスポンスを処理し、サービス・プロバイダでセキュリティ・ コンテキストを作成し、ユーザ・エージェントをターゲット・リソースにリダイレクトする。
7. SPに対象のリソースを再リクエスト
ユーザーエージェントは、サービスプロバイダーにターゲット・リソースをリクエストする(再度)。
https://sp.example.com/myresource
8. 要求されたリソースで応答する
セキュリティコンテキストが存在するため、サービスプロバイダはリソースをユーザーエージェントに返す。
これは、SAML 2.0 Web Browser SSO Profile(SAMLProf)の複雑な展開であり、サービスプロバイダ(SP)とアイデンティティプロバイダ(IdP)の両方がHTTPアーティファクト・バインディングを使用している。 両方のアーティファクトは、HTTP GET でそれぞれのエンドポイントに配信される。
メッセージの流れは、SPのセキュアなリソースへのリクエストから始まる:
1. SPでターゲット・リソースをリクエスト
プリンシパルは、(HTTPユーザーエージェントを介して)サービス・プロバイダにターゲットリソースを要求する:
https://sp.example.com/myresource
サービス・プロバイダは、ターゲットリソースに代わって、セキュリティ チェックを実行する。 サービス・プロバイダに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–11をスキップする。
2. IdPのシングルサインオン(SSO)サービスへのリダイレクト
サービス・プロバイダは、ユーザーエージェントをアイデンティティ・プロバイダのシングルサインオン(SSO)サービスにリダイレクトする。 リダイレクトURLには、RelayStateパラメータとSAMLartパラメータが付加される。
3. IdPへのSSOサービスのリクエスト
ユーザ・エージェントは、アイデンティティ・プロバイダに SSO サービスを要求する。
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token
ここで、tokenは、サービスプロバイダで保持されている状態情報への不透明な参照であり、artifact_1は、SAMLアーティファクトであり、いずれもステップ 2で発行されたものである。
4. SPでアーティファクト・レゾリューション・サービスをリクエスト
SSOサービスは、SAML SOAPメッセージにバインドされた要素をサービスプロバイダのアーティファクト解決サービスに送信することで、アーティファクトの参照先を見に行く(dereference)。
ここで、要素の値は、ステップ3で送信されたSAMLアーティファクトである。
5. SAML AuthnRequestで応答
サービスプロバイダのアーティファクト解決サービスは、SAML SOAPメッセージにバインドされた要素(要素を含む)を、アイデンティティ・プロバイダのSSOサービスに返す:
SSOサービスは、要素を処理し、セキュリティチェックを行う。 ユーザーが有効なセキュリティ・コンテキストを持っていない場合、アイデンティティ・プロバイダはユーザーを識別する(詳細は省略)。
6. アサーション・コンシューマー・サービスへのリダイレクト
アイデンティティ・プロバイダの SSO サービスは、ユーザ・エージェントをサービス・プロバイダのアサーション・コンシューマ・サービスにリダイレクトする。 以前の RelayState パラメータと新しい SAMLart パラメータがリダイレクト URL に追加される。
7. SPにアサーション・コンシューマー・サービスを要求する