Okta Classic環境の認証をOkta Identity Engineに任せてみた

はい、どーもこんにちは！たつみんです。

このブログ記事では前回のブログ記事『弊社Okta環境をOkta Identity Engineにお引越ししました』の中でキーとなったOktaのOrg2Orgについて具体的な内容をご紹介したいします。

はじめに

今回Org2Orgを通して実現したいのは以下の項目です。

• Device Trustの展開を早期に実現する
• ユーザーはSPがClassic環境に紐づいているかOIE環境に紐づいているか意識しなくても利用ができる状態
• Classic環境で設定済みのOkta Verifyなどの認証要素の利用をなくし、OIE環境に一本化する
• 管理者がSP移行を行なってもユーザー体験が損なわれることがない状態

Org2Orgについて

前回のブログでは2つのテナントをOrg2Orgという機能で結ぶと記載しましたが、具体的にはOIE環境をIdPとしてClassic環境をSPとして設定します。SPとしてのClassic環境はIdPとしても機能していますので、SPとしてGoogle WorkspaceなどのSaaSが存在しています。

例えばユーザーがOrg2Orgしている環境でClassic環境に紐づくGoogle Workspaceにサインインしようとすると以下のような流れとなります。

1. Google WorkspaceにアクセスしユーザーID（メールアドレス）を入力する
2. SPであるGoogle WorkspaceからみたIdPであるClassic環境へリダイレクトされる
3. IdPルーティング設定によってClassic環境に対するIdPであるOIE環境にリダイレクトされる
4. OIE環境はユーザーに対し認証を要求する
5. ユーザーがFastPass等を利用しOIE環境に対して認証を行う
6. OIE環境がユーザーに対してSAMLアサーションが発行する
7. ユーザーはClassic環境に対して認証が行われる
8. Classic環境がユーザーに対しSAMLアサーションを発行する
9. ユーザーはGoogle Workspaceに認証が行われアクセス可能となる

シーケンス図で表すと以下のようになります。

関連用語について

Okta公式ドキュメントではOrg2OrgのことをHub＆Spokeと記載していることがあります。そのようなドキュメントを参照される場合は下記に照らして読み替えていただければと思います。

HubとはSPともなるOktaテナントのことです。このブログ記事の中ではClassic環境がHubにあたります。
SpokeとはHub側のIdPとなるOktaテナントのことです。この記事の中ではOIE環境がSpokeにあたります。

設定手順

SSO設定

ここではまずIdPとしてのOIE環境に、SPとしてClassic環境を追加することでSAML認証を行えるようにします。

1. OIE環境でOkta管理画面へログインし、Applications>Applications>Browse App Catalogをクリックします。
2. Org2Orgと検索しAdd Integrationをクリックします。
   
3. General　Settings画面でApplication labelを確認し、必要に応じて変更し、Nextをクリックします。
   Base UrlはOIE環境からClassic環境に対してユーザープロビジョニングを行う場合のみ入力します。今回の要件では不要であるため省略しています。
   
4. Sign-On Options画面でSign on methodsでSAML 2.0を選択し、View SAML setup instructionsをクリックします。
   このSign-On Options画面は開いたままにしておきます。
   
5. Classic環境のOkta管理画面でSecurity>Identity Providersに移動し、Add Identity Providerをクリックします。
   
6. SAML2.0 IdPを選択し、Nextをクリックします。
   
7. OIE環境のView SAML setup instructionsに表示された内容を参考に設定を行います。
   証明書はダウンロードし、okta.crtとして保存後にClassic環境にアップロードします。
   
8. Classic環境での設定が完了すると以下のようにAssertion Consumer Service URLとAudience URIが表示されます。
   
9. 4.で開いたままのOIE環境のSign-On Options画面でAdvanced Sign-on SettingsのHub ACS URLに8.で表示されたAssertion Consumer Service URLを入力します。
10. Audience URIに8.で表示されたAudience URIを入力し、Doneをクリックします。
    
11. Assignmentsタブでユーザーをアサインします。
12. OIE環境のOktaダッシュボードからOkta Org2OrgアプリをクリックすることでClassic環境にOIE環境の認証情報を用いてSSOが行えることを確認します。

ここまでの設定でOIE環境を起点としたClassic環境へのSSOつまりIdP-Initの動作が確認できたこととなります。

SP-Initという観点では、Classic環境のサインイン画面からの遷移の中でまだClassic環境の認証情報で認証を行います。つまりユーザーはIdP-InitかSP-Initかで利用する認証情報を使い分けなければなりません。このことはユーザー体験としては非常に悪く、混乱を招いてしまいます。

そこで以降ではClassic環境からの認証つまりSP-Initの場合であってもOIE環境の認証情報のみを利用できるようにIdPルーティング設定を行います。

またOIE環境からClassic環境にSSOを行なったあとにClassic環境側のMFAが要求されてしまう状態のため、Classic環境のSign On Policyを変更し、これを回避します。

IdPルーティング

事前準備

IdPルーティングを行うユーザーかどうかを制御するためにカスタム属性を追加しておきます。

1. Classic環境のOkta管理画面でDirectory>Profile EditorからOkta(user）をクリックします。
   
2. Add Attributeをクリックします。
3. 以下のようにDisplay name等を入力し、Save Attributeをクリックします。
   

各ユーザーのプロファイルを編集しIdPルーティングを行わないユーザーにFalseを設定します。検証段階では一部のユーザーに対象を絞るかと思いますので大多数のユーザーに対してFalseを設定しておきます。CSV Importを利用し更新するとよいでしょう。

IdPルーティング設定

1. Classic環境のOkta管理画面でSecurity>Identity Providersに移動し、Routing rulesからAdd Routing Ruleをクリックします。
   
2. 以下のようにIdPルーティングを行わないユーザー用のRuleを作成します。
   User matchesで事前準備で作成したカスタム属性、条件式、値を指定
   Use this Identity providerでデフォルトのOktaを指定
   
3. 以下のようにIdPルーティングを行うユーザー用のRuleを作成します。
   User matchesでデフォルトのAnythingを指定
   Use this Identity providerでSSO設定 7.で作成した設定名を指定
   

なお、作成したRouting Ruleは上から評価されるため手順2.で作成したRuleが最上位に手順3.で作成したRuleが下位に位置するようにします。

検証フェーズが終わり運用フェーズの段階つまり、Org2Orgを全体適用をする場合はカスタム属性で設定していたFalseを削除します。最終的にFalseが設定されるのは一部のシステムアカウントのみとなります。また新入社員のアカウント作成時にカスタム属性の更新を行う必要がないようにあえて、3.の設定ではUser matchesをAnythingとしています。

特に弊社の場合は新入社員のアカウント作成をWorkatoで自動化しているため改修が発生しないようにするという意図もあります。

Classic環境のMFA除外設定

事前準備

Classic環境でMFAを除外するユーザー用のグループを作成します。

弊社の場合は雇用形態によってなんらかのグループに所属するため、それを条件にグループに所属させるようにGroup Rulesで設定を行いました。

MFA要求しないSign On Policyの作成

1. Classic環境のOkta管理画面でSecurity>Authenticationに移動し、Sign OnタブからAdd New Okta Sign-on Policyをクリックします。
   
2. Assign to groupsで事前準備で作成したグループを指定します。
   
3. Add ruleをクリックし、Users will authenticate withをPassword / Any IDPを指定しSaveをクリックします。
   
   

Multifactor Enrollment Policyの作成

新入社員のためにOktaアカウント初期セットアップの段階でMFAの登録を除外するためのPolicyを作成します。ただし、Classic環境のOkta管理者はAdminダッシュボードにアクセスするためにMFA登録が必要なため、そのPolicyも作成します。

1. Classic環境のOkta管理画面でSecurity>Multifactorに移動し、Factor EnrollmentタブからAdd Mulitifactor Policyをクリックします。
   
2. Okta管理者をまとめたグループを指定し、Okta Verifyの登録を必須とする以下のようなPolicyとRuleを作成しました。
   
3. 事前準備で作成したグループを指定し全てのMFA要素をDisableとし、Enroll in multi-factorをdo not enrollとしたRuleを作成します。
   

なお、作成したMulitifactor Policyは上から評価されるため手順2.で作成したRuleが最上位に手順3.で作成したRuleが下位に位置するようにします。

新入社員のアカウント作成時の注意点

これまでの設定を行い全体適用を行なった運用フェーズでは、Okta管理者を除いてClassic環境のパスワードやOkta Verifyなどの認証情報はまったく利用しなくなります。

この状況ではClassic環境で新入社員のアカウントを作成する際に初回ログイン時のパスワードの変更要求はOffとします。このように設定することで新入社員はOIE環境のOktaアカウント初期セットアップのみでClassic環境でのOktaアカウント初期セットアップについて操作を行う必要がなくなります。

弊社の場合はWorkatoで行っている処理のため、担当者に改修依頼を行いました。
Okta管理画面上での作業の場合は下記のUser must change password on first loginの部分のチェックを外しておきます。

この部分を忘れてしまうと新入社員にClassic環境で利用することのないパスワードについてセットアップを求めることとなりユーザー体験が損なわれしまいます。

ブックマークアプリの設定

ブックマークアプリを設定することでSP移行を行う前の段階でもOIE環境のダッシュボードには見た目上に多くのSPが表示され、そのまま認証が行えるようになります。これによりユーザーはClassic環境のダッシュボードにアクセスする必要がなくなりユーザー体験の向上につながります。

1. OIE環境のOkta管理画面でApplications>Applications>Browse App Catalogをクリックします。
2. Bookmarkと検索しAdd Integrationをクリックします。
   
3. アイコンやApplication labelを設定します。
4. URL部分はOrg2OrgアプリのView SAML setup instructionsのIdP Single Sign On URLに?RelayState=を追加し、続けてClassic環境の対象アプリのGeneral内のEmbed Linkを追加します。
   View SAML setup instructionsのIdP Single Sign On URLがhttps://example-oie.okta.com/app/okta_org2org/xxxxxx/sso/samlで、
   Classic環境の対象アプリのGeneral内のEmbed Linkがhttps://example-classic.okta.com/home/boxnet/xxxxxx
   の場合は以下を設定します。
   https://example-oie.okta.com/app/okta_org2org/xxxxxx/sso/saml?RelayState=https://example-classic.okta.com/home/boxnet/xxxxxx
   
5. AssignmentsでClassic環境でアサインしているユーザーと同一のユーザーをアサインします。
6. これらの操作を必要な数だけ繰り返します。

SP移行とブックマークアプリの削除

これらの設定を行ったのちにSSO設定を徐々にClassic環境からOIE環境へSP移行します。移行が完了したタイミングでアプリケーション用のブックマークアプリは削除します。

最後に

改めてまとめてブログ記事にするとOrg2Orgを実現するため、新入社員をスムーズに迎えるために必要な設定が多岐にわたることが実感できます。

またこのブログでは紹介しませんでしたがユーザー向けにClassic環境とOIE環境と見た目の区別をするためにそれぞれのCustomizations>BrandingからLogoやFaviconを設定しておくとよいです。ユーザーがどちらのOkta環境のダッシュボードにアクセスしているかや認証時にどの経路を通っているかが分かりやすくなりトラブルシューティングに役立つことがあります。

ただこの設定はOkta管理画面には反映されないため、作業時はClassic環境とOIE環境どちらの環境を設定しているかを見失いがちになります。ブラウザーのタブグループの活用やウィンドウを分けるなど工夫しましょう。

それではまた別の記事でお会いしましょう〜?