こんにちはたつみんです。
今回はタイトルそのままなのですが、Oktaユーザーアクティベーション時にモバイル版Okta Verifyをセットアップをせずにデスクトップ版Okta Verifyのセットアップのみを行いOkta FastPassを使いたいというニッチなニーズへの対応方法のご案内です。
背景
このニーズの背景には個人所有のスマートフォンに対してモバイル版Okta Verifyを導入することに抵抗感があり難しく、会社支給のスマートフォンの配備もこれからのためモバイル版Okta Verifyの登録をスキップしたい。ただし、Windows端末やMac端末ではFastPassは利用したいのでデスクトップ版Okta Verifyのセットアップを行わなければならないという事情があります。
考え方
背景で記載したとおりFastPassを利用するにはアクセスするデバイス上でOkta Verifyの登録が必要となりますが、ユーザーアクティベーションのタイミングでOkta Verifyの登録を必須化するとモバイル版Okta Verifyアプリの登録を促されてしまいます。
そのため今回のようなケースではユーザーアクティベーション時にOkta Verifyの登録を必須化せずにオプションとすることでモバイル版Okta Verifyの登録をスキップ可能とし、アクティベーション完了後にFastPassを利用するタイミングでデスクトップ版Okta Verifyのセットアップを行うことで実現します。
だだしこの手法は後述する課題もあるため、一時的なものとする事が望ましいです。
実施すること
- 専用Oktaグループの作成
- Global Session Policyの設定
- AuthenticatorsのEnrollment Policyの設定
- Okta Dashboardに対するAuthentication Policyの設定
専用Oktaグループの作成
今回は一時的な対応を想定しているため、専用Oktaグループを作成します。この記事では割愛しますが各種ポリシーに存在するEveryoneグループを対象としたデフォルトポリシーもしくはルールには恒久的に適用するいわば理想像をあらかじめ作成しておきます。そのデフォルトポリシーもしくはルールの上位に今回作成するポリシーやルールを専用Oktaグループにのみに適用するように作成するという発想とします。
これにより今回ご紹介する一時的な対応が不要となった場合に作成したポリシーやルールを無効化・削除することで恒久的なポリシーやルールにすぐにスイッチすることができます。また専用Oktaグループのメンバーシップ変更により段階的な移行を行うことも可能となります。
今回は以下のようにOkta Verify Optional Enroll Groupという名称で作成しました。
Global Session Policyの設定
Global Session PolicyでMFAを要求してしまうとユーザーアクティベーションのタイミングで必ずMFAをセットアップしなければならなくなります。
そこで下図のようにPolicyを追加し、先ほど作成したグループのみを指定します。Policy内のRuleではMultifactor authentication (MFA)をNot Requiredと指定します。
なお、PoicyやRuleの名称は設定内容に応じて命名しておくことでログを確認したときに意図したPoiicyやRuleを通過したかを確認することができます。名称内のGSPはGlobal Session Policyが長いので頭文字を取り表現しました。
AuthenticatorsのEnrollment Policyの設定
次に今回のキーポイントであるアクティベーション時に要求するAuthenticatorについて定義します。ここでも下図のようにPolicyを追加し、先ほど作成したグループのみを指定し、Okta VerifyをOptionalとします。
Policy内のRuleについてはルール名のみ設定しその他の項目はデフォルトのままとしました。
Okta Dashboardに対するAuthentication Policyの設定
ユーザーアクティベーションを行うタイミングではOkta Dashboardに対するAuthentication Policyも考慮する必要があります。ここでMFAを要求してしまうとアクティベーションが完了できずに詰みの状態となります。
そのため、下図のようにOkta Dashboardに紐づいているAuthentication Policyであるポリシー名：Okta Dashboardに対してRuleを追加します。この時も先ほど作成したグループのみを指定し、Alny 1 factor typeを指定します。
ユーザー操作の流れ
Okta管理者側の設定が完了したので、次にユーザーが実際にアクティベーションを行う際の挙動を確認してみます。
- Oktaへようこそ！のメールからアクティベーションリンクをクリック
- パスワードの設定を実施
- Okta Verifyアプリのセットアップで[あとで設定]を選択
これでモバイル版Okta Verifyアプリのセットアップをせずに初回アクティベーションが完了し、Okta Dashboardへのログインが完了します。
次にデスクトップ版Okta Verifyのセットアップを行う手順については下記のような流れとなります。
- Okta Dashboardからサインアウトを実施
- Okta FastPassでサインインをクリック
- デスクトップ版Okta Verifyアプリのダウンロードを実施
- デスクトップ版Okta Verifyアプリ上でアカウントの追加を実施
- 追加時にブラウザで行う認証作業はID/Passwordのみで実施
- 必要に応じてTouch IDの有効化も実施
基本的に実施している内容は以下のブログのOkta Verify設定部分と同等です。
これによりデスクトップ版Okta Verifyのセットアップが完了しました。次回以降のサインイン時にはOkta FastPassでサインインをクリックすることでデスクトップ版Okta Verifyアプリが起動し認証を行うことが可能となります。
課題
今回の内容では背景に記載した内容をクリアすることができ万事解決かと思うかもしれませんが、モバイル版Okta Verifyのセットアップをせずにデスクトップ版Okta Verifyアプリのみがセットアップされている場合は以下のような制約事項があります。
- 端末交換時などで新しい端末側でユーザー自身でデスクトップ版Okta Verifyのセットアップを行うことができない
これは新しい端末上でデスクトップ版Okta Verifyを登録しようとするとセットアップ済みの追加の認証要素が求められてしまいます。この時に登録されている認証要素が旧端末上のデスクトップ版Okta Verifyしかない場合は追加認証を検証できずにループに陥ります。デスクトップ版Okta Verifyはその端末を飛び越えて、端末外で行われる認証に関与することができないからです。
以下についても課題となることがあります。
- Jamf Connect利用時やAzure AD Join時
この理由も根本的には先ほどと同等で登録されている認証要素がデスクトップ版Okta Verifyしかない場合は追加認証を検証することができないためです。
解決策は以下の2点のどちらかです。
- Okta管理者によってすべての追加の認証要素をリセットする
- 追加の認証要素として、取り外し可能な物理的なセキュリティキーやモバイル版Okta Verifyなどの認証要素を登録する
Okta管理者による認証要素のリセットは端末交換時は問題ありませんが、同時に2台の端末を利用するような場合は適していいません。また、取り外し可能な物理的なセキュリティキーやモバイル版Okta Verifyの利用は今回のニーズから外れてしまいます。
最後に
今回は技術的には可能であることを確認できましたが、推奨できる構成であるとは言い難い内容でした。もしこの構成を取る場合は課題に記載の内容をよく理解し一時的な利用として割り切ったほうがよいでしょう。今後、デスクトップOkta VerifyがPush通知に対応してくれれば、他の端末での認証にも利用できるようになり、より取り回しがよくなるかと思うのでぜひアップデートしてほしいなと思います。
また、背景にある私物のモバイルデバイスを認証要素として利用させたくないというのは組織の考え方にもよるので、一概に答えを出せるものではありません。しかし個人的には懸念することはあまりないという見解です。もし、懸念する点が私物のモバイルデバイスから会社の情報資産へのアクセスという場合は、認証要素としての利用とは切り離して、Device Trust等で制御を行うことを検討すべき内容です。
IdPを導入検討する際には利用しているSaaSがSSO対応しているんだっけ？等さまざま検討事項がありますが、認証要素ってどうするんだっけ？何が利用できるんだっけ？という点も忘れずにあらかじめ押さえておきましょう。
それでは今日はこのあたりで！また別の記事で〜?
