Okta Sign-on Policyを構成する

Okta Sign-on Policyでは、Oktaにアクセスできるユーザー、Oktaにアクセスできる場所、本人確認の方法を指定できます。Okta Sign-on Policyを作成するには、ポリシーを作成してルールを追加する必要があります。

Oktaにはデフォルトで、リストに1つのデフォルトのOkta Sign-on Policyがあります。このポリシーの設定をカスタマイズして、包括的なポリシーとしてOrganizationのすべてのユーザーに適用することができます。次に、さらにOktaサインオンポリシーを追加して、特定のユーザーグループに適用できます。たとえば、特定のネットワークゾーンからのみOktaにサインインできる特定のユーザーグループ、認証方法、セッションの長さなどを指定できます。

Oktaは、リストに表示されている順序で、リストの最上部からポリシーを評価します。Oktaは、サインイン試行を満たすポリシーが見つかるまで、各ポリシーに対するサインイン試行を検証します。サインイン試行がいずれのカスタムポリシーの要件も満たさない場合、OktaはデフォルトのOkta Sign-on Policyに対してサインイン試行を検証します。サインイン試行がいずれかのポリシーの要件を満たす場合、残りのポリシーは検証されず、ユーザーはOktaにアクセスできます。Oktaでは、リストの並び順は最も制限の高いポリシーを最上部に、最も制限の低いポリシーを下から2番目に、デフォルトのOkta Sign-on Policyを最下部に配置することを推奨しています。

  • Okta Sign-on Policyを作成したら、新しいポリシーを有効にするために、アクティブなセッションをすべて閉じる必要があります。
  • Oktaサインオンポリシーは、APIトークンの有効性やライフタイムには影響しません。「APIトークンの管理」を参照してください。

Oktaサインオンポリシーを作成する

  1. Admin Consoleで[Security(セキュリティ)][Authentication(認証)]に進みます。

  2. [Sign On(サインオン)]タブをクリックします。

  3. [Add New Okta Sign-on Policy(新規Oktaサインオンポリシーを追加)]をクリックします。

  4. 以下のフィールドに入力します。

    • [Policy Name(ポリシー名)]:サインオンポリシーの名前を入力します。

    • [Policy Description(ポリシーの説明)]:オプションです。Okta Sign-on Policyの説明を入力します。

    • [Assign to Groups(グループに割り当てる)]:ポリシーを適用するグループの名前を入力します。ポリシーは複数のグループに適用できます。

  5. [Create Policy and Add Rule(ポリシーを作成してルールを追加)]をクリックします。

Okta Sign-on Policyルールを追加する

  1. [Add Rule(ルールを追加)]をクリックして、ルールをポリシーに追加します。必要に応じて以下のフィールドに入力します。

ルール名 作成するルールのわかりやすい名前を追加します。
ユーザーを除外 必要に応じて、グループの個々のユーザーをルールから除外できます。
IF User's IP is(ユーザーのIPが次の場合) ドロップダウンメニューを使用して場所のパラメーターを割り当てます。認証を求める場所の種類を指定できます。「ネットワークゾーン」と「動的ゾーン」を参照してください。
AND[Identity provider is(IDプロバイダーが次)]

使用するIDプロバイダーを選択します。 詳細については、「IDプロバイダー」を参照してください。

AND[Authenticates via(次で認証)] 必要な認証方法を選択します。
AND[Behavior is(挙動)]

以前に作成された既存の動作の名前を入力します。動作を追加するには、動作名の入力を開始します。一致するすべての定義済みの動作のドロップダウンリストが表示され、そこから動作を選択できます。追加する各動作についてこれを繰り返します。複数の動作を追加する場合は、OR条件として扱われます。「サインオンポリシールールに動作を追加する」を参照してください。

リスクの高い動作に対しては、予備の要素の要件を[Every time(毎回)]に設定します。動作条件をper device(デバイスごと)またはper session(セッションごと)の予備の要素の要件と組み合わせないでください。

Okta Admin Consoleで毎回再認証することをお勧めします。

AND[Risk is(リスクレベル)]

リスクスコアリングでは、データ主導のリスクエンジンを使用して、各サインインイベントが異常なアクティビティを表す可能性が高いかどうかを判断します。[Low(低)]、[Medium(中)]、または[High(高)]のリスクレベルを選択します。

[High(高)]を選択した場合は、予備の要素の要件を[Every time(毎回)]に設定します。高リスクレベルをper device(デバイスごと)またはper session(セッションごと)の予備の要素の要件と組み合わせないでください。

リスクスコアリング」を参照してください。

THEN[Access is(アクセスの可否)] 前のドロップダウンリストの認証フォームに基づき、このフォームを使用して条件がアクセスを許可または拒否するかを決定します。

[認証]

多要素認証が必要かどうかを示します。

[Users will authenticate with(ユーザーの認証方法)]

ユーザーの認証方法を選択します。

  • [Password / Any IdP(パスワード/任意のIdP)]:パスワードおよびOrg用に構成された任意のIDプロバイダーを使用します。

  • [Password / Any IdP + Any authenticator(パスワード/任意のIdP+任意のAuthenticator)]:パスワード、Org用に構成された任意のIDプロバイダー、Org用に構成された任意の要素を使用します。

  • [Factor Sequence(要素シーケンス)]:ユーザーがOktaにサインインしたときに表示されるMFA要素のシーケンスを指定します。手順は「MFA要素シーケンシング」を参照してください。

[Users will be prompted for MFA(ユーザーにMFA用のプロンプトを表示)]

ユーザーが多要素認証を使用する必要がある場合に、使用するためのプロンプトがいつ表示されるかを示します。

  • [At every sign in(サインイン毎)]:ユーザーは、Oktaにサインインするたびに多要素認証を求められます。
  • [When signing in with a new device cookie(新しいデバイスCookieでサインインする場合)]:ユーザーが新しいデバイスでサインインしようとしたとき、または既存のデバイスからCookieが削除された場合に、ユーザーは多要素認証を求められます。ユーザーが[Sign-In Widget]で[Do not challenge me on this device again(次回からこのデバイスではチャレンジしない)]を選択して認証が成功した場合、MFAはデバイスのCookieを記憶します。デバイスのCookieが有効になっている限り、ユーザーはサインイン時にMFAを求められることはありません。
  • [After MFA lifetime expires for the device cookie(デバイスCookieのMFAのライフタイムが期限切れになった後)]:ユーザーは、MFAのライフタイム期間が期限切れになった後にサインインしようとすると、多要素認証を求められます。サインインウィジェットでユーザーがDo not challenge me on this device again for the next(次回はこのデバイスではチャレンジしない)]を選択して認証が成功した場合、MFAはデバイスのcookieを記憶します。デバイスのcookieが有効になっている限り、ユーザーはサインイン時にMFAを求められることはありません。
    • [MFA lifetime(MFAのライフタイム)]:このオプションは、[After MFA lifetime expires for the device cookie(デバイスCookieのMFAのライフタイムが期限切れになった後)]を選択すると表示されます。右側のフィールドに数値を入力し、ドロップダウンリストから値を選択します([Days(日)][Hours(時間)][Minutes(分)])。
  • [Select "Don't prompt me again for MFA" by default(「次回からMFAのプロンプトを表示しない」をデフォルトで選択する]:このオプションを選択すると、デフォルトで多要素認証のプロンプトをユーザーに表示しません。

セッションライフタイム

Oktaセッションの長さを構成します。

[Maximum Okta session lifetime(Okta最大セッションライフタイム)]

Oktaセッションライフタイムを構成します。

  • [No time limit(時間制限なし)]:このオプションを選択すると、Oktaセッションに時間制限は適用されませんが、ユーザーセッションはアイドル時間に達すると期限切れになります。

  • [Set time limit(時間制限を設定)]Oktaセッションライフタイムに時間制限を設定します。右側のフィールドに数値を入力し、ドロップダウンリストから値を選択します([Days(日)][Hours(時間)][Minutes(分)])。

  • Admin Consoleのセッションライフタイムは、このグルーバル設定とは無関係に設定できます。「管理コンソールのセッションライフタイムを構成する」を参照してください。

[Expire session after user has been idle on(ユーザーがOktaで次の間アイドル状態になった後にセッションを期限切れにする)]

Okta最大セッションライフタイムに関係なく、Oktaセッションが自動的に期限切れになるまでのアイドル時間を構成します。

  • 右側のフィールドに数値を入力し、ドロップダウンリストから値を選択します([Days(日)][Hours(時間)][Minutes(分)])。

Admin Consoleのタイムアウトは、このグルーバル設定とは無関係に設定できます。「Admin Consoleのセッションライフタイムを構成する」を参照してください。

[ブラウザーセッション間でセッションクッキーを保持]

ブラウザーセッション間でのセッションCookieの保持を有効化または無効化します。ドロップダウンリストからオプションを選択します。

  • [Enable(有効化)]:ユーザーが希望する場合に、セッションCookieがブラウザーセッション間で保持されることを許可します。この機能を有効化するには、ユーザーが[Sign-In Widget][Keep me signed in(サインインしたままにする)]を選択する必要があります。

  • [Disable(無効化)]:セッションCookieがブラウザーセッション間で保持されることを許可しません。

セッションライフタイムの最大値は、Okta APIを通じて設定できます。以前にAPIでこの数値を設定した場合、Oktaのアプリでその最大値を超えることはできません。APIの最大値を超える数値を設定すると、エラーが発生します。

複数のOktaサインオンポリシーを追加する場合、基準に一致する最初のポリシーのみが適用されます。

ユニバーサルなOkta Sign-on Policyのアクション

  • 以下のポリシー1の左側に表示されている、ポリシー名の横にある点線のバーをつかみ、リスト内の目的の位置にポリシーを移動して、デフォルトポリシーを除くすべてのポリシーの順序を変更します。

  • ルール名の左側にあるバーをつかみ、ポリシー内のルールの順序を変更します。
  • [Add New Okta Sign-on Policy(新しいOktaサインオン ポリシーを追加)]を選択して新しいポリシーを追加します。

個別のOkta Sign-on Policyのアクション

1つのポリシーに対して次のアクションを実行できます。リストからポリシーを選択して開始します。

  • 選択したポリシーをアクティブ化または非アクティブ化します。ポリシーを非アクティブ化した場合、そのポリシーはどのユーザーにも適用されませんが、後で再アクティブ化できます。
  • ポリシーを編集するには、[Edit(編集)]をクリックします。
  • ポリシーを削除するには、[Delete(削除)]をクリックします。デフォルトのポリシーは削除できません。削除されたポリシーは復元できません。
  • 選択したポリシーにルールを追加するには、[Add Rule(ルールを追加)]をクリックします。ポリシー内で、ルールをアクティブ化、非アクティブ化、編集、または削除できます。
  • ルールの詳細を表示するには、[Add Rule(ルールを追加)]でルール名をクリックします。

認証前サインオン評価ポリシー

AuthN APIを使用してサインインするエンドユーザーは、パスワードまたはその他の要素が確認される前に、まずサインオンポリシーが評価されます。この評価は、Org全体で発生するアカウントロックアウトの数を減らすために役立ちます。

サインオンポリシーが[deny(拒否)]に設定されている場合、ユーザーのサインオン試行は拒否され、「Authentication failed(認証に失敗しました)」という一般的なエラーがプロンプトに表示されます。このシナリオでは、失敗したログイン数のカウンターは増加しませんが、代わりに認証前サインオンポリシーの評価を示すイベントがトリガーされます。

  • このバックエンド機能を有効にするために、Admin ConsoleでUIを変更したり、設定を行う必要はありません。
  • このポリシーは、JITプロビジョニングを使用するために構成された、新しく作成されたアカウントの初期認証では機能しません。このポリシーの影響を受けるには、エンドユーザーアカウントがOktaに存在している必要があります。
  • このポリシーでは、ユーザーが拒否された場所から資格情報をリセットすることは妨げません。

関連項目

Oktaサインオンポリシー

MFA登録ポリシー

パスワードポリシー

アプリのサインオンポリシー

MFA登録ポリシーを構成する

アプリサインオンポリシーを構成する

パスワードポリシーを構成する