SAML属性の扱いとマッピング

📄 属性の基本

メールアドレスや氏名、ロールなどをSAML Responseに載せることで、アプリ側でアカウント紐づけや権限付与ができます。

代表的な属性

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

🧩 属性のマッピング

IdPから届く属性名と、アプリ内部のユーザー項目を対応づけます。

マッピング時の注意

• 🔍 IdPごとに属性名・命名空間が異なる（例: AzureAD, Okta, Google Workspace）
• 🔍 必要な属性が欠けているとログインに失敗するため、必須項目を事前に合意する
• 🔍 環境（本番/検証）で属性値が違う場合があるので、検証環境で確認する

⚙️ IdPごとの違いと設定のコツ

IdPによって属性名や命名空間が異なるため、事前に仕様をそろえることが重要です。

Attribute Profile

SAMLでは属性のスキーマを定義するAttribute Profileが用意されています（例: X.500/LDAP属性プロファイル）。標準プロファイルを前提にすると互換性が上がります。

• X.500/LDAP Attribute Profile など標準プロファイルを参照し、属性名・命名空間を揃える
• IdP依存の独自属性を使う場合は、対応するSP側のマッピングを明示する
• 標準プロファイル準拠かどうかをIdP/ SPで合意しておく

IdPごとの特徴

• 🔧 AzureAD: EntityIDがURL形式。属性名に独自の命名空間が入ることが多い
• 🔧 Google Workspace: 独自の名前空間で、属性名を調整する必要がある
• 🔧 Okta/Keycloak: 柔軟だが設定項目が多い。AttributeStatementの設定範囲が広い

SP設定のヒント

• 🛠️ 受け入れる属性名を明示し、ドキュメント化して共有する
• 🛠️ メタデータにAttributeConsumingServiceを定義できる場合は設定しておく
• 🛠️ テナントや環境ごとの差分を記録し、サポート窓口と共有しておく