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

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

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

アサーション内では、一連の内部要素が以下のステートメントを記述する。

• 認証：Subject は特定の時点で特定の手段によって認証されました。
• 属性：Subject は提供された属性に関連付けられています。
• 許可決定：指定されたリソースにアクセスする要求が許可または拒否されました。

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

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

補足（表中の「汎用認証サイト」列）: この列は、
Open棟梁プロジェクトの汎用認証サイト（Multi-purpose Authentication Site）が
実装対象としたかどうかを示す。仕様上の必須／任意とは別物である。

移行メモ（正誤）: 元ページは ds:Signature を Required としていたが、
スキーマ上は Optional である
（署名を必須にしているのは Web Browser SSO Profile の
POST Binding 使用時の規定であって、<Assertion> 自体の要件ではない）。

また要素名を saml:AuthzStatement としていたが、
正しくは saml:AuthzDecisionStatement である。

• Elements

• Attribute

• Format に指定できる主な値（詳細は SAML Core）

移行メモ（正誤）: 元ページの表は Format の値がすべて
urn:oasis:names:tc:SAML:**1.1**:... で始まっており、
かつ persistent が 2 行（Pairwise UserID と一時的）並んでいた。
正しくは

• entity / persistent / transient は SAML 2.0 の名前空間
• unspecified / emailAddress は 1.1 の名前空間
• 「一時的」は persistent ではなく transient

であるため、上表のとおり正した。

また SPProvidedID は「？」となっていたが、
SP がその Subject に対して用いる別名を IdP が知っている場合に、
IdP 側が付記するための属性である。

• Attribute

• Elements

• Attribute

移行メモ（正誤）: 2 点訂正する。

• InResponseTo の説明が「Response メッセージの ID」となっていたが、
  これは「対応する要求（<AuthnRequest>）の ID」である。
• Address の説明が「IdP のエンドポイント」となっていたが、
  仕様上は「アサーションを提示している側（＝ブラウザ）のアドレス」である。

なお、bearer を使う Web Browser SSO Profile では
**NotBefore を含めてはならない（MUST NOT）**という規定がある。

• Attribute

• Elements

※ AnyNumber：型が違う時に要否が変わる場合は、この表現。

補足（<AudienceRestriction> の検証は必須）: <Audience> は
JWT の aud クレームに相当する。

SP は「自分の EntityID が <Audience> に含まれること」を必ず検証する。
ここを省くと、別の SP 向けに発行されたアサーションを受理してしまい、
悪意ある SP がユーザになりすませる。

<ProxyRestriction> は「IdP がプロキシとして再発行できる回数」を制限する
ものだが、実装はほとんど無い。

• Attribute

• Elements

移行メモ: 元ページは Elements の番号が「1, 1」と重複していたので
「1, 2」に改めた。

補足: SessionIndex は「Single Logout をサポートするなら必要」であり、
<LogoutRequest> でどのセッションを落とすかを指定するのに使う
（SAML Profilesを参照）。

AuthnInstant は「いつ認証したか」であって
「アサーションをいつ作ったか（IssueInstant）」ではない。
SSO では既存セッションを流用するため、
AuthnInstant が数時間前ということは普通に起こる。
再認証を強制したい場合は <AuthnRequest> の ForceAuthn を使う。

• Elements

移行メモ: 元ページで「？」となっていた AuthnContextDecl /
AuthnContextDeclRef は、認証方式を URI クラスで丸めるのではなく、
宣言（Declaration）そのものを記述／参照するための要素である。
実装はほぼ無く、通常は AuthnContextClassRef だけを使う。

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

2 SAML Assertions

2.1 Schema Header and Namespace Declarations

2.2 Name Identifiers
2.2.1 Element <BaseID>
2.2.2 Complex Type NameIDType
2.2.3 Element <NameID>
2.2.4 Element <EncryptedID>
2.2.5 Element <Issuer>

2.3 Assertions
2.3.1 Element <AssertionIDRef>
2.3.2 Element <AssertionURIRef>
2.3.3 Element <Assertion>
2.3.4 Element <EncryptedAssertion>

2.4 Subjects
2.4.1 Element <Subject>
2.4.1.1 Element <SubjectConfirmation>
2.4.1.2 Element <SubjectConfirmationData>
2.4.1.3 Complex Type KeyInfoConfirmationDataType
2.4.1.4 Example of a Key-Confirmed <Subject>

2.5 Conditions
2.5.1 Element <Conditions>
2.5.1.1 General Processing Rules
2.5.1.2 Attributes NotBefore and NotOnOrAfter
2.5.1.3 Element <Condition>
2.5.1.4 Elements <AudienceRestriction> and <Audience>
2.5.1.5 Element <OneTimeUse>
2.5.1.6 Element <ProxyRestriction>

2.6 Advice
2.6.1 Element <Advice>

2.7 Statements
2.7.1 Element <Statement>
2.7.2 Element <AuthnStatement>
2.7.2.1 Element <SubjectLocality>
2.7.2.2 Element <AuthnContext>
2.7.3 Element <AttributeStatement>
2.7.3.1 Element <Attribute>
2.7.3.1.1 Element <AttributeValue>
2.7.3.2 Element <EncryptedAttribute>
2.7.4 Element <AuthzDecisionStatement>
2.7.4.1 Simple Type DecisionType
2.7.4.2 Element <Action>
2.7.4.3 Element <Evidence>

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