SAML 2.0
これは、SAML 2.0 WebブラウザSSOプロファイル(SAMLProf)を比較的簡単に導入したもので、サービス・プロバイダー(SP)とアイデンティティ・プロバイダー(IdP)の両方がHTTP POSTバインディングを使用している。
メッセージ・フローは、SPのセキュアなリソースへのリクエストから始まる。
1. SPでターゲット・リソースをリクエスト
プリンシパルは、(HTTPユーザーエージェントを介して)サービスプロバイダにターゲットリソースを要求する:
サービス・プロバイダは、ターゲット・リソースに代わってセキュリティ・チェックを実行する。 サービスプロバイダーに有効なセキュリティコンテキストがすでに存在する場合は、ステップ2–7をスキップする。
2. XHTMLフォームで回答する
サービス・プロバイダは、XHTMLフォームを含むドキュメントで応答する:
RelayStateトークンは、サービスプロバイダで保持している状態情報への不透明な参照である。 SAMLRequestパラメータの値は、以下の<samlp:AuthnRequest>要素のbase64エンコーディングである。
<samlp:AuthnRequest>要素がXHTMLフォームに挿入される前に、まずbase64エンコードされる。
3.IdP での SSO サービスのリクエスト
ユーザーエージェントは、アイデンティティ・プロバイダの SSO サービスに POST リクエストを発行する:
ここで、SAMLRequestおよびRelayStateパラメータの値は、ステップ 2のXHTMLフォームから取得される。
SAML 1.1 WebブラウザSSOプロファイルはIdentity Provider (IDP)によって開始(initiate)される。つまり、 一方的な<samlp:Response>要素がアイデンティティ・プロバイダから(ブラウザ経由で)サービスプロバイダに送信される。(接頭辞 samlp:はSAMLプロトコルの名前空間を示す。)
ただし、SAML 2.0 では、流れはサービス・プロバイダから始まり、サービス・プロバイダは アイデンティティ・プロバイダに明示的な認証要求を発行する。結果として生じる「認証要求プロトコル」は、SAML 2.0 の重要な新機能である。
プリンシパル(またはプリンシパルの代理を務めるエンティティ)が認証ステートメントを含むアサーションの取得を希望する場合、<samlp:AuthnRequest>要素がアイデンティティ・プロバイダに送信される:
上記の<samlp:AuthnRequest>要素は、暗黙的に 認証ステートメントを含むアサーションを要求するものであり、サービス・プロバイダー(https://sp.example.com/SAML2) によって明確に発行され、その後(ブラウザを介して)アイデンティティ・プロバイダに提示された。 アイデンティティ・プロバイダは(必要であれば)プリンシパルを認証し、認証応答を発行する。認証応答は、(再びブラウザを介して)サービス・プロバイダに送信される。
受信時には、元のメッセージを復元するために、このプロセスを逆に行う。
例えば、上記の <samlp:AuthnRequest>メッセージをエンコードすると、次のようになる:
上記のメッセージ(可読性のためにフォーマットされている)は、追加のセキュリティのために署名される場合もある。実際には、<samlp:AuthnRequest>に含まれるすべてのデータ(SP ID を含むIssuerやNameIDPolicyなど)は、事前に IdP と SP の間で(手動での情報交換や SAMLメタデータを介して)合意されている。その場合、リクエストへの署名はセキュリティ上の制約とはならない。<samlp:AuthnRequest>に、アサーション・コンシューマー・サービスのURLなど、IdPが事前に把握していない情報が含まれている場合、セキュリティの観点からリクエストへの署名が推奨される。