はじめに こんにちはこんばんは、WS-Federationをこよなく愛するネクストモードのおはらふです
はじめに
皆様こんにちはこんばんは、Microsoft Entra ID (Azure AD) とOkta WICをこよなく愛するネクストモードのおはらふです
ところで検証環境等含めて複数のEntra IDとOkta WICを管理していると、ふと思うことはありませんか？
「Azure ADからOktaを経由してAzure ADにプロビジョニングしたいな」と
キーワード
Okta、Okta WIC、SSO、SAML、WS-Federation、JIT、Azure AD、Entra ID
Entra IDとOkta WICの連携
まだまだAzure ADのネームバリューが強すぎて、なかなかEntra IDの呼び方に慣れない方も多いと思いますが、本稿では以降「Entra ID」に統一します
単純にEntra IDとOkta WIC（以下Okta）をそれぞれ連携させてもいいのですが、せっかくなのでOkta部分はHub & Spoke構成してみましょう
図にすると下記のようになります
そして悩みを抱えていない方はすぐに疑問に思うはずです。「なんでこんなことするの？」と
なぜEntra ID連携でOktaを経由するのか
単純に上記のようなEntra IDとOktaしか連携しない場合でOktaを経由するメリットは・・・、ロマンです。あとは大人の事情でしょうか
一方、単純なEntra IDとOkta連携のケースは運用上考えづらく、多くの場合は他のSaaSが連携されているはずです
OktaをHub & Spoke構成にするメリットのひとつは、検証環境と本番環境のような複数の環境を分けられることです
検証環境だけでなく、本社と支店や、全社導入SaaSと部門単位導入SaaS等の環境で使えるケースも多いと思います
こちらも図にすると下記のようになります
本番Entra IDにアカウントを作成すると、自動的にOkta Hub/Spoke、各SaaSにID連携（プロビジョニング）を行うことができます
人が介在するのは本番用Entra IDにアカウント作成をする工程のみですので、運営コストが下がる効果が得られるはずです
また、検証用環境は基本的にエンジニアしか使わないと思いますので、Entra IDのグループ情報等を使い特定ユーザーのみ検証環境を自動的に払い出すことが可能です
今回は本番環境のドメインを [xxx.onmicrosoft.com] 、検証環境のドメインを [xxx.nextmode.co.jp] で構築してみましょう
Okta Spokeへ連携する際にドメイン変換することで、本番と検証のドメインを分けることが可能です
設定方法
上記構成を実際に構築してみましょう
手順としては以下の3工程となります（SaaS郡の設定は除く）
Okta Hubにカスタムアプリを設定する場合、Hub & Spoke構成を最後に設定する必要があります
- [本番Entra ID] と [Okta Hub] のID連携
- [Okta Spoke] と [検証用Entra ID] のID連携
- [Okta Hub & Spoke構成] の構築
[本番Entra ID] と [Okta Hub] のID連携
Entra IDをIdpとしてOktaと連携する手順になりますので、下記ブログを参考に設定を行います
[Okta Spoke] と [検証用Entra ID] のID連携
OktaをIdpとしてEntra IDと連携する手順となりますので、下記ブログの注意点やOkta公式ドキュメントを参考に設定を行います
手順としてはMicrosoft365とのWS-Federationですが、実態としてはEntra IDとのID連携を行っております
https://help.okta.com/ja-jp/content/topics/apps/office365-deployment/configure-sso.htm
[Okta Hub & Spoke構成] の構築
Hub & Spoke (Org2Org) の設定も下記ブログを参考に行っていきます
ブログ内ではブックマークアプリを利用し、ユーザーがOkta Spokeを意識しない設計になっていますが、ユーザーがOkta Spokeを意識するやり方があるので補足しておきます
[Okta Hub] にある [Org2Orgアプリ] にて、[アプリの表示] を行うことでSpoke Oktaへのアイコンを表示させることが可能です
以降、ブックマークアプリ作成有りとチェック有りのパタターンで画面遷移を説明いたします
上記工程を全て行うことで、[Entra ID] → [Okta Hub] → [Okta Spoke] → [Entra ID]のID連携が完成しました
実際にログインしてみる
本番用Entra IDに任意のユーザーを作成し、そのユーザーでEntra ID (Microsoft365) にログインすると、こんな感じでアプリ一覧にOktaが出てくるはずです
ポチーと作成されているOktaアプリを押してみましょう
こんな感じでくるくるした後に・・・
Oktaへのログインが自動的に行われ、アプリ一覧に2つのアイコンが出てきました
左がOkta Spokeへログインするアイコンで、右が検証用Entra IDにシームレスでログインできるアイコンです
ためしに左側のOkta Spokeへログインするアイコンをクリックしてみましょう
ちょっとわかりづらいですが、自動的にOkta Spokeにログインが完了し、検証用Entra ID（Microsoft 365）へのログインアイコンが出てきました
最後にこのアイコンをクリックし、正しくログインできるか確認しましょう
これまたちょっとわかりづらいですが、無事にEntra ID（Microsoft365）へログインできました
尚、Okta Hubにあるブックマークアプリをクリックすると、Okta Spokeを意識することなく（フロー上は経由していますが）この画面へ辿り着くことができます
それぞれに直接ログインしようとするとどうなる？
これまでの手順でお目当ての構成は構築できましたが、ふと疑問に思いませんか？
「各テナントに直接ログインしようとするとどうなるの？」と
せっかくなのでそれぞれ直接ログインを試みてみましょう
Okta (Hub) の場合
OktaのHub側に直接ログインを試みた場合、初期設定だとOkta HubにユーザーIDを入れてもサインインできません
これでも良いのですが、せっかくなので優しさのために本番Entra ID側にリダイレクトさせてみましょう
[Identity Providers] → [Routing rules] → [Add Routing Rule] にてリダイレクトの設定を行います
デフォルト設定だと全てのログインがリダイレクトされてしまうので、特定のドメインのみリダイレクトする設定にしてみます
下記設定の場合、[User matches] の項目でログイン名に***.onmicrosoft.comが含まれている場合、[Identity provider] にて設定したEntra IDへリダイレクトされる動作となります
上記設定を行い、ログインを行ってみると・・・
無事にEntra IDのアカウント選択画面になりました（検証を行う方はこの辺がカオスになっているはず・・・）
このあとはいつも通りEntra IDにログインすることでその後Okta hubにリダイレクトされます
Okta (Spoke) に直接ログインしようとした場合
Okta Spokeに直接ログインしようとすると、Okta Spokeのパスワードなんて知らない（設定されていない）のでログインできない状態となります
これまでのやり方ですと、Entra IDのパスワードは連携されません
こちらもこのままでも良いのですが、せっかくなので優しさでOkta Hubにリダイレクトさせてみましょう
手順は上記と同じなので割愛します
Okta Hubへリダイレクト後にログインをしようとすると、またパスワードを求められるのですが、上記同様パスワードは設定されていないのでログインできません
加えて今回のケースですとOkta HubとOkta Spoke連携の際にドメイン変換しているので、Okta Hubでは [xxx.onmicrosoft.com] のログインIDを使用する必要があります
ちなみに [サインインに戻ります] からドメイン変換前のログインIDを入力することで、Entra IDに正しくリダイレクトさせることは可能です
検証用Entra IDに直接ログインしようとした場合
こちらはMicrosoft側の設定になりますが、基本的には自動的にOkta Spokeにリダイレクトされるはずです
WS-Federationでは該当ドメイン全てがIdP（Okta Spoke）経由のログインになるためにこの動作となります
おわりに
理想はひとつのIDaaSを管理することなのかもしれませんが、実務上そんなうまくいかないパターンもあると思います
特に何らかの形でMicrosoft Entra ID (Azure AD) を使っているケースは多く、そんな中Oktaとどう連携させるかのひとつのパターンとして参考にしてくれたら嬉しいです
最近X（旧Twitter）を始めましたので、よければこちらもご覧ください
https://twitter.com/oha_rafu
