SAML署名と属性の基本

🔏 SAML署名と属性

SAML Responseは、XML署名によって改ざんから保護され、さらに発行元のIdPが正当なものであることを証明できるようになっています。
この仕組みにより、偽造されたレスポンスを受け取ってしまうリスクを防ぎ、安全なシングルサインオンが実現されます。
署名の検証には、IdPが提供する公開鍵証明書が使われ、SPはその情報をもとに署名の正当性を確認します。

署名の構造

• 📌 署名は ds:Signature 要素内に記述される
• 📌 署名対象は Assertion または全体の Response
• 📌 署名には証明書（X.509）が使われる

検証時の注意

• ⚠️ サーバーの時刻ズレがあると NotBefore/NotOnOrAfter の検証に失敗することがある
• ⚠️ 証明書の正当性・有効期限も要チェック
• ⚠️ SP側が受け取るべきEntityIDと一致しているか確認

📄 属性（Attribute）の扱い

SAMLのResponseにはユーザーの属性情報（email, roleなど）を含めることができます。

代表的な属性

• ✅ email: ログインIDや通知先に利用される
• ✅ givenName / surname: 表示名として利用される
• ✅ groups / roles: アクセス制御の根拠に

属性のマッピング

• 🧩 SP側で属性名と内部ユーザー項目を対応づける必要がある
• 🧩 IdPにより属性名の命名や命名空間が異なる（例: AzureAD, Okta）
• 🧩 必要な属性が送られていないとログインに失敗するケースも

⏱️ 条件・有効期限とエラー

SAMLのAssertionには有効期限や条件が記述されており、SPはこれらを検証します。

Assertionの条件

• 📎 NotBefore：この時刻より前は無効
• 📎 NotOnOrAfter：この時刻以降は無効（トークンの期限）
• 📎 Audience：許可されたSPのEntityIDと一致しているか

よくあるエラー例

• 🧯 署名検証エラー（証明書不一致・署名範囲ミス）
• 🧯 XML解析エラー（Deflate展開やBase64デコード失敗）
• 🧯 条件不一致エラー（時刻ズレ、Audience不一致）

⚙️ SP / IdP設定の違いと相性

IdPごとの違い

• 🔧 AzureADではEntityIDがURL形式、証明書自動更新に注意
• 🔧 Google Workspaceは名前空間が独自で、属性名も調整が必要
• 🔧 OktaやKeycloakなどは高度なSAML制御が可能だが設定項目が多い

SPの設定注意点

• 🛠️ 受け入れるEntityIDやACS（受信URL）の正確な指定
• 🛠️ メタデータファイルから自動インポート可能かチェック
• 🛠️ SAML Responseの署名検証の有効化・必須化