MS_SAMLProtocols

SAML Protocols

• 戻る（SAML Core）
  • SAML Protocols
  • SAML Assertions
  • SAML Signature or Encryption

概要

汎用認証サイトに SAML2.0を実装するため仕様を読む。

• ターゲットは SP Initiated な Web Browser SSO Profile に絞る。
• ココに書いた情報は、SAML Core の Protocols の範囲。

以下、詳細

以下について説明する。

• トランスポートプロトコルを使用して
• プロトコルメッセージをトランスポートする特定の手段

※ saml-core-2.0-os.pdf の内容が微妙なので、

• サンプルをベースにそれぞれの仕様を確認する。
• 医療分野共通認証基盤整備コンソーシアムのPDFの内容がワリとイイ

移行メモ: 上の「トランスポートする特定の手段」は
SAML Bindings の守備範囲である。
Protocols が定義するのは**メッセージの中身（要求 / 応答の構造と処理規則）**であり、
それをどう運ぶかは Bindings が担う。

SAML 要求・応答メッセージ

要求メッセージ（AuthnRequest）

SP は IdP に認証を要求する <AuthnRequest> メッセージを発行

Attribute

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	ID	Required	xs:ID	-	400 ビット以内の ID。応答の InResponseTo 属性の値と一致させる。	○
2	Version	Required	-	"2.0"	バージョンを指定	○
3	IssueInstant	Required	UTC time	-	発行時刻を指定	○
4	ProtocolBinding	Optional	URI	-	応答の Protocol Binding を識別する参照 URI（AssertionConsumerServiceURL と併用）	○（Redirect or Post）
5	AssertionConsumerServiceURL	Optional	URI	-	応答の URL を識別する参照 URI（ProtocolBinding と併用）	○（完全一致）
6	AssertionConsumerServiceIndex	Optional	unsignedShort	-	応答の URL を識別するインデックス（4・5 と排他的でメタデータと併用）	-
7	AttributeConsumingServiceIndex	Optional	unsignedShort	-	IdP に要求するユーザ属性グループのインデックス（メタデータと併用）	-
8	Destination	Optional	URI	-	IdP の URI	-
9	ProviderName	Optional	string	-	SP の可読名称	-
10	Consent	Optional	URI	urn:oasis:names:tc:SAML:2.0:consent:unspecified	利用者から得られている同意の有無や条件	-
11	ForceAuthn	Optional	boolean	false	true の場合、IdP は認証情報を再要求	-
12	IsPassive	Optional	boolean	false	true の場合、IdP はログイン UI を表示してはならない。	-

補足（AssertionConsumerServiceURL の検証は必須）: この属性は
OAuth の redirect_uri に相当する。

IdP がこれを検証せずに応答先として使うと、
攻撃者が指定した URL にアサーションを送り込める
（オープン リダイレクタ相当の脆弱性）。

対策は OAuth と同じで、メタデータに登録済みの値との完全一致を要求する。
「登録済みプレフィックスで前方一致」も危険である。

なお、Destination 属性は「このメッセージの宛先」であり、
受信側は自分のエンドポイント URL と一致することを検証する
（署名付きメッセージのリレー攻撃を防ぐ）。

Elements

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	saml:Issuer	Optional	URI	-	SP の URI	-（署名があるので）
2	ds:Signature	Optional	-	-	XML署名	○
3	saml:Subject	Optional	-	-	Subject を入力する（login_hint 的な。）	○
4	samlp:NameIDPolicy	Optional	-	-	Subject の制約条件を指定（Format、SPNameQualifier、AllowCreate）	○（Format）
5	samlp:RequestedAuthnContext	Optional	-	-	認証コンテキストに関する要件を指定	○
6	saml:Conditions	Optional	-	-	アサーション構築プロセスの入力	-
7	samlp:Scoping	Optional	-	-	SP が信頼する IdP リスト	-
8	samlp:Extensions	Optional	-	-	拡張ステートメント	-

移行メモ: <Issuer> は Core のスキーマ上は Optional だが、
**Web Browser SSO Profile では必須（MUST）**である。
元ページの「-（署名があるので）」は汎用認証サイトの実装判断だが、
IdP 側から見れば「どの SP からの要求か」を知る唯一の手段であり、
署名検証に使う鍵を選ぶためにも必要になる。

応答メッセージ（Response）

IdP が認証アサーションを入れた <Response> メッセージを応答する。

Attribute

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	ID	Required	xs:ID	-	400 ビット以内の ID	○
2	Version	Required	-	"2.0"	バージョンを指定	○
3	IssueInstant	Required	UTC time	-	発行時刻を指定	○
4	InResponseTo	Optional	xs:NCName	-	対応する要求メッセージの ID。指定の場合、要検証。	○（state 代替）
5	Destination	Optional	URI	-	SP の URI	-
6	Consent	Optional	URI	urn:oasis:names:tc:SAML:2.0:consent:unspecified	利用者から得られている同意の有無や条件	-

補足（InResponseTo は CSRF 対策の要）: InResponseTo は
OAuth の state に相当する。

SP は「自分が発行した <AuthnRequest> の ID を覚えておき、
返ってきた InResponseTo と突き合わせる」必要がある。
突き合わせを省略すると、攻撃者が用意したアサーションを
被害者のブラウザに POST させるログイン CSRF が成立する。

なお IdP 開始 SSO では InResponseTo が存在しない。
「無ければ検証しない」という実装にすると、
InResponseTo を削るだけで検証を回避できてしまう。
SP 開始しか受け付けないなら、無い応答は拒否すること。

Elements

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	saml:Issuer	Optional	URI	-	IdP の URI	-（署名があるので）
2	ds:Signature	Optional	-	-	XML署名	○
3	samlp:Status	Required	-	-	処理ステータスコード	○
4	saml:Assertion	Optional	-	-	認証アサーション	○

移行メモ（正誤）: <samlp:Status> は元ページで Optional と
なっていたが、スキーマ上 Required である
（StatusResponseType の必須の子要素）。

共通的なメッセージ

<Response> と <Assertion> に共通

Status

• Elements

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	samlp:StatusCode	Required	URI	-	ステータスを表すコードを指定（下記参照）	○
2	samlp:StatusMessage	Optional	string	-	オペレータに返すメッセージ	○
3	samlp:StatusDetail	Optional	-	-	付加情報	-

StatusCode

• 以下の様に、第一・第二レベルを指定できる。

<samlp:Status>
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/>
  </samlp:StatusCode>
  <samlp:StatusMessage>Authentication Failed</samlp:StatusMessage>
  <samlp:StatusDetail>
    <Cause>org.sourceid.websso.profiles.idp.FailedAuthnSsoException</Cause>
  </samlp:StatusDetail>
</samlp:Status>

• Attribute

#	パラメタ	要否	値	既定値	内容	汎用認証サイト
1	Value	Required	URI	-	ステータスコードの参照 URI 値	○

• 許容値（接頭辞 urn:oasis:names:tc:SAML:2.0:status:）

  • 第一レベル

#	ステータス	値	説明
1	成功	Success
2	リクエスタの失敗	Requester	リクエスタでの失敗
3	レスポンダの失敗	Responder	レスポンダでの失敗
4	バージョン不整合	VersionMismatch	要求メッセージのバージョンは処理できない。

• 第二レベル
  適合するものが無い場合は、StatusMessage、StatusDetail を使用してもよさそう。

  AuthnFailed / InvalidAttrNameOrValue / InvalidNameIDPolicy /
  NoAuthnContext / NoAvailableIDP / NoPassive / NoSupportedIDP /
  PartialLogout / ProxyCountExceeded / RequestDenied /
  RequestUnsupported / RequestVersionDeprecated /
  RequestVersionTooHigh / RequestVersionTooLow /
  ResourceNotRecognized / TooManyResponses / UnknownAttrProfile /
  UnknownPrincipal / UnsupportedBinding

移行メモ（正誤）: 元ページの第一レベルの表には
「4 | 認証の失敗 | 下記参照 | レスポンダ（IdP）での失敗」という行があったが、
第一レベルの StatusCode は 4 つ（Success / Requester /
Responder / VersionMismatch）しかない。
AuthnFailed 等は第二レベルであるため、上表から当該行を除いた。

認証要求の処理規則

以下の処理規則は、レスポンダに、

• このプロトコル交換のすべてのプロファイルにわたって不変の動作として適用される。
• 基礎となる SAML 要求 / 応答メッセージに関連する他のすべての処理規則も遵守する。

認証

• 認証プロセスを開始するか、プレゼンターと追加のメッセージ交換を行う可能性がある。
• 独自の <AuthnRequest> メッセージでプレゼンターを別の IdP に誘導（プロキシ）する
  ことが含まれる。

Assertion

<saml:Subject>

• Assertion には、プレゼンターを表す <saml:Subject> 要素が含まれている必要がある。
• リクエストに <saml:Subject> 要素が含まれている場合、
  レスポンスの <saml:Subject> 要素はこれに強く一致している必要がある。

<NameIDPolicy>

• 認証した Subject の ID を <saml:Subject> の <saml:NameID> で返す。
• 種類と形式は、<NameIDPolicy> 要素を使用して SP が要求できるが、
  最終的には IdP によって決定される。

<saml:AuthnStatement>要素以下

少なくとも 1 つの <saml:AuthnStatement> を含む Assertion に、以下を含める必要がある。

• <saml:SubjectConfirmation>
• <saml:AudienceRestriction>

Status > StatusCode

なお、認証処理が失敗するなどして、Assertion を提供できない場合は、
以下の <StatusCode> を返す。

• urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
• urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal

レスポンス

最終的に <AuthnRequest> に、以下の要素を含む <Response> メッセージで
応答しなければならない。

• Assertion — 仕様を満たす 1 つ以上の <Assertion> 要素を含む。
• Status — または発生したエラーを説明する <Status> 要素を含む。

補足（エラー時の情報漏えい）: <StatusMessage> /
<StatusDetail> にスタックトレースや内部クラス名を入れてはならない。
上の例（org.sourceid.websso.profiles.idp.FailedAuthnSsoException）は
まさにそれに当たり、製品名・実装の内部構造が外部へ漏れる。

また、UnknownPrincipal（ユーザが存在しない）と
AuthnFailed（パスワードが違う）を区別して返すと
ユーザ列挙（アカウント存在確認）の手掛かりになる。
外部向けには一律 AuthnFailed を返し、
詳細はサーバ側のログにのみ記録するのが安全である。

参考

https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

3 SAML Protocols

3.1 Schema Header and Namespace Declarations

3.2 Requests and Responses
3.2.1 Complex Type RequestAbstractType
3.2.2 Complex Type StatusResponseType
3.2.2.1 Element <Status>
3.2.2.2 Element <StatusCode>
3.2.2.3 Element <StatusMessage>
3.2.2.4 Element <StatusDetail>

3.3 Assertion Query and Request Protocol
3.3.1 Element <AssertionIDRequest>
3.3.2 Queries
3.3.2.1 Element <SubjectQuery>
3.3.2.2 Element <AuthnQuery>
3.3.2.2.1 Element <RequestedAuthnContext>
3.3.2.3 Element <AttributeQuery>
3.3.2.4 Element <AuthzDecisionQuery>
3.3.3 Element <Response>
3.3.4 Processing Rules

3.4 Authentication Request Protocol
3.4.1 Element <AuthnRequest>
3.4.1.1 Element <NameIDPolicy>
3.4.1.2 Element <Scoping>
3.4.1.3 Element <IDPList>
3.4.1.3.1 Element <IDPEntry>
3.4.1.4 Processing Rules
3.4.1.5 Proxying
3.4.1.5.1 Proxying Processing Rules

3.5 Artifact Resolution Protocol
3.5.1 Element <ArtifactResolve>
3.5.2 Element <ArtifactResponse>
3.5.3 Processing Rules

3.6 Name Identifier Management Protocol
3.6.1 Element <ManageNameIDRequest>
3.6.2 Element <ManageNameIDResponse>
3.6.3 Processing Rules

3.7 Single Logout Protocol
3.7.1 Element <LogoutRequest>
3.7.2 Element <LogoutResponse>
3.7.3 Processing Rules
3.7.3.1 Session Participant Rules
3.7.3.2 Session Authority Rules

3.8 Name Identifier Mapping Protocol
3.8.1 Element <NameIDMappingRequest>
3.8.2 Element <NameIDMappingResponse>
3.8.3 Processing Rules

---

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, SAML