SAML NameIDとNameID Format
NameIDは「このユーザーをどのIDで表すか」を決める識別子です。NameID Formatを適切に選ぶことで、安定した認証連携ができます。
🪪 NameIDとは
通常はResponse内のAssertionのSubjectにある識別子です。SPは検証済みのAssertionから読み取り、発行元も含めてアカウントに対応付けます。
押さえるポイント
- ✅ IdPが発行し、SPが受け取りユーザーと紐づける
- ✅ 固定IDを使うか、その都度変わるIDを使うかでFormatを選択
- ✅ 別の属性（email など）をNameIDに流用するケースもある
📑 代表的なNameID Format
どの形式でユーザーを識別するかを事前に決め、IdP/SPで揃えることが重要です。
指定できる主なNameID Format
| Format | 特徴/用途 |
|---|---|
| persistent | 長期利用する不透明な識別子。通常はIdPとSPの組に対応し、サービスをまたぐ共通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などの変更されにくいIDを検討する。emailAddressは変更・再割当があるため、メール値だけで既存アカウントを自動統合しない
- 🧭 プライバシー重視で追跡性を下げたい: transient
- 🧭 IdP/ SPの実装が対応しているFormatを事前に確認する
⚙️ 設定時の注意点
NameID Format のミスマッチは認証失敗の典型原因です。設定を合わせておきましょう。
NameIDPolicy と要求
AuthnRequestのNameIDPolicyで希望するFormatを明示できます。対応していないFormatを要求すると認証は失敗します。
- NameIDPolicyでFormatを指定し、IdPがサポートしない場合はエラーになることを理解する
- persistentを要求する場合、IdPが生成・保持できるか事前に確認する
- unspecifiedを使う場合も、実質どの値が来るかは合意しておく
NameIDの再発行/変更
識別子の変更・終了通知はManageNameIDRequest/Responseです。NameIDMappingRequest/Responseは同じ主体の別形式・別名前空間の識別子を求める仕組みで、変更通知とは別です。対応状況を確認して移行手順を決めます。
- persistentを再発行する場合、既存ユーザーとの突合せ手順を決めておく
- ManageNameIDに非対応の場合は、連携先と合意したアカウント移行・連絡手順を用意する
- NameID変更がログインに与える影響をテスト環境で確認してから本番反映する
よくある落とし穴
- ⚠️ IdPとSPで期待するNameID Formatがずれていると認証に失敗する
- ⚠️ emailAddressを使う場合、ドメイン変更でIDが変わるリスクがある
- ⚠️ persistentを使う場合、再発行時に既存ユーザーとの突合せルールが必要
🧯 トラブルシュートのヒント
フォーマットの不一致やメタデータの設定ズレを優先的に確認すると切り分けが早くなります。
確認項目
- 🔍 Response > Assertion > Subject > NameIDのFormatを確認する（暗号化時は復号後に確認）
- 🔍 AuthnRequestのNameIDPolicyと、メタデータのNameIDFormatを区別して確認する
- 🔍 SP側で受け入れるNameID Formatを制限していないか