ポリシーには 1 つ以上のアクセス ルールが含まれます。各ルールは、アプリケーション ポータルに対する全体としてのユーザー アクセスまたは指定された Web アプリケーションへのユーザー アクセスを管理するために構成できる設定値の集まりです。

ネットワーク範囲

各ルールについて、ネットワーク範囲を指定してユーザー ベースを決定します。ネットワーク範囲は、1 つ以上の IP 範囲から構成されます。アクセス ポリシー セットを構成する前に、[セットアップ] > [ネットワーク範囲] ページの [ID とアクセス管理] タブでネットワーク範囲を作成します。

デバイス タイプ

このルールで管理するデバイス タイプを選択します。クライアント タイプには、[Web ブラウザ]、[Identity Manager Client アプリ]、[iOS]、[Android]、および [すべてのデバイス タイプ] があります。

認証方法

ポリシー ルールについて認証方法の優先順位を設定します。 認証方法は、表示されている順序で適用されます。ポリシーの認証方法とネットワーク範囲の構成と一致する最初の ID プロバイダ インスタンスが選択され、ユーザー認証要求は、その ID プロバイダ インスタンスに転送され認証が行われます。認証が失敗すると、リストに表示されている次の認証方法が選択されます。証明書によって認証する場合、この認証方法をリストの最初に表示する必要があります。

2 つの認証方法を使用してユーザーの認証情報を検証し、パスしなければユーザーがサインインできないようにするアクセス ポリシー ルールを構成できます。1 つまたは両方の認証方法が失敗し、フォールバック方法も構成されている場合、ユーザーは構成されている次の認証方法の認証情報を入力するように求められます。次の 2 つのシナリオから、認証チェーンがどのように機能するかを把握できます。

  • 最初のシナリオでは、パスワードと Kerberos の認証情報を使用してユーザーを認証することを求めるアクセス ポリシー ルールが構成されています。認証にパスワードと RADIUS の認証情報を求めるフォールバック認証がセットアップされています。 ユーザーはパスワードを正しく入力しましたが、正しい Kerberos の認証情報を入力していません。ユーザーは正しいパスワードを入力したため、フォールバック認証で、RADIUS の認証情報だけが要求されます。 ユーザーはパスワードを再入力する必要はありません。

  • 2 番目のシナリオでは、パスワードと Kerberos の認証情報を使用してユーザーを認証することを求めるアクセス ポリシー ルールが構成されています。認証に RSA SecurID と RADIUS を求めるフォールバック認証がセットアップされています。ユーザーはパスワードを正しく入力しましたが、正しい Kerberos の認証情報を入力していません。フォールバック認証では、認証に RSA SecurID の認証情報と RADIUS の認証情報の両方が要求されます。

認証セッションの時間の長さ

各ルールについて、認証が有効となる時間の長さを設定します。この値は、ユーザーがポータルにアクセスするか、または特定の Web アプリケーションを起動した前回の認証イベント以来の最長時間を決定します。たとえば、Web アプリケーション ルールに値 4 を指定すると、ユーザーが別の認証イベントを開始して時間が延長される場合を除いて、Web アプリケーションを 4 時間起動できます。

カスタムのアクセス拒否エラー メッセージ

無効な認証情報、誤った構成、またはシステム エラーによってユーザーのログイン試行が失敗すると、アクセス拒否のメッセージが表示されます。デフォルトのメッセージは、以下のとおりです。

有効な認証方法が見つからなかったため、アクセスは拒否されました。

各アクセス ポリシー ルールに、デフォルトのメッセージをオーバーライドするカスタム エラー メッセージを作成できます。このカスタム メッセージには、アクション メッセージを呼び出すテキストおよびリンクを含めることができます。たとえば、管理するモバイル デバイス用のポリシー ルールで、ユーザーが未登録のデバイスからログインしようとする場合に次のカスタム エラー メッセージが表示されることがあります。

社内リソースにアクセスするには、このメッセージの最後にあるリンクをクリックしてデバイスを登録してください。デバイスが既に登録されている場合は、サポートにお問い合わせください。

デフォルト ポリシーの例

次のポリシーは、デフォルトのポリシーを構成してアプリ ポータルへのアクセスを制御する方法の例として参考にできます。ユーザー アクセス ポリシーの管理を参照してください。

ポリシー ルールは、表示されている順序で評価されます。[ポリシー ルール] セクションでルールをドラッグ アンド ドロップして、ポリシーの順序を変更できます。

次の使用事例では、このポリシーの例は、すべてのアプリケーションに適用されています。

    • 社内ネットワーク(内部ネットワーク範囲)の場合、Kerberos とパスワード認証という 2 つの認証方法がフォールバック方法として、ルールに構成されます。社内ネットワークからアプリケーション ポータルにアクセスするため、サービスはまず Kerberos によるユーザー認証を試行します。これは、ルールで最初に記載されている認証方法であるためです。それが失敗すると、ユーザーは Active Directory のパスワードを入力するよう求められます。ユーザーはブラウザを使用してログインし、8 時間のセッション期限までユーザー ポータルにアクセスできます。

    • 外部ネットワーク(全ての範囲)からのアクセスの場合、構成される認証方法は RSA SecurID の 1 つだけです。外部ネットワークからアプリケーション ポータルにアクセスする際、ユーザーは SecurID でログインするよう要求されます。 ユーザーがブラウザを使用してログインすると、4 時間のセッション期限までアプリケーション ポータルにアクセスできます。

  1. ユーザーがリソースへのアクセスを試みると、Web アプリケーション固有のポリシーが適用されている Web アプリケーションを除いて、デフォルトのポータル アクセス ポリシーが適用されます。

    たとえば、このようなリソースの再認証の時間は、デフォルトのアクセス ポリシー ルールの再認証の時間と同一になります。アプリ ポータルにログインしているユーザーの時間がデフォルトのアクセス ポリシー ルールに従って 8 時間である場合、ユーザーがセッション中にリソースを起動しようとすると、アプリケーションはユーザーに再認証を求めずに起動します。