SAML NameIDとNameID Format
NameIDは「このユーザーをどのIDで表すか」を決める識別子です。NameID Formatを適切に選ぶことで、安定した認証連携ができます。
🪪 NameIDとは
SAML ResponseのSubjectに含まれるユーザー識別子。SPがユーザーを特定する根拠になります。
押さえるポイント
- ✅ IdPが発行し、SPが受け取りユーザーと紐づける
- ✅ 固定IDを使うか、その都度変わるIDを使うかでFormatを選択
- ✅ 別の属性（email など）をNameIDに流用するケースもある
📑 代表的なNameID Format
どの形式でユーザーを識別するかを事前に決め、IdP/SPで揃えることが重要です。
指定できる主なNameID Format
| Format | 特徴/用途 |
|---|---|
| persistent | 長期的に変わらないID。ユーザー紐づけを安定させたいときに利用。 |
| transient | セッションごとに変わる一時ID。プライバシー重視で恒久IDを残したくない場合に有効。 |
| emailAddress | メールアドレスをそのままNameIDにする形式。外部SaaS連携で多用。 |
| unspecified | 形式を固定しない汎用指定。IdP/SPの合意が前提。 |
| X509SubjectName | 証明書のSubject名をNameIDに利用。証明書ベースの環境で使用。 |
| WindowsDomainQualifiedName | DOMAIN\user 形式。Windows/AD連携で利用。 |
| kerberos | KerberosプリンシパルをNameIDに利用。Kerberos連携環境で使用。 |
| entity | エンティティIDをNameIDとして扱う形式。限定的なケースで利用。 |
選択の目安
安定性を優先するか、プライバシーを優先するかで選択が変わります。
- 🧭 既存アカウントと確実に突き合わせたい: persistent または emailAddress
- 🧭 プライバシー重視で追跡性を下げたい: transient
- 🧭 IdP/ SPの実装が対応しているFormatを事前に確認する
⚙️ 設定時の注意点
NameID Format のミスマッチは認証失敗の典型原因です。設定を合わせておきましょう。
NameIDPolicy と要求
AuthnRequestのNameIDPolicyで希望するFormatを明示できます。対応していないFormatを要求すると認証は失敗します。
- NameIDPolicyでFormatを指定し、IdPがサポートしない場合はエラーになることを理解する
- persistentを要求する場合、IdPが生成・保持できるか事前に確認する
- unspecifiedを使う場合も、実質どの値が来るかは合意しておく
NameIDの再発行/変更
NameIDMappingRequest/ResponseでNameIDを再発行するフローがありますが、未対応IdPも多いため運用での再発行ルールを決めておくと安心です。
- persistentを再発行する場合、既存ユーザーとの突合せ手順を決めておく
- Mappingリクエストに非対応の場合、IdP管理者の手動変更と連絡フローを用意する
- NameID変更がログインに与える影響をテスト環境で確認してから本番反映する
よくある落とし穴
- ⚠️ IdPとSPで期待するNameID Formatがずれていると認証に失敗する
- ⚠️ emailAddressを使う場合、ドメイン変更でIDが変わるリスクがある
- ⚠️ persistentを使う場合、再発行時に既存ユーザーとの突合せルールが必要
🧯 トラブルシュートのヒント
フォーマットの不一致やメタデータの設定ズレを優先的に確認すると切り分けが早くなります。
確認項目
- 🔍 Response の Subject > NameID に期待するFormatが入っているか
- 🔍 メタデータの NameIDPolicy / Format が一致しているか
- 🔍 SP側で受け入れるNameID Formatを制限していないか