1.はじめに
無料でできるEntra IDによるSSO手順シリーズの番外編です。
Entra IDをIdP(IDプロバイダー)にしたSAML認証時のSP(サービスプロバイダー)に、Oktaを設定してみる記事となっています。
Oktaといえば、IDaaSの有名製品の１つですが、実はSPとしても動作させることができます。具体的には、Entra IDのエンタープライズアプリケーション（Entra IDと連携設定済みのSaaS)に、Oktaを設定することができます。例えば、Entra IDによる認証をさせることで、そのままOktaにアクセスさせることができます。そして、Oktaのログインフォーム入力時に、Entra IDにリダイレクトして、認証をさせることも可能です。
2.Okta Developer Edition
2-1.Okta Developer Editionとは
Okta Developer Editionとは、oktaの開発者向け環境です。なんとクレジットカード登録なしで、利用期限の制限もなく、さまざまなoktaの機能を利用することができるプランとなります。
私が気になる制約事項としては、SSOする状態がアクティブなアプリケーション数は、最大５個までという点くらいです。一応、アプリケーションのSSOの設定をしていても、インアクティブにしておけば、制限対象の対象外にはなります。
2-2.Okta Developer の登録
それでは、Okta Developer の登録をしていきます。Business用のドメインを取得しているメアド、または、Google Account、Githubアカウントを事前に用意しておいて下さい。
以下URLにアクセスし、「Sign up free for Developer Edition」を選択します。
https://developer.okta.com/signup/
私の場合は、GitHubのアカウントがあったので、Githubのボタンをクリックして、進みます。
住んでいる国情報を入れて、「Continue」を押します。
Githubの認証画面に遷移しますので、必要情報を入力して、github側の認証は完了させましょう。
しかし、このままではアクセスすることはできませんでした。
理由は、oktaの管理者向けコンソールに対するAuthentication Policyの設定が多要素になっているためとなります。今回のようなIdPによる認証だけだと、単一要素という判定になってしまい、アクセスNGとなりました。実際には、githubの認証時に多要素にはなっていますが、仕方ないですね。
次に、githubとリンクしているメールアドレスのメール受信箱を確認すると、oktaからwelcome mailが届いていました。こちらのSign inだと先ほどのようにアクセスできないので、「Set password」をクリックします。
すると、今回は無事oktaの管理者コンソール画面にアクセスすることができました。
しかし、このままだと、7日後には「Set password」からアクセスすることができなくなるので、Github側の認証が多要素になっているので、Authentication Policiesの設定を変更しておきます。
「Security > Authentication Policies」を選択し、「Okta Admin Console」を選択します。
Priorityが１になっているポリシーの「Edit」を選択します。
THENの「User must authenticate with」を「Any 1 factor type / IdP」に変更し、「Save」を選択します。
3.OktaをSP、Entra IDをIdPとしたSAML設定
ここからは、OktaをSP、Entra IDをIdPとしたSAML設定手順になります。
なお、最初はOIDC（OpenID Connect）利用した構成で作ろうとしたのですが、うまく作れなかったのですが、以下nextmodeさんの記事を参考にさせていただき、SAMLで設定を実施しました。
3-1.設定手順：アプリ登録
Entara管理センターに移動し、「アプリケーション > エンタープライズアプリケーション > 独自のアプリケーションの作成 」を選択します。そして、任意の名前を登録して、作成をクリックします。
「シングルサインオン > SAML」を選択します。
「基本的なSAML構成の編集」を選択します。ここには、oktaのエンティティIDや応答URLを入力する必要があるのですが、Entra ID側から発行された証明書がないと、oktaのエンティティIDや応答URLを生成することができません。そのため、後から変更することを前提にして、仮の情報をエンティティIDと応答URLに入力して、「保存」をクリックします。
上記入力を実施すると、「3 SAML証明書」のところで、「証明書(Base64)」の「ダウンロード」を選択できるようになりますので、証明書ファイルをダウンロードします。
Oktaの管理者コンソールに移動し、 「Security > identity Providers > Add identity provider」を選択します。
「SAML 2.0 IdP」を選択します。
以下の対応関係で入力していきます。デフォルト値はそのままにしています。
IdP Signature Certificateには、Entra管理センターでダウンロードした証明書をアップロードしましょう。
| 項目 | 入力値 |
|---|---|
| IdP Usage | SSO only |
| IdP username | idpuser.email ※仮入力。後で変更 |
| If no match is found | Create new user(JIT) |
| IdP Issuer URI | [Entra管理センター上のMicrosoft Entra 識別子] ※固有情報 |
| IdP Single Sign-On URL | [Entra管理センター上のログイン URL] ※固有情報 |
| Request Binding | HTTP POST |
作成が完了しますと、Summaryが表示され、「Assertion Consumer Service URL」と「Audience URI」が生成されます。
この「Audience URI」を「Entra管理センター上の基本的なSAML構成」の「識別子(エンティティID)」に入力し、「Assertion Consumer Service URL」を「Entra管理センター上の基本的なSAML構成」の「応答URL（Assertion Consumer Service URL)」に入力します。入力が完了しました。
忘れずに、「保存」を押して、再び、oktaの管理コンソールに戻ります。
3-2.設定手順：属性のマッピング
oktaの管理コンソールで、作成したIdPの 「Actions > Edit Profile and Mappings」 をクリックし、「Attributes > Mappings]」の画面へ進みます。
Entra IDからoktaへのマッピングは、最初は以下のようになっています。
これを「source.userName」だけ残し、すべて停止させます。設定変更後は、以下のようになりますが、後で再度設定しなおします。
次は、「Custom」からすべての項目を消します。
もし既存のProfileと関連づいていることで消せない場合は、サイドメニューのProfile Editorから、消せない原因となっているProfileを探して、消す必要があります。
削除後は、以下になります。
一度Entra管理センターに戻り、マッピングさせたい属性を確認します。「属性とクレーム」のところで、各クレーム名のメモをとります。
Oktaの管理コンソールに戻り、「+ Add Attribute」を選択し、属性を４つ追加します。
例：UPNの場合
Display name：upn
variable name：upn
External name：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
作成後は、以下のようになります。
「Attributes > Mappings」 の画面へ進み、先ほど作ったカスタム属性を入力します。
最後に、仮で入れておいたIdPからログインする際のマッピングを、[メールアドレス] から [UPN] に変更します。「Identity Providers > Actions > configure Identity Provider」に移動し、IdP usernameの項目を「idpuser.upn」に変更します。
3-3.動作確認：IdP initiated SSO
これで、Entra IDを起点にしたSAML認証で、oktaにログインすることが可能となります。
M365のマイアプリより、oktaを選択してログインしてみます。
以下のようにOktaにログインすることができました。なお、この時点では、JITプロビジョニングでユーザを作成してログインしただけなので、後で、アプリの割り当てなどを実施する必要があります。
3-4.設定手順：SP initiated SSO
ここまででSAML設定自体は完了していますが、oktaのログインフォームで直接ログインすることはまだできません。そのため、oktaへのログインフォームで、Entra ID側の認証へとルーティングする設定をします。
「Security > Identity Provider > Routing rules」に移動し、「Add Routing Rule」を選択します。
そして、任意のRul Nameを入力し、「User matches」に「Domain list on login」を選択し、対象となるドメイン名を入力します。
例えば、ログインユーザが、 user@example.com だった場合は、example.com 部分を入力します。
そして、Identity Providerには、今回作成したIdentity Providerを選択します。
「Create rule > Activate」を入力します。
完了すると、以下のようなRuting rulesになります。
これによって、特定のドメインユーザは、Entra IDにフェデレーションされて認証されます。
3-5.動作確認：SP initiated SSO
それでは、oktaのログインフォームにユーザ名を入力してみましょう。
するとユーザ名を入力すると、Entra IDの認証に遷移し、必要情報を入力後には、Oktaにログインすることができました。
4.おわりに
Entra IDによるSAML認証の番外編として、OktaをSPにした場合の設定手順を確認しました。
Entra ID側の設定はいつも通りな気もしますが、okta側の設定も多々あり、属性のマッピングも考慮するとなかなか難しい面があったのではないでしょうか。
次回は、OktaをIdPにして、Entra ID(O365)側をSPにしたフェデレーション構成を記事にしたいと思います。リンクは下記です。