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

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

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

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

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

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

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

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

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

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

  1. Kerberos 認証で企業ネットワークの内部からユーザーがログインします。

    このとき、例 1 でセットアップしたように、ユーザーは 8 時間アプリケーション ポータルにアクセスできます。

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

  3. ユーザーは RSA SecurID 認証ログインページにリダイレクトされます。

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

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