ニフティで利用しているAWS、Notion、GitHubなどのクラウドやSaaSの管理・運用を担当している石川です。
最近社内で利用しているIDaaS（Identity as a Service）をOneLoginからMicrosoft Entra ID（旧Azure AD）へ移行しました。
同じ「IDaaSの切り替え作業」でも、アプリケーションごとに事情はまったく異なり、想定外のハマりどころが数多くありました。本記事では、実際の移行作業を通じて得られたノウハウを共有します。今回は私が移行したアプリの中でも AWS、GitHub Enterprise、Notion、Redash の4つを例に取りつつ説明していきます。
📍 この記事の読み方
各セクションの内容を 📖 一般論（IDaaS移行全般で押さえるべき知識）と 🔧 体験談（筆者が実際に経験した具体事例）に分けています。
IDaaS移行は「認証設定の差し替え」だけではない
IDaaSを変えるというと、SAML設定のURLや証明書を貼り替えるだけに思えるかもしれません。しかし実際には、以下のような周辺領域にまで影響が波及します。
- ユーザープロパティのマッピング（表示名・属性情報などの紐付け）
- IDaaS/SaaSごとのプロビジョニング（SCIM）挙動差異の把握
- グループ管理の方式変更
- 既存セッションや認証トークンへの影響
- 申請フロー・運用ワークフローの再構築
認証設定そのものよりも、これらの周辺対応のほうがボリュームが大きいです。
1. ユーザープロパティの確認と表示名の定義
📖 一般論
新旧のIDaaSで連携するADやLDAPが同じでも、IDaaS側でのプロパティの持ち方や参照先が異なることがあります。
移行を機にデータが「整理」されることがある
IDaaS移行のタイミングで、AD側の属性を正しいフィールドに寄せ直す（＝綺麗にする）動きが起きることがあります。その上で「名」と「体」が合っていないフィールドがあると、一時的なものか恒常的なものかを事前に確認しておかないと、マッピングで使っている値が突然変わるリスクがあります。
表示名の設計は悩みどころ
SaaS側のユーザー表示名をどう構成するかは意外と悩むポイントです。 SaaSの挙動で特に確認すべき点は以下の2つです。
- ユーザーサジェストはどのフィールドに対して行われているか
- → 表示名でしか行われないとローマ字でユーザーを検索できない、逆も然り
- 同姓同名の区別が付くか
- → ユニークなIDがないと区別が付かない
- → サジェスト時は補助情報としてユニークなIDが出て区別が付くが、設定後は区別が付かない場合もあり
🔧 体験談
検索サジェストやユーザー名オンマウスで、固有ID（メールアドレス or ユーザーID）を併記してくれているアプリに関しては表示名を 姓 名 。そうでないものに関しては 姓 名 メールアドレスのユーザー部 という併記構成にしています。冗長に見えますが、以下のメリットがあります。
- 常に同姓同名の区別がつく
- 漢字の読み方がわからない場合もメールアドレスにあるローマ字で補完できる
💡 TIPS: 通常であれば表示名には英字を推奨します。日本語話者が圧倒的多数の環境では 漢字 + ローマ字 の併記が現実的な妥協点になります。サジェストが前方一致でしか機能しないサービス（Amazon Qなど）もあるので、 ローマ字 + 漢字 のパターンも有効です。
2. Entra IDのグループ管理の注意点
📖 一般論
アプリによっては、全社員にデフォルトで権限を与えるものがあります。その場合、以下のような流れでライセンスが消費されます。
- Entra IDにユーザーが追加される
- Entra IDの特定グループ（動的グループ）に自動で追加される
- そのグループにアプリの利用権限が付与されている
- アプリにユーザーがプロビジョニングされる
- アプリの利用シートが増える
つまり、Entra IDにユーザーを追加すると同時に、アプリのユーザー数が増えてライセンスが消費または追加されます。
事前に確認すべきポイントは2つです。
- 動的グループがどのような基準で構成されているか
- その基準に合致するプロパティが、どのような運用で付与されるか
例えば、Entra ID上でテストアカウントを作成したところ、意図せず動的グループに含まれてしまい、アプリ側のユーザーが自動生成されてライセンスが消費される、といったことが起こり得ます。
🔧 体験談
移行前に確認したところ、人間だけのはずのグループにテストアカウントが含まれていたり、入社の数ヶ月前からアカウントが存在していてライセンスが無駄に消費されていたりするケースがありました。
また過去には、LDAPで更新ミスが発生し大量のユーザーが削除されたことがありました。その際、LDAP連携していたIDaaSおよびプロビジョニング先のアプリ側でも、大量のユーザーが無効化される障害が発生しました。
ユーザーの無効化・削除によって保管データに不可逆な変化が生じるタイプのアプリでは、プロビジョニングの誤削除防止機能を有効化し、閾値を設定することを強く推奨します。
Microsoft Entra プロビジョニング サービス で誤削除防止機能を有効にする – Microsoft Entra ID | Microsoft Learn
3. IDaaSごとに異なるマッピングの仕様
📖 一般論
Entra IDでは、プロビジョニング時の属性マッピングに独自の式を使います。Join()、IIF()、Replace() などの関数を組み合わせてフィルターや値変換を行うことができます。
Microsoft Entra アプリケーションのプロビジョニングで属性マッピングの式を記述するためのリファレンス – Microsoft Entra ID | Microsoft Learn
🔧 体験談
|
1 2 3 |
# 表示名を 姓 名 メールアドレスのユーザー部にする式 Join(" ", [surname], [givenName], Item(Split([mail], "@"), 1)) |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# 特定のグループは同期先では別名に置換、決まったprefixが付いたグループはprefixを置換して同期 IIF( [displayName] = "ほげほげ", "group-hogehoge", IIF( [displayName] = "ふがふが", "group-fugafuga", IIF( InStr([displayName], "YourApp-team-", , ) > 0, Replace([displayName], "YourApp-team-", , , "team-", ), [displayName] ) ) ) |
上の例はNotionの表示名マッピングですが、こうした式を本番で一発勝負で試すのは危険です。
SCIMに対応した検証用アプリを用意して、本番適用前にマッピング式の動作確認をしましょう。Entra IDには式ビルダーのテスト機能もありますが、実際のプロビジョニング結果で確認するのが確実です。
4. アプリごとに異なるプロビジョニングの挙動
📖 一般論
SCIMプロトコルを使っていても、利用するIDaaSとSaaSによって挙動が異なります。
🔧 体験談
過去、実際に遭遇した問題は以下のとおりです。
- SaaSのSCIMエンドポイントへのアクセス過多でエラー（初回同期時）
- IDaaS or SaaSのSCIMがRFCどおりに実装されておらず、一部の同期処理が失敗
- IDaaS or SaaSがグループ名変更やグループ削除に対応していない
- グループプロビジョニングでメンバーの同期状態と実態に齟齬がよく出る
サポートに依頼して改修してもらったり、自前でSCIM APIを叩いて同期用Lambdaを動かしたりと、正常な状態にするまでにはそれなりに時間がかかります。
そのため、できる限り検証環境を用意して事前に確認することを推奨します。ただし、SaaSでは検証環境の用意が難しいため、本番環境で一発勝負になることもあります。
今回は、自前での用意が難しいものだけ検証なしで本番一発勝負で切り替えました。
- Notion：本番環境で一発勝負
- SAML SSOはOrganizationレベルの設定のため、Workspaceごとの事前検証が不可能
- GitHub Enterprise Cloud：日常的に使っていないOrganizationで検証
- SAML SSOをEnterpriseレベルで行うとSCIMが利用できないため、Organizationレベルで設定
- AWS：検証用の別Organizationで検証
- Redash：検証用の別環境を作成
💡 TIPS: GitHubのSCIM設定で、Azure AD OAuthアプリがひとつでもOrganizationに対して承認状態になっていると、SCIMセットアップ時のGitHub OrganizationにGrantする画面が表示されないという問題に遭遇しました。個人設定のOAuthアプリからRevokeすることで解消しましたが、ドキュメントに記載がないのでハマりどころです。
5. IDaaS移行時のセッション・トークンへの影響
📖 一般論
SAMLのIdPを切り替える際は、既存セッション・認証トークンへの影響をアプリケーションのサポートに事前確認することが重要です。
🔧 体験談
GitHubでの移行時に、影響範囲を事前にGitHubサポートへ確認しました。
Enterprise管理者のアカウントから英語で質問するとレスポンスが早い気がします。
| 項目 | 影響 | 対応 |
|---|---|---|
| ブラウザアクセス | 再認証が必要 | SAMLで保護されたリソースにアクセスする際に、新しいIdP（Entra ID）での認証が必要 |
| 既存セッション | 有効期限まで維持 | 強制的なログアウトはないが、期限切れ後の再ログイン時に再認証 |
| OAuth/PAT | 機能継続 | 特別な対応不要 |
| Copilot | 初回のみ再認証 | 変更後の初回使用時に再サインインとSAML SSO完了が必要 |
💡 TIPS: IDaaS変更についてドキュメントに具体的な記載がないことがままあります。影響がないかサポートに問い合わせましょう。また影響があるにしろないにしろ、切り替え前にユーザーへの周知を忘れずに。あとで来る問い合わせの量が減ります。
6. グループプロビジョニングの罠
IDaaSとの連携で一番厄介だと思っているのがグループプロビジョニングです。
一見便利なのですが運用まで考えると考慮しないといけない事項が多くて、有効活用できるシーンは限られます。
📖 一般論
ネストされたグループは同期できない
Entra IDのSCIMプロビジョニングは、ネストされたグループ（Group in Group）のメンバーを読み取れません。直接メンバーとして割り当てられたユーザー・グループのみが同期対象です。
Nested groups. The Microsoft Entra user provisioning service can’t read or provision users in nested groups. The service can only read and provision users that are immediate members of an explicitly assigned group.
Understand how Application Provisioning in Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn
グループ設計時にネストを前提としている場合、フラットな構造に見直す必要があります。
旧IDaaSで作成されたグループは引き継げない
旧IDaaSのグループプロビジョニングで作成されたグループを、Entra IDでそのまま同期状態で引き継ぐことはできません。グループにはメールアドレスのようなユニークIDにしやすい項目が存在しないため、IDaaS側が独自にIDを割り振ります。そのため、移行時にIDを引き継げず、グループの再作成が必要になります。
グループ削除時の権限孤立リスク
削除予定のグループだけに権限が付いたリソースがないか、事前に確認が必要です。そのグループが唯一の権限付与先になっている場合、削除後にリソースへアクセスできなくなります。
Entra IDのプロビジョニング間隔は40分固定
Entra IDのグループプロビジョニングは約40分間隔で実行されます。即時性がないため、急ぎのオペレーションにはグループプロビジョニングは不向きです。ユーザー単位のプロビジョニングならばオンデマンドで実行できるため、少数であれば手動での即時同期が可能です。
🔧 体験談
OneLoginからの移行で行ったグループ切り替え手順
OneLoginで作成されたグループをEntra IDに引き継げなかったため、以下の手順で対処しました。
- 旧グループを事前にリネーム（古いことを記すプレフィックスを付与）して名前の衝突を回避
- Entra ID側で新しいシンプルな命名規則（YourApp-
team-xxx）でグループを再作成 - グループプロビジョニング
- グループへの権限付与などを利用者に依頼（APIで再付与できない場合）
- 旧グループは棚卸しタイミングで削除
💡 TIPS: グループのリネームはAPIがないと手作業になります。システム的にカバーできない手順がある場合は、数日前から計画的に進めるのがおすすめです。
Notionでの権限孤立チェックの限界
Notionではコンテンツ検索で対象グループが権限を持つページを洗い出せますが、そのグループ「だけ」が権限を持っているかどうかは目視確認が必要で、網羅的なチェックは困難でした。
グループプロビジョニングは多用しないのが無難
実際に運用を考えてみると、追加・削除・統合が発生する組織変更のたびにグループの付け替えや廃止管理に悩まされます。SaaS側にグループ管理の手段がSCIMしかない場合を除き、グループプロビジョニングは最小限にとどめるのがよいと感じています。
7. アプリのバージョンが古い場合のリスク
📖 一般論
SaaSではなくオンプレでOSSを動かしている場合、アプリケーションのバージョンが古いとIDaaSのSAML構成をそのまま組めないことがあります。
🔧 体験談
実際にこの問題に直面しました。利用しているRedash v10.1.0ではマニュアル通りでは動きません。
SAML & Azure/Entra · getredash redash · Discussion #7026
Authentication Options (SSO, Google OAuth, SAML)
対応策の検討
| 案 | 結果 |
|---|---|
| Redashをアップグレード | アップグレード後の動作確認に手間がかかるため最終手段 |
| 別のIdPを使う（AWS IIC等） | 動作はしたので選択肢としてあり |
| 設定だけで回避する | 動作したので採用 ✅ |
Redash v10.1.0だとEntra IDのSAML認証が通らないバグ、どこかで見た話だなと思ったら過去にOneLoginでも同じような不具合を喰らっていました。
RedashをECS Fargate構成にしてv7からv10へアップグレードする – NIFTY engineering
マニュアルだとEntity IDにRedashインスタンスのURLを入れるようにと書いてますが、Microsoft Entra Identifierを入れれば利用できるようになります。これならコード修正・イメージ再作成も不要です。
💡 TIPS: OSSのドキュメントやIssueの情報を鵜呑みにせず、実際に試してみることが大事です。なお、FirstName, LastNameのクレーム名に名前空間は不要でした。
8. 申請フロー・運用ワークフローの再構築
📖 一般論
IDaaS移行に伴い、以下のような運用フローの再構築が必要になる場合があります。
- アプリ利用者の追加・削除フロー
- グループ作成・メンバー変更の申請フロー
- 例外的なメンバー追加の手順
- 退職者管理の仕組み
- 一連の自動化処理
この部分は日常的な運用工数や利用者の使い勝手に直結するため、しっかりとフローを設計して手作業の運用は可能な限りゼロにすることを目指しましょう。
🔧 体験談
AWS IAM Identity Centerグループ管理のTerraform化
AIで加速するAWS運用効率化 〜IAM Identity Center IssueOpsとセキュリティ基準自動作成〜 | ドクセル
AWS IAM Identity Center（以下AWS IIC）への権限割り当てには、TerraformによるGitOpsを採用しています。今回の移行に伴い、グループ作成とメンバー割り当てもできるように改修しました。
グループへの割り当てでは、実際に誰が何の権限を得るのか分かりにくくなるため、レビューをサポートするGitHub Actionsを追加しました。
まとめ
IDaaSの移行は、表面的には「認証設定の差し替え」ですが、実態はアプリケーションごとの仕様差異・制約・運用フロー再構築との格闘です。
IDaaS移行で押さえておきたいポイント
- ユーザープロパティの差異を事前に洗い出す
- Entra IDのグループ管理の基準や動的グループの挙動を確認する
- マッピング式はIDaaSごとに仕様が異なるため、検証環境でテストする
- プロビジョニング挙動はアプリごとに異なる前提で、できること・できないことを整理する
- セッション・トークンへの影響範囲をサポートに確認し、ユーザーへ周知する
- グループのネスト非対応やグループ引き継ぎ不可など、SCIMの仕様制約を把握する
- アプリのバージョンが古いとそもそもSAML構成ができないことがある
- 運用フローの再構築（申請・自動化）まで含めて移行計画を立てる
同様の移行を検討されている方の参考になれば幸いです。
