When you add Web and desktop applications to the catalog, you can create application-specific access policies. For example, you can create a policy with rules for a Web application that specifies which IP addresses have access to the application, using which authentication methods, and for how long until reauthentication is required.

The following Web-application-specific policy provides an example of a policy you can create to control access to specified Web applications.

Example 1 Strict Web-Application-Specific Policy

In this example, a new policy is created and applied to a sensitive Web application.

  1. To access the service from outside the enterprise network, the user is required to log in with RSA SecurID. The user signs in using a browser and now has access to the apps portal for a four-hour session as provided by the default access rule.

  2. After four hours, the user tries to start a Web application with the Sensitive Web Applications policy set applied.

  3. The service checks the rules in the policy and applies the policy with the ALL RANGES network range because the user request is coming from a Web browser and from the ALL RANGES network range.

    The user signed in with the RSA SecurID authentication method, but the session just expired. The user is redirected for reauthentication. The reauthentication provides the user with another four-hour session and the ability to start the application. For the next four hours, the user can continue to run the application without having to reauthenticate.

Example 2 Stricter Web-Application-Specific Policy

For a stricter rule to apply to extra sensitive Web applications, you could require reauthentication with SecurId on any device after one hour. The following is an example of how this type of a policy access rule is implemented.

  1. User logs in from inside the enterprise network using the Kerberos authentication method.

    Now, the user can access the apps portal for eight hours, as set up in Example 1.

  2. The user immediately tries to start a Web application with the Example 2 policy rule applied, which requires RSA SecurID authentication.

  3. The user is redirected to RSA SecurID authentication sign-in page.

  4. After the user successfully signs in, the service launches the application and saves the authentication event.

    The user can continue to run this application for up to one hour but is asked to reauthenticate after an hour, as dictated by the policy rule.