こんにちは！たつみんです。
Okta Identity Engine（通称：OIE）でパスワードを持たないユーザーが作れるようになったとのことなので検証してみました。
はじめに
OIEではFastPassに代表されるような方法でパスワードを使わずに認証を行うことができるようになりましたが、依然としてパスワード自体は存在し続けている状態です。
今回の検証を通して、パスワードを一切持たないユーザーを作成できるか、またユーザーが体験する実際の挙動についても触れていきたいと思います。
設定方法
以下のドキュメントを参考に設定を行います。
検証用グループの作成
今回の検証内容の影響範囲を限定的に行うために、検証用グループとしてPasswordless Test Groupという名称のグループを作りました。
以降の設定ではこのグループを指定し、ポリシーを作成・適用していきます。
認証要素の設定
- Security>AuthenticatorsのSetupからEmailをAuthentication and recoveryとして設定します。
- Enrollment内で以下のように検証用グループを指定し、Eligible AuthenticatorsでEmailをRequiredに、PasswordはDisabledにします。
- ルールについては名称のみを入力し、特に条件を設定せずに進めます。
- 以下のようにポリシーが設定されていることを確認します。
ポリシーは上から順番に評価されます。Dafault Policyは最下層として固定されているため、合計で3つ以上のポリシーがある場合は順番に注意しましょう。今回のポリシーは最上位にしておくとよいでしょう。
ここまでの設定でEmailを認証要素として有効化し、検証用グループに対してEmailを必須化、パスワードについては無効する展開ポリシーを設定しました。
ユーザーの作成
事前準備ができたので実際にパスワードを持たないユーザーを作成してみます。
Directory>PeopleのAdd personからユーザー作成に必要な情報を入力します。 この時Groupsに検証用で作成したグループを指定します。
ユーザーのログイン体験について
パスワードを持たないユーザーを作成した際にアクティベーションメールなどは送付されません。
- まずユーザーはOktaのテナントURLにアクセスし、ユーザー名を入力します。
- 次にメールを送信するというボタンが表示されるためクリックします。
- メールを確認するとワンタイム認証コードという件名でメールが届きます。メールの中のサインイン部分をクリックするか6桁のコードを利用します。
- 今回はシークレットブラウザで検証を行っているため、コードを利用して確認を行いました。
- 追加の認証要素のセットアップが求められたのでOkta Verifyをセットアップします。
- 無事にダッシュボード画面まで表示されました。
パスワードについて確認をするためユーザーの設定を開きます。
- 下図のようにパスワードの部分に本来であればあるはずのリセットが表示されれおらずパスワードを持たないユーザーであることが確認できます。
- ユーザーは初回ログイン以降は設定したOkta Verifyなどを利用しログインを行うことが可能です。
注意点
Oktaダッシュボード含むアプリケーションのポリシーがPassword+Another factorのようにパスワードが存在することが前提となっている場合はあらかじめ変更もしくはパスワードを持たないユーザーのための新しいポリシーを追加で作成する必要があります。
また、下図のように初回ログイン時や新しいブラウザからの認証時にパスワードの選択肢が表示される場合があります。
これは以下のセキュリティ設定によるものです。
Security>General内のUser Enumeration PreventionがEnabledである場合に発生します。 この機能はユーザー名列挙攻撃から保護する目的があります。
既存ユーザーからパスワードを削除する
これまでの流れでは新規ユーザー作成時にパスワードを持たないようにすることができましたが、すでにパスワードを持っている既存ユーザーについてはどうでしょうか。
以下の方法で既存ユーザーからもパスワードを削除することが可能となります。
- 対象ユーザーを検証用グループに追加します。
- Directory>Peopleから対象ユーザーを表示し、Reset or Remove passwordをクリックします。
- 確認画面でRemove passwordをクリックします。
上記の2.3.は管理者がパスワードを削除する方法をご紹介しましたが、1.のグループへの追加を行った時点で下図のようにユーザー自身がパスワードを削除することが可能となります。
まとめ
おそらくここまでの流れを見てお気づきかもしれませんが、この検証ではいくつかの課題も見えてきました。
まずOIEでパスワードを持たないユーザーを作成するためにはEmailを必須の認証要素として設定する必要があります。
これは冒頭に紹介したドキュメントにも以下のように記載されています。
Unless email is set to Required, password cannot be set to Optional or Disabled. If the password is set to Optional or Disabled, you cannot set Security Question to Required as a stand-alone authenticator for authentication. However, it is allowed for account recovery.
メールシステム自体がOktaとSSO連携済みある場合に、新しく入社される方のアカウントをパスワードレスで作成してもユーザー体験としてはメールにアクセスできず、Oktaアカウントも利用できない状況となってしまいます。
また、Email自体は所持情報の一種と見做されますが、デバイスに紐づいてはいないため、あまり積極的には利用したくない認証要素のひとつだと感じています。
これらをクリアするにはAzure ADの一時アクセスパスのような仕組みがあれば、初回ログイン時の課題や好ましくない認証方法が残り続けるという課題が解消されそうです。
今後Oktaがより進化し、真のパスワードレスが実現することを期待しています。
真のパスワードレスについては同じIDチームのすかんくがブログを執筆予定とのことなので期待ですね！
それではまた〜！
