社名変更に伴う ログインID(メールアドレス)変更
はじめに
この記事は 【初心者優先枠】corp-engr 情シスSlack(コーポレートエンジニア x 情シス)#2 Advent Calendar 2024 のアドベントカレンダー 19日目 (2024/12/19(木)) の記事となります。
この記事では、約650アカウントの社名変更に伴うログインID(メールアドレス)変更プロジェクトの実施経験をもとに、以下のような内容をご紹介します。
- Okta を利用した SSO 環境での ログインID 変更の実施方法
- SCIM 連携時の注意点や各 SaaS ごとの特性
- 実際に直面した課題と解決策
以下のような方々のご参考になれば幸いです。
- Okta を利用した SSO/SCIM 連携環境での ログインID 変更を検討されている方
- 社名変更に伴うメールアドレス変更を計画している方
概要
- 社名変更に伴い、約650アカウント(本社600アカウント、グループ会社50アカウント)の ログインID 変更を実施しました(ログインID としてメールアドレスを利用している)。
- 弊社では、Okta を IdP として利用し、各 SaaS への SSO ログインをしています。
- アカウントのプロビジョニングは SCIM 連携しているものもあれば、していないものもあります。
- その中で、どのようなことをしたのか、どのような点に躓いたのか、どのようなことがわかったか、などを記載したいと思います。
やったこと、躓いたこと、わかったこと
Okta から SCIM 連携している SaaS のログインID 変更
まず、 SCIM 連携している SaaS のログインID のキーとしているメールアドレスを変更したらどのような影響があるのか、を確認する必要がありました。
App username
」 と 「 login
」属性を変更した場合では挙動が違う!
「 「え、そうのなの?」という感じです。一番躓いた点はここです。
当初検証をする際、「 App username
を更新する」という検証を行っていました。
そしたら、連携先の SaaS では
- 既存ユーザの削除
- 新しいユーザを作成
という動きになりました。
うーん、では連携先の SaaS とタイミングを併せてメールアドレス変更しなきゃいけないのかぁ、と思っていました。
そして、いざ プロファイル の login
属性を変更してみると、
-
App username
も変わってる(まあ、それはそうだろう) - 連携先 SaaS のメールアドレスも変わってるぞ(???)
という状況でした。
どうやら、 Okta プロファイルの login
を変更するパターンと、アプリケーションの割り当てで設定する App username
を変更したときのパターンで SCIM の挙動が違うようです!
まとめると以下のようになります。
-
login
を変更するパターン- SCIM 連携 が有効の場合
- SCIM Update が実行され、追従して
App username
および連携先のメールアドレスも更新される。
- SCIM Update が実行され、追従して
- SCIM 連携 が無効の場合
- 何もおきない。
- SCIM 連携 が有効の場合
-
App username
を変更するパターン- SCIM 連携が有効の場合
- SCIM Create が実行され、別アカウントが作成される。
- 従来アカウントのメールアドレスを変更したい場合は、Oktaの作業前に連携先の SaaS 側でメールアドレスを変更しておく必要がある。
- SCIM 連携 が無効の場合
- 何も起きない。
- SCIM 連携が有効の場合
このあたりのお話は以下を参考に進めさせていただきましたので、感謝を込めてリンクを貼らせていただきます。
SCIM 連携してるけど例外的な対応が必要だった SaaS ( Miro / Zoom )
SCIM 連携してたら何も考えずに 「 login
属性だけ変えればメールアドレス変わる」というわけにはいかないパターンもあったので、それぞれの特性を説明しつつ、記載します。
Miro
Miro も SCIM 連携していたので、上記想定で変更できる想定でいました。
テストアカウントで変更したところ、問題なく変更できました。
しかしながら、メンバーのアカウントでリハーサルを行ったところ、うまくいきませんでした。
これは、サンドボックスで契約していた別テナントにすでに、ドメイン変更後のユーザが存在したためです。
つまり、本番作業でもユーザが別テナントに野良アカウントを作成していたら、同じことが起きてしまう、ということを意味します。
しかしながら、Miro では SCIM 連携をしているとメールアドレスを変更できない、という制限がありました。
ではどうしたか?
- Miro のサポートに問い合わせたところ、サポート側にて変更可能と言うことがわかりました。
- 本番作業時は、Miro のサポートと連携して、ログインID の変更を実施しました。
- ここで注意しなければならないのは、SCIM Update / SCIM Detele を作業時に一時的に無効化したことです。
- これは、
login
属性変更時に SCIM 連携による影響を回避するためです。- ※ SCIM Create も無効化してしまうと SCIM 連携が切れてしまう可能性があるので、 Create は有効のまま
Zoom
Zoom に関しては、ライセンス管理を Zoom に対して直接行っています。
Zoom Phone などのアドインライセンスの管理が Okta ではできないためです。
そのため、SCIM 連携はしているものの SCIM Update は有効にしてませんでした。
この場合、 login
属性を更新しても、App Username
は更新されません。
つまり、Zoom 側のメールアドレスが自動で更新されることはないため、手動で更新する必要がありました。
Zoom のメールアドレスの更新は以下に説明があります。
しかしながら、いくつか注意事項があるので、その点を記載します。
- ヘルプサイトの言語が英語じゃないとメアド一括更新の記載が見えない
- 言語が日本語だと出てきませんのでご注意ください(2024年12月時点)
- 手順通り進めようとしても一括更新のメニューが見当たらない
- ヘルプページに記載れている手順で進めればできるかぁ、と思いましたが一括更新のメニューが見当たりません。
- サポートに問い合わせたところ、「問い合わせに応じて有効化しています」とのことです...
- ※ 2024年5月ごろの情報なので現時点では通常機能として提供されているかもしれません(メニューが見当たらない場合はサポートに問い合わせてみてください)
SCIM 連携していない SaaS について
上記の通り、login
を変更しても App username
が更新されないため、弊社では「SCIM 連携していない SaaS のログインIDは変更しない」ことを基本方針としました。
Okta にログインしてしまえば、 IdP-Initiated の シングルサインオン の裏で Okta が暗黙的に変換し、ユーザが特に ログインID を意識する必要がないと考えたためです。
(一部 Google ログイン を利用している SaaS は変えざる得なかったので変更しました。)
まとめ
良かった点
- Okta を IdP として利用していた点
- IdP に特化しており、こういった変更に強いプロダクトであったことは非常に安心材料でした(プロダクトとしてよく考えられた設計になってるなと思いました)。
- 例として以下の点です。
- Okta はプロファイル属性とは別に
App username
という各 SaaS ごとの ログインID を持っており、個別の対応が容易だった点 - プロビジョニングのマッピングの変更がユーザー個別にカスタマイズしやすい点
- Okta はプロファイル属性とは別に
- 事前に入念な準備、度重なるリハーサルを実施した点
- テストアカウントだけでなく、実運用されているメンバーのアカウントにてリハーサルを行うことで、様々な問題点を事前に洗い出すことができました(以下の反省点に記載した内容を除き)。
- 本番作業を2週に分けて実施した点
- 弊社だと、人数の少ないグループ会社(約50アカウント)を1週目、本社(約600アカウント)を2週目に実施しました。
- 1週目で問題(Zoom のライセンスが外れてしまう)という問題が発生しましたが、人数も少なかったので、即時リカバリを実施できました。
- そして、 2周目の作業までに原因解明及び対策の実施ができました。
反省点
- 一般権限での検証を怠った点
- あるあるだと思うのですが、情シス部門のため管理者権限がついているアカウントで検証をしてしまいました。
- 結果、1週目の本番作業時に Zoom でライセンスが外れる、といったことが発生してしまいました(管理者だと外れないが一般ユーザだと外れてしまう)。
- ユーザと同じ権限での検証の大切さを実感させられました。
今後に活かしたい点
- SCIM 連携する SaaS を拡充したい
- Okta で SSO しているものの、 SCIM 連携していない SaaS も結構ありました。
- 弊社では、SCIM 連携していないアプリの
App username
は変更しない、という方針としたため、ユーザに若干の混乱を招いてしまいました。- SP-Initiated の際に旧ドメインのメールアドレスで認証しなければならないため
- SCIM 連携していれば、
login
属性の変更に追従して変更されるので、このような混乱を防ぐことができると同意時に、「ユーザへのわかりやすさ」という観点でもシンプルだと思いました。
所感
- 実施規模について
- 個人的な感想としては、これぐらいの規模(今回は650アカウント)が限界だと思いました。
- これ以上規模が大きい場合は無理やり変更せず、コストが許されるならドメイン混在の運用を許容し、リプレイスなどの機会に全員統一する、という選択肢もありだと思いました。
- 野良アカウントについて
- SaaS アカウントのトレンド的に、今後 Miro の用に野良アカウントを他テナントで作られているパターンは十分あり得るな、と思いました。ログインID のキーをメールアドレスとしている場合に考えることが増えそうです。
以上となります。
少しでもみなさまのご参考になれば幸いです。
Discussion