SAML属性の扱いとマッピング
SAMLでは、ログイン結果と合わせてユーザー属性を渡せます。属性名の違いやマッピングのコツを押さえると、運用がぐっと楽になります。
📄 属性の基本
属性は通常AssertionのAttributeStatementに入ります。署名・発行元・宛先などを検証した後でアカウントや権限に対応付けます。以下のemail等は設定例で、全IdP共通の必須属性名ではありません。
代表的な属性
- ✅ email: ログインIDや通知先に利用される
- ✅ givenName / surname: 表示名として利用される
- ✅ groups / roles: アクセス制御の根拠に
🧩 属性のマッピング
IdPから届く属性名と、アプリ内部のユーザー項目を対応づけます。
マッピング時の注意
- 🔍 IdPごとに属性名・命名空間が異なる（例: Microsoft Entra ID（旧Azure AD）, Okta, Google Workspace）
- 🔍 必要な属性が欠けているとログインに失敗するため、必須項目を事前に合意する
- 🔍 環境（本番/検証）で属性値が違う場合があるので、検証環境で確認する
⚙️ IdPごとの違いと設定のコツ
IdPによって属性名や命名空間が異なるため、事前に仕様をそろえることが重要です。
Attribute Profile
SAMLでは属性のスキーマを定義するAttribute Profileが用意されています（例: X.500/LDAP属性プロファイル）。標準プロファイルを前提にすると互換性が上がります。
- X.500/LDAP Attribute Profile など標準プロファイルを参照し、属性名・命名空間を揃える
- IdP依存の独自属性を使う場合は、対応するSP側のマッピングを明示する
- 標準プロファイル準拠かどうかをIdP/ SPで合意しておく
IdPごとの特徴
- 🔧 属性のNameとNameFormatを実際の連携設定で確認する。entityIDは発行元識別子であり属性名とは別
- 🔧 FriendlyNameだけで属性を識別せず、連携で合意したNameを使う
- 🔧 AttributeValueは複数値になり得る。groups等を単一文字列と決めつけず、欠落・空値・複数値を試験する
SP設定のヒント
- 🛠️ 受け入れる属性名を明示し、ドキュメント化して共有する
- 🛠️ メタデータにAttributeConsumingServiceを定義できる場合は設定しておく
- 🛠️ テナントや環境ごとの差分を記録し、サポート窓口と共有しておく