STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

社名変更でドメインが変わる際にOkta周りでやったことと苦労したこと

この記事は STORES PX Advent Calendar 2023 Spring 2日目の記事です。

はじめに

こんにちは、STORES のPX部門IT本部でコーポレートエンジニアをしている加来 (thdy_jp) です。

この記事では社名変更でドメインが変わったことによりOkta関連で対応したことや、その中で苦労したことなどについて書いています。

内容としてはOktaに限らず何らかのIDaaS製品 (例えばAzure ADやOneLoginなど) でシングルサインオンを構成している組織であれば発生するであろう課題について書いているので、Oktaを利用されていないID管理者の方にもぜひ読んでいただきたいと思っています。

背景

弊社は昨年の10月にヘイ株式会社からSTORES 株式会社へ社名変更しました*1。

社名変更に伴いメールアドレスのドメインを hey.jp から st.inc に変えることとしたため、社内で利用している様々なサービスのアカウントも基本的に st.inc のメールアドレスに移行する方針でした。

※ 関連する記事として PX Advent Calendar 2023 Spring 1日目の 「社名変更に伴うGoogle Workspaceアカウントの引越し手順を解説します」 もぜひ読んでみてください

また STORES では社内向けのID管理・統合認証基盤サービスとしてOktaを使って各種サービスとのID連携を構成しており、このOkta側およびシングルサインオン (以下 SSO) している先のサービス側それぞれのメールアドレスの変更を実施する必要がありました。

SSOに使うメールアドレス変更のイメージ

課題

OktaおよびID連携先サービスでメールアドレス変更を行っていく上での課題として下記のような点がありました。

  • それぞれのサービスにおいてメールアドレス変更をすることによる実影響が不明
    • Slackをはじめさまざまな業務と密接に関わっているサービスにおいては何か影響が出た時の業務影響も大きい
  • メールアドレスの変更がサービス開発ベンダー側でしかできないものもあり切り替えタイミングが限られる
  • SSOしている複数のサービスすべてを同時に切り替えるのは何かあった際の対応リソースが集中することもありリスクが高い

要件

前述のような課題を踏まえ、OktaとID連携先サービスのメールアドレス変更の要件を下記としました。

  • 各部門から募った有志による先行移行テストを行えるように、全員一斉にではなく特定のグループから段階的にメールアドレス変更できること
  • SSOしている先のサービスごとに任意のタイミングで移行できること

SSOに用いるメールアドレスの変更プロセス

前述の要件を満たすためには Okta上のユーザープロファイルに従来のメールアドレス (hey.jp) と新メールアドレス (st.inc) の両方を持っている必要があります。 この点についてはデフォルトのユーザー属性でPrimary emailとSecondary emailがあるのでそれを活用することにしました。

Okta上のユーザープロファイル属性名 従来の設定値 変更後の設定値
Username xxxx@hey.jp xxxx@st.inc
Primary email xxxx@hey.jp xxxx@st.inc
Secondary email (未使用) xxxx@hey.jp

いきなり上記の変更後の設定値の通りにしてしまうとSSOが動かなくなってしまうので、実際には下記のような流れで実施しました。

  1. Secondary emailにhey.jpのアドレスを設定
  2. SSOに用いる属性値をSecondary emailに向ける
  3. Primary emailにst.incのアドレスを設定
  4. 先行で移行するメンバーのSSOに使うアドレスをst.incに書き換え
  5. 最終的にすべてのメンバーのSSOに用いる属性値をPrimary emailに向ける

文章だけだと少し分かりづらいのでここから図を交えながら解説します。

段階的に移行するための準備

まず以下の図は従来のユーザープロファイルとSSOの設定状況です。

これに対し一旦ユーザープロファイルに新メールアドレスを入れつつ従来のSSOを維持できるようにしました。

なお 1. と 3. はCSVで一括インポートし、2. についてはそこまで数も多くないためOktaの管理コンソールからポチポチ変更しました。
これで特定のメンバーから新しいメールアドレスへ切り替えていく準備ができました。

SSOに使うアドレスを切り替える

続いて先行で移行して動作確認を行うメンバーのみを対象として、SSOに使うメールアドレスをst.incに書き換えることで各種サービスで新メールアドレスでの動作確認ができるようにします。

これについてはOkta側およびSSOしている先のサービス側のメールアドレスを書き換えるためのAPIを叩くcurlコマンドをスプレッドシート上で一括作成し、先行で移行するメンバーの分だけをコピーして手元のターミナル上で実行することで実施しました。
以下はSlackの例です。

# Oktaの特定のSSO AppのApp Usernameを変更するコマンド
curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: SSWS $OKTATOKEN" -d '{"credentials": {"userName": "kaku@st.inc"},"profile": {"email": "kaku@st.inc", "slackUsername": "kaku"}}' "https://{organizationId}.okta.com/api/v1/apps/{Okta app id}/users/{Okta user id}";

# Slackの特定のユーザーのメールアドレス変更コマンド
curl -X PATCH -H "accept: application/json" -H "Authorization: Bearer $SLACKTOKEN" -d '{"schemas": ["urn:scim:schemas:core:1.0"],"emails": [{"value": "kaku@st.inc","primary": true}]}' "https://api.slack.com/scim/v1/Users/{Slack user id}";

なおサービスごとにAPIのrate limitが異なるのでエラーにならないよう注意が必要です。今回はOktaに合わせて50ユーザーずつ実行しました。
また、中にはAPIが公開されていないサービスもあったのでそういったものはCSVインポート等で対応しました。

※ ちなみにこのコマンドを見て気づかれた方もいるかもしれませんが弊社ではOktaによるプロビジョニングを基本的には利用していません (一部では利用あり) *2

先行移行メンバーが各種サービスの動作をテストして問題ないことが確認できた上で、同様のコマンドを全メンバーにも実施し書き換えを完了しました。
ここまで来たらOkta上のSSOに用いる属性値も元通りPrimary emailに向けて完了です。

苦労したこと、ハマったこと

ここまでに書いた内容を実施する中で苦労したことやハマったことを挙げてみたいと思います。

メールアドレス変更の影響が不明 & サービスごとに異なる

SSOとは直接関係ない内容になりますが、ドキュメントを確認するだけではメールアドレス変更の影響が分からずそれぞれのサービスで実際に試してみたりサポートに問合せたりといった調査がほとんどのサービスで必要でした。
ここでは調査結果については割愛しますが、Slackについては全てのメンバーが利用することであったり様々な外部サービスと連携することから最も影響が大きかったサービスであると感じました。

またサービス利用時にサブドメインを独自に指定する必要があるもの (xxxxx.slack.com など) については恐らく多くの組織が「自社の社名に関する文字列」を付けると思われます。当社もそのケースに該当していたのですが、このURLが何らかのタイミングで外部の取引先から見えるサービスについては変更しないと取引する上で不要な誤解を招く恐れがある場合があり*3、これも変更対応および影響確認の対象となりました。

OktaのApp username更新ルールを知らずにハマった

前述の SSOに使うアドレスを切り替える のセクションにも記載していた通り今回はAPIでOkta側のApp usernameを書き換えていたのですが、これはあくまで「App usernameは勝手に書き換わらないこと」を前提としていました。

その基となる仕様理解として、App usernameは「対象AppのCredential Detailsの画面で Update Now を押さない限り更新されない」と思いこんでいましたがこれは誤りでした。

ここを押した時だけ更新されると思いこんでいました

実際にはそうではなく、下記URLのページ内に記載されている通りユーザープロファイルの更新に応じてApp usernameが上書き更新される条件があります。

https://support.okta.com/help/s/article/Application-Usernames-are-not-being-updated-automatically

上記URLの内容を要約すると、下記のいずれかに該当するSAML SSO Appはユーザープロファイルの更新に応じてApp usernameは自動更新されます。

  • プロビジョニングが有効になっている
  • SSO Appのユーザー名の形式がcustomかつ非推奨の式や機能しない式を使用していない
  • OktaからSSO Appへ "create and update"としてマップされた複数の属性がある

今回は対象のサービスの中に一部プロビジョニングを利用していたサービスがあったため意図せずApp usernameの上書きが発生してしまい、そこで調べた結果この仕様に気付きました。 移行テスト中に判明した内容だったため、事前テストの重要さを改めて感じたきっかけにもなりました。

なお補足として上記はSAMLプロトコルにおけるSSOの話であり、OpenID ConnectでSSOしているサービスの場合は「基本的にユーザープロファイルと連動してApp usernameが自動更新される」という仕様のようです*4。

採用しなかった別のアプローチ

今回はOktaのApp username自体をAPIで書き換える方法を取りましたが、別の選択肢として考えていたのはOktaのユーザープロファイル上に拡張属性として「メールアドレス切り替えフラグ」をサービスごとに持たせ、SSO Appのusernameフォーマット設定でカスタム数式を使ってそのフラグを判定することでApp usernameを切り替えるというアプローチです。

これを採用しなかった理由としては「今回限りしかやらない」という性質の作業に対して拡張属性を新たにユーザーに持たせるということをしたくなかったからですが、ID連携先サービスの数やプロビジョニングの有無によってはこれも有力な選択肢になり得るとも思います。

まとめ

結果としては特に大きなトラブル等を招くこともなく、それぞれのサービスで無事に移行を終えることができました。

ただその背景としては先行してメールアドレス変更の影響調査に協力してくれた多くの社内メンバーであったり、切り替え作業に用いる手順やデータのレビューを綿密に行ってくれたチームのメンバーのおかげだと思っています。
また、事前調査の中で各種問合せに回答してくれたサービスベンダーの中の方々にも改めて感謝したいと思います。

なお各ID連携先サービスにおけるメールアドレス変更の影響 (例えばOktaとフェデレーションしているAzure ADのUPNを変更したらどう影響があるのか？など) については本記事には書ききれないため割愛していますが、リクエスト等あれば何かしらお答えや別記事を書いたりできればと思っているのでツイートやはてブのコメントなどお待ちしています。

お読みいただきありがとうございました！

*1:お商売のデジタル化を支援するヘイ株式会社、 2022年10月より「STORES 株式会社」へ社名変更｜STORES 株式会社

*2:別途GASやNode.jsを使った内製のツールでより柔軟なアカウント管理を行っていることが背景としてあります

*3:例えばSlackにおいては取引先とSlackコネクトを行う際に相手側に届くメールにSlackのテナントURLが表示されるので、ここが実際の社名と異なると誤って招待してしまったのかなど不要なやりとりが発生する懸念がありました

*4:これに該当するドキュメントは発見できませんでしたが実際に手元で検証した内容とサポートに確認した結果で裏を取りました