Web アプリケーションをカタログに追加する際に、 Web アプリケーション固有のアクセス ポリシーを作成できます。たとえば、特定の Web アプリケーションについて、そのアプリケーションにアクセスできる IP アドレス、使用する認証方法、および再認証が必要になるまでの期間を指定するルール付きのポリシーを作成できます。

次の Web アプリケーション固有のポリシーは、指定した Web アプリケーションへのアクセスを制御するために作成できるポリシーの例です。

例 1:厳格な Web アプリケーション固有のポリシー

この例では、新しいポリシーが作成され、機密性の高い Web アプリケーションに適用されます。

  1. 企業ネットワークの外部からサービスにアクセスするには、ユーザーは RSA SecurID を使用してログインする必要があります。ユーザーはブラウザを使用してログインし、デフォルトのアクセス ルールに指定されているように、4 時間のセッションまでアプリ ポータルにアクセスできます。

  2. 4 時間後に、ユーザーは機密性の高い Web アプリケーション ポリシー セットが適用された Web アプリケーションを起動しようとします。

  3. サービスは、ポリシーのルールをチェックし、ユーザー リクエストが Web ブラウザと全範囲ネットワーク範囲から来ているため、全範囲ネットワーク範囲のポリシーを適用します。

    このユーザーは、RSA SecurID の認証方法でログインしていますが、セッションがちょうど失効しました。このユーザーは再認証にリダイレクトされます。再認証により、ユーザーには再度 4 時間のセッションが与えられ、アプリケーションの起動が許可されます。これに続く 4 時間、ユーザーは再認証する必要なしにアプリケーションを起動し続けることができます。

例 2:さらに厳格な Web アプリケーション固有のポリシー

極めて機密性の高い Web アプリケーションに適用するさらに厳格なルールの場合は、デバイスを問わず、1 時間後に SecureId を使用した再認証を必要とします。次の例は、このタイプのポリシー アクセス ルールの実装方法を示しています。

  1. パスワードによる認証方法で企業ネットワークの内部からユーザーがログインします。

    今、例 1 でセットアップしたように、ユーザーは 8 時間アプリ ポータルにアクセスできます。

  2. ユーザーは、例 2 のポリシー ルールが適用された Web アプリケーションを直ちに起動しようとします。このためには RSA SecurID 認証が必要です。

  3. このユーザーは、RSA SecurID を提供する ID プロバイダにリダイレクトされます。

  4. ユーザーがログインに成功すると、サービスによりアプリケーションが起動され、認証イベントが保存されます。

    ユーザーはこのアプリケーションを最大 1 時間起動し続けることができますが、1 時間後、ポリシー ルールの指示通りに再認証を求められます。