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 Sign-on Policyを作成する
-
Admin Consoleで、[Security(セキュリティ)] > [認証]に移動します。
-
[Sign On(サインオン)]タブをクリックします。
-
[Add New Okta Sign-on Policy(新規Oktaサインオンポリシーを追加)]をクリックします。
-
以下のフィールドに入力します。
-
[ポリシー名]:サインオンポリシーの名前を入力します。
-
[ポリシーの説明]:オプションです。Okta Sign-on Policyの説明を入力します。
-
[Assign to Groups(グループに割り当てる)]:ポリシーを適用するグループの名前を入力します。ポリシーは複数のグループに適用できます。
-
-
[ポリシーを作成してルールを追加]をクリックします。
Okta Sign-on Policyルールを追加する
-
[ルールを追加]をクリックして、ルールをポリシーに追加します。必要に応じて以下のフィールドに入力します。
[Rule Name(ルール名)] | 作成するルールのわかりやすい名前を追加します。 |
[Exclude Users(ユーザーを除外)] | 必要に応じて、グループの個々のユーザーをルールから除外できます。 |
IF [User's IP is(ユーザーのIP)] | ドロップダウンメニューを使用して場所のパラメーターを割り当てます。認証を求める場所の種類を指定できます。「ネットワークゾーン」と「動的ゾーン」を参照してください。 |
AND [Identity provider is(IDプロバイダー:)] |
使用するIDプロバイダーを選択します。 詳細については、「IDプロバイダー」を参照してください。 |
AND [Authenticates via(次で認証:)] | 必要な認証方法を選択します。 |
AND [Behavior is(動作:)] |
以前に作成された既存の動作の名前を入力します。動作を追加するには、動作名の入力を開始します。一致するすべての定義済みの動作のドロップダウンリストが表示され、そこから動作を選択できます。追加する各動作についてこれを繰り返します。複数の動作を追加する場合は、OR条件として扱われます。「サインオンポリシールールに動作を追加する」を参照してください。 リスクの高い動作に対しては、予備の要素の要件を[Every time(毎回)]に設定します。動作条件をデバイスごとまたはセッションごとの予備の要素の要件と組み合わせないでください。 |
AND [Risk is(リスクレベル)] |
リスクスコアリングでは、データ主導のリスクエンジンを使用して、各サインインイベントが異常なアクティビティを表す可能性が高いかどうかを判断します。[Low(低)]、[Medium(中)]、または[High(高)]のリスクレベルを選択します。 [High(高)]を選択した場合は、予備の要素の要件を[Every time(毎回)]に設定します。高リスクレベルをデバイスごとまたはセッションごとの予備の要素の要件と組み合わせないでください。 「リスクスコアリング」を参照してください。 |
THEN [Access is(アクセスの可否)] | 前のドロップダウンリストの認証フォームに基づき、このフォームを使用して条件がアクセスを許可または拒否するかを決定します。 |
[認証] |
多要素認証が必要かどうかを示します。 |
[Users will authenticate with(ユーザーの認証方法)] |
ユーザーの認証方法を選択します。
|
[Users will be prompted for MFA(ユーザーにMFA用のプロンプトを表示)] |
ユーザーが多要素認証を使用する必要がある場合に、使用するためのプロンプトがいつ表示されるかを示します。
|
セッションライフタイム |
Oktaセッションの長さを構成します。 |
[Maximum Okta session lifetime(Okta最大セッションライフタイム)] |
Oktaセッションライフタイムを構成します。
|
[Expire session after user has been idle on Okta for(ユーザーがOktaで次の間アイドル状態になった後にセッションを期限切れにする:)] |
Okta最大セッションライフタイムに関係なく、Oktaセッションが自動的に期限切れになるまでのアイドル時間を構成します。
|
[Persist session cookies across browser sessions(ブラウザーセッション間でセッションCookieを保持)] |
ブラウザーセッション間でのセッションCookieの保持を有効化または無効化します。ドロップダウンリストからオプションを選択します。
|
セッションライフタイムの最大値は、Okta APIを通じて設定できます。以前にAPIでこの数値を設定した場合、Oktaのアプリでその最大値を超えることはできません。APIの最大値を超える数値を設定すると、エラーが発生します。
複数のOktaサインオンポリシーを追加する場合、基準に一致する最初のポリシーのみが適用されます。
ユニバーサルなOkta Sign-on Policyのアクション
- 以下のポリシー1の左側に表示されている、ポリシー名の横にある点線のバーをつかみ、リスト内の目的の位置にポリシーを移動して、デフォルトポリシーを除くすべてのポリシーの順序を変更します。
- ルール名の左側にあるバーをつかみ、ポリシー内のルールの順序を変更します。
- [Add New Okta Sign-on Policy(新しいOktaサインオン ポリシーを追加)]を選択して新しいポリシーを追加します。
個別のOkta Sign-on Policyのアクション
1つのポリシーに対して次のアクションを実行できます。リストからポリシーを選択して開始します。
- 選択したポリシーをアクティブ化または非アクティブ化します。ポリシーを非アクティブ化した場合、そのポリシーはどのユーザーにも適用されませんが、後で再アクティブ化できます。
- ポリシーを編集するには、[編集]をクリックします。
- ポリシーを削除するには、[削除]をクリックします。デフォルトのポリシーは削除できません。削除されたポリシーは復元できません。
- 選択したポリシーにルールを追加するには、[ルールを追加]をクリックします。ポリシー内で、ルールをアクティブ化、非アクティブ化、編集、または削除できます。
- ルールの詳細を表示するには、[ルールを追加]でルール名をクリックします。
認証前サインオン評価ポリシー
AuthN APIを使用してサインインするエンドユーザーは、パスワードまたはその他の要素が確認される前に、まずサインオンポリシーが評価されます。この評価は、Org全体で発生するアカウントロックアウトの数を減らすために役立ちます。
サインオンポリシーが[deny(拒否)]に設定されている場合、ユーザーのサインオン試行は拒否され、「Authentication failed(認証に失敗しました)」という一般的なエラーがプロンプトに表示されます。このシナリオでは、失敗したログイン数のカウンターは増加しませんが、代わりに認証前サインオンポリシーの評価を示すイベントがトリガーされます。
- このバックエンド機能を有効にするために、Admin ConsoleでUIを変更したり、設定を行う必要はありません。
- このポリシーは、JITプロビジョニングを使用するために構成された、新しく作成されたアカウントの初期認証では機能しません。このポリシーの影響を受けるには、エンドユーザーアカウントがOktaに存在している必要があります。
- このポリシーでは、ユーザーが拒否された場所から資格情報をリセットすることは妨げません。