Entra IDからOktaへのシームレスな移行
IDaaSを一度導入した後に、別のソリューションへの移行を実際に行うことは難しいと感じる方も多いかもしれません。確かに従業員の日々の業務の窓口となる認証のポイントを移行することは技術的なハードルだけでなく、従業員への教育や、オペレーション面も総合的に検討する必要があり、容易でないことは事実です。
そこで、今回はOkta Workforce Identityの能力、またOkta Workflowsのカスタマイズ性をフルに活用し、Microsoft Entra IDをIDaaSとして利用している状況から、Okta Workforce Identityに移行する作業を実際に行います。この移行作業においてはOkta Workforce Identityの様々な特徴的な機能を活用し、管理者やエンドユーザーへの影響を極小化しスムーズに移行する方法を検討します。
具体的には、Entra IDからOktaへの移行にあたって、管理者によるエクスポートやインポートなどの一括移行は行いません。更に加えてEntra IDで現在利用中のパスワードは、リセットをすることなくOktaへ同じパスワードのまま引き継ぎを行います。
ではこれらをどのように実現するのでしょうか？本記事では、また具体的な設定方法についても解説します。最初の設定部分は少し難解な部分があるかもしれませんが、一度設定を済ませておくことで、ユーザーとそのパスワードは自動で徐々にOktaに移行していくことが出来ます。
目次
注意点
今回ご紹介する手法については、Entra IDからOktaへの移行方法の概念を実証したに過ぎません。従って実際は現在の運用、Entra IDの個別設定状況を十分に考慮したうえで、適切な移行設計が必要になることに留意が必要です。
また、本手法によるEntra IDからOktaへの移行を完全に保証するものではありませんので、本番環境で実施する場合は、OktaパートナーやOktaプロフェッショナルサービスによる綿密な検討と移行設計を行うことを強く推奨します。
Okta Worflowsを用いた実装にあたっては、Workflowsのシステム制限に該当する場合があります。あわせてOkta APIのレートリミットも考慮し、実行するユーザー数や規模についても考慮が必要になります。
今回の手法では、ユーザーやパスワードのエクスポートや、インポートを用いない方法を示していますが、実際の移行シナリオにおいては、この手法で全てのユーザーをカバーすることは困難です。例えば、休職中の社員などの対応を考慮すると、今回の自動移行の手法だけで全社員を完全に移行させることは難しく、未移行のユーザーを手動でエクスポートしての移行、また、パスワードのリセットも組み合わせることが現実的なシナリオであります。
なお、Entra IDとOktaのスクリーンショットは2025年3月時点のものであり、今後両サービスの設定画面が変更となる可能性があります。あらかじめご了承ください。
移行方法の概要
今回のシームレスな移行については、Step 1. 「ユーザー移行」、Step 2. 「パスワード移行」という2つのStepを組み合わせて、2回に分けて実現します。
Step 1. ユーザー移行 - 外部Identity Providerの登録と、Just In Timeプロビジョニング
Okta Workforce Identityは、通常Identity Providor（IdP）として動作しますが、このOktaの認証を外部に委任することが可能です。この機能のことを「インバウンドフェデレーション」と呼ぶ場合があります。今回はOktaの外部IdPとしてEntra IDをOpen ID Connect（OIDC）で接続します。したがってOktaはRelying Party（RP）として、Entra IDはOpenID Provider（OP）として動作します。
また、インバウンドフェデレーションの際にJust In Timeプロビジョニング（JIT）によるユーザープロビジョニングが可能です。これにより、ユーザーがOktaに初回ログインした際に、Oktaのユーザーが自動で都度作成される形となります。これにより、各ユーザーがログインするたびにOktaのユーザーが作成されることから、徐々にユーザーは作成され、一括での移行が不要になります。
Step 2. パスワード移行 - パスワードインポートインラインフック
上記のJITでOktaに作成したユーザーは、Entra IDをソースとするユーザーとなり、またインバウンドフェデレーションされている状況ではOkta上にユーザーのパスワードが存在しません。パスワード移行にあたって、事前準備としてインバウンドフェデレーションを停止し、便宜的に一度Oktaのパスワードをリセットします。
ここでOktaのフック機能の一つである、「パスワードインポートインラインフック」を用います。次にユーザーがOktaにログインを試みた際に、Oktaの認証画面に入力した資格情報をもとに、インラインフックが発動し、Entra ID側で検証を行います。成功した場合はそのパスワードをOktaに保存します。これにより、ユーザーはEntra IDで使用していたパスワードと同じものをそのままOktaで利用することができます。
実際の設定
それでは実際の設定をEntra IDとOktaでそれぞれ実施していきましょう。詳細な手順をご紹介します。
Step 1. ユーザー移行
まずインバウンドフェデレーションの設定をEntra IDとOktaに対して行います。設定手順のドキュメントはこちらにあります。
Entra IDでは、[アプリの登録]から[新規作成]をクリックし、Oktaと接続するEntra ID側にOPとしてアプリケーションを最初に作成します。
ここでは「Okta Inbound Federation」と名付け、リダイレクトURIには[Web]を選択し、URIを入力します。
OktaのRPのURIは以下の形式になるので、その通り自身の環境に一致するよう指定します。そして[登録]をクリックします。https://[テナント名].okta.com/oauth2/v1/authorize/callback または https://[テナント名].oktapreview.com/oauth2/v1/authorize/callback
ここで作成したアプリケーション（クライアント）IDをメモします。次に、[証明書とシークレット]をクリックします。[新しいクライアントシークレット]を選択、追加し生成されたシークレット値をメモします。
[概要]->[エンドポイント]の順にクリックし、[OpenID Connect メタデータ ドキュメント]のURLをコピーします。
ブラウザの別タブにURLを貼り付けメタデータを表示し、"token_endpoint"、"jwks_uri"、”issuer”、 "userinfo_endpoint"、"authorization_endpoint" これら5つの値をメモします。
最後にAPIのアクセス許可から[〜に管理者の同意を与えます]をクリックし、ユーザー情報へのアクセス許可を付与します。これでEntra IDの設定は一旦終了です。
次は、これまでメモした値をもとにOktaに対して外部IdPを設定します。OktaのAdmin Consoleから、[セキュリティ] -> [IDプロバイダー] - [IDプロバイダーを追加] を選択します。
次にOpenID Connect IdPを選択し、先ほどメモした内容から各種項目を入力します。
後半の[認証の設定]ではIdPユーザー名はデフォルトのまま、つまりEntra ID上のメールアドレス属性をOktaのユーザー名として使用します。
アカウントリンクポリシーは自動リンクを有効化し、一致が見つからない場合は、JITで新しいOktaのユーザーを作成します。さらに、JITで作成したユーザーについては今回の場合、あらかじめ作成済みの「JIT Group」というOktaグループに自動割り当てを行います。設定完了後、終了をクリックし確定します。
次にIDプロバイダーの設定に戻り、ルーティングルールの作成を行います。
ここではユーザー名（メールアドレス）のドメイン名がjknme.netの場合Entra ID、それ以外の場合はOktaで認証するようルーティングルールを構成します。これでStep 1.ユーザー移行の準備が完了しました。
Step 2. パスワード移行
先ほどの手順同様に、Entra IDから[アプリの登録]から[新規作成]をクリックしアプリケーションを最初に作成します。
先程同様にEntra IDにアプリケーション (クライアント) IDをメモし、[証明書とシークレット]からクライアントシークレットを作成します。更に、[API のアクセス許可]から[〜に管理者の同意を与えます]をクリックし、ユーザー情報へのアクセス許可を付与します。（この部分のスクリーンショットは割愛していますので、前半部分を参照してください。）
次に[認証]をクリックし、「承認エンドポイントによって発行してほしいトークン」に「アクセストークン」と「IDトークン」を選択します。また下部にある「次のモバイルとデスクトップのフローを有効にする」を「はい」とし保存します。ここでOIDCのリソース所有者のパスワード資格情報フロー（Resource Owner Password Flow）を有効化します。
[エンタープライズアプリケーション]からパスワード移行用として作成したアプリケーションを選択し、移行対象とするユーザーを追加します。今回は、「Jun Sakamoto」をサンプルユーザーとして割当を行いました。
Entra IDの[概要]から、テナントIDをコピーしメモします。Entra ID側はこれで設定完了です。
Oktaの設定に移ります。まずパスワード移行用途としてのOktaグループを作成します。ここでは、「Password Migration」というグループ名で作成します。この際に作成されたグループのIDをメモします。IDはURLの末尾の文字列です。
後続のOkta WorkflowsからOktaに対してのAPIを実行するためにAPIトークンを作成します。[セキュリティ] -> [API] -> [トークン] から[トークンの作成]を行います。作成したトークンはメモします。
Okta Workflowsの設定に移ります。以下で用いるフローについてはこちらからダウンロード可能です。Okta Workflowsの基本的な利用方法については、細かく触れませんので過去のブログ記事を御覧ください。
まず「Password Migration準備用」を開きフローの左半分を見ます。ここではユーザーがOktaのグループに追加されたことをトリガーとしてフローが開始されます。[Continue if]カードに先ほど作成したグループのIDを[value b]に入力し、一致する場合フローが継続します。また追加されたユーザーのIDを用いて、OktaのUsers APIを実行しパスワードリセットを行います。このためには、[Compose]カードのURLを自身のテナント名に書き換えます。
[API Connector Post]のカードでは、[New Connection]を作成し、その際の[Auth Type]は[None]を選択します。[Header]部分のSSWS 00から始まる部分に先程発行したトークンを入力します。（SSWS 半角スペースの後にトークンを入力してください）
フロー後半の右半分においても同様に、[Compose]カードのURLの書き換え、また[API Connector Post]のカードでは、先ほど作成したAPI Connectorを選択し、Authorization Headerに同様のOktaのトークンを記載します。
この後半部分では当該ユーザーに対して、パスワードインポートインラインフックの有効化を行っています。この処理を行うためには、1度Oktaのパスワードリセットすることで、外部IdP由来のユーザーである状態から、Okta由来のユーザーとすることでインラインフックの有効化が可能となることからこのような順で実施しています。
次に「Entra ID - Validate Creds」フローを開きます。[Entra ID Tenant ID]、[Entra ID ROP OIDC Client ID]のカードに対して先ほどメモした、Entra IDのテナントIDと、Password Migration用アプリのアプリケーション (クライアント) IDを記載します。後半の[Try]とある（Error ifカード）の中においても[API Connector Post]カードがありますので先程作成したものと同じAPI Connectorを選択します。
このフローでは、メインフローから受け取ったユーザー名とパスワードを用いて、Resource Owner Password FlowでEntra IDへログインし、エラー応答の有無を検証するフローです。
最後のメインフローにおいて変更点はありません。このフローはAPIエンドポイントによりトリガーされ、上記のログインに成功した場合はステータスコード200を返答します。
フローを全て有効化し、最後のメインフローの[API Access]をクリックします。
Invoke URLをメモします。これでWorkflowsの設定は完了です。
Okta Admin Consoleに戻り、[ワークフロー] -> [インラインフック] を選択し[インラインフックを追加]から[パスワードのインポート]をクリックします。
名前を決め、先程Okta Workflowsフローでコピーした”Invoke URL”をURLとして貼り付け、保存します。
以上ですべての設定は完了しました。それぞれの設定が正しく完了しているか、アクティブかどうかを確認し、動作確認をしてみましょう。
移行作業の実施
それでは実際に移行作業をそれぞれのステップ別に実行します。
Step 1. ユーザー移行
今回は動作確認として、移行対象の1つのユーザー、Jun Sakamoto ([email protected])を例として、Okta Dashboardにログインを試みます。この時点ではEntra IDのみにユーザーは存在し、まだOktaには存在しません。
Oktaへの認証要求は、先ほど設定したルーティングルールに従ってMicrosoftのログイン画面にリダイレクトされます。
Entra IDの認証成功後、Okta Dashboardへのログインが完了しました。このタイミングでJITでOktaのユーザーが作成されています。
Admin Consoleからもユーザーが作成され、またJITの際に割り当てた「JIT Group」に所属していることが分かります。
これでユーザーの移行が完了しました。この作業によりOktaにユーザーが作成されていることから、Oktaに登録済みの各ダウンストリームアプリケーションはEntra IDからのインバウンドフェデレーションにて利用することが可能です。この状態を一定期間を取ることで、日常ユーザーの大半がOktaにJITにてユーザーが作成されることが期待されます。
Step 2. パスワード移行
パスワード移行後は、ユーザーの認証はEntra IDからOktaに変更となるため、まずは事前準備として、Step 1で用いたインバウンドフェデレーションを停止します（非アクティブ化）。これにより対応するルーティングルールもあわせて非アクティブ化されます。
次に対象ユーザのJun Sakamotoのユーザー状態の詳細を見ます。Postmanなどを用いてOktaのUsers APIからGet Userを取得した際の、レスポンスボディーにある”credentials”部分に注目します。現時点ではprovider, typeとして”SOCIAL”となっており、資格情報については外部のIdPを参照していることを示します。これをOkta管理の資格情報に変更するためには一旦パスワードリセットが必要です。
その後、このユーザーに対して、インラインフックにてパスワードを取得する対象としての処理を行います。これらの処理は準備したOkta Workflows最初のフロー「Password Migration準備用」を使用します。 このフローは作成した”Password Migration”グループに追加することでトリガーされるため、Jun Sakamotoを手動操作でグループに追加します。すると、以下の通りフローが正常完了しました。
再度、APIからGet Userを取得した際の、ボディーにある”credentials”部分に注目します。
typeが”IMPORT”に変わり、パスワードインポートの対象となるよう処理が正しく完了したことが分かります。それでは同じユーザーでログインしてみましょう。すでにインバウンドフェデレーションは無効化されていることから、Oktaのログイン画面(Sign in widget）にEntra IDのパスワードを直接入力します。
特段遅延はなくログインが完了しました。これだけでパスワード移行は完了になります。パスワードの入力によりインラインフックが発動され、そこからOkta Workflowsのメインフロー、対応するヘルパーフローが実行され、UsernameとパスワードをEntra IDで検証を行ったことが分かります。
最後にAPIからGet Userを取得した際の、レスポンスにある”credentials”部分の変化を確認します。typeは”OKTA”となりました。これにより、Oktaでパスワードを管理するユーザーであることが分かります。次のログイン以降は、Oktaでパスワードを検証し認証する動作となります。
おわりに
いかがでしたでしょうか？事前設定を行うことで、ユーザーの観点ではOktaに2回のログインするだけで、ユーザーとパスワードの移行が完了しました。あまり日の目を見ないインラインフックや、インバウンドフェデレーションの機能の組み合わせ、これらの橋渡し、ユーザーに対する必要な処理や自動化をOkta Workflowsで実現しました。
実際にはユーザーがMFAで利用するAuthenticatorの登録も必要であるなど、他の観点（ユーザー属性の移行など）も織り交ぜての考慮が必要となりますが、Oktaのプラットフォームの柔軟性、可能性、潜在能力を体験いただけると嬉しく思います。
Oktaでは複雑なユースケースや、移行要件を伴うプロジェクトについても多くの支援実績を有します。これらご検討の際には、担当営業までぜひご相談ください。
（本ブログ記事は、こちらの記事を参考にシナリオをカスタマイズし、また最新版にアップデートしたものとなります。）
Follow 南野 要
