SCIMを有効化したが、異動・削除まで正しく動くか分からない

結論は、SCIM接続の成功ではなく、Joiner・Mover・Leaverのテスト結果を受入条件にすることです。照合属性、割り当て、属性マッピング、対象外化、SaaS側の実装差を一つずつ確認します。

作成成功だけでは足りない理由

プロビジョニングには、接続、照合、スコープ、属性変換、SaaS側APIの動作が関係します。初回同期で新規ユーザーが作成されても、部署変更、姓変更、休職、グループ離脱、退職が同じように処理されるとは限りません。

見落としやすい設計点

照合属性

メールアドレスやUPNが将来変更される場合、一意性と不変性を確認します。誤った照合は、重複作成や別ユーザーへの更新につながるため、既存ユーザーを含めて確認が必要です。

スコープ

全ユーザー、割り当て済みユーザー、グループ、属性フィルターのどれを使用するかで対象が変わります。動的グループを使う場合は、メンバーシップ評価時間も全体の反映時間に影響します。

対象外化の操作

割り当て解除、グループ離脱、スコープフィルター不一致、Entra IDでの無効化が、SaaS側でどの操作になるかを確認します。ギャラリーアプリと独自SCIM実装では挙動が異なる場合があります。

解決までの進め方

1. 既存状態を取得するEntra IDの割り当てとSaaS側ユーザーを突合し、重複・未管理・共有IDを分けます。
2. 照合と属性を決める一意キー、必須属性、部署・役職・ライセンス・ロールの変換を表にします。
3. スコープを固定する直接割り当て、対象グループ、除外条件、動的グループの評価を明確にします。
4. ライフサイクルを試験する入社、異動、休職、退職、再雇用、誤割り当て解除をテストします。
5. ログの見方を決めるプロビジョニングログ、SaaS側ログ、エラー対応者、再試行条件を定義します。
6. 変更管理へ組み込む属性やグループ設計の変更時に、影響確認と再試験を必須にします。

相談が必要な状態

• 初回作成以外のテストをしていない
• 照合属性を選んだ理由が記録されていない
• 入れ子グループを含む割り当て構成になっている
• プロビジョニングログの失敗を定期確認していない
• SaaS側の削除・無効化仕様が不明