You can create custom access policies for individual web and desktop applications that are in the catalog. These access policies can restrict access based on location, device type, authentication method, and session length. To limit access, you can associate a specific group to an application rule.
The following are examples of web-application-specific policies that you can create to control access to specified Web applications.
Example 1 Basic Web-Application-Specific Policy Assigned to a Group
In this example, a new application-specific access policy is created and applied to web applications that the Sales Team group can access. Two rules are applied. The first rule is specific to users in the Sales Team group who access the app from the internal network.
The rule to access from the internal network is configured as follows.
- Network range is INTERNAL NETWORK.
- Users can access the content from the Web Browser.
- Users belong to the group Sales Team.
- First authentication method is Kerberos.
- Fallback is Password.
- Session reauthentication after 8 hours.
To access the sales team applications from the internal network, a member of the Sales Team group, launches an app from a web browser and is asked to enter a name and Kerberos password. If Kerberos authentication fails, the user is asked to enter the Active Directory password. The session is available for eight hours. After eight hours, the user is prompted to sign in again.
The second rule is applied if users in the Sales Team group access the app from an eternal site through a web browser.
The rule to access from an external site is configured as follows.
- Network range is ALL RANGES.
- Users can access the content from the Web Browser.
- Users belong to the group Sales Team.
- Authentication methods implemented include the ability to sign in with mobile devices and from a computer.
- Authenticate using Mobile SSO (for iOS).
- Fallback to Mobile SSO (for Android).
- Fallback to RSA SecurID.
- Session reauthentication after 4 hours.
To access these applications from outside the enterprise network, depending on the type of device, the user is required to sign in with the mobile device passcode or with the RSA SecurID passcode. The session starts and is available for four hours. After four hours, the user is prompted to sign in again.
Example 2 Strict Web-Application-Specific Policy Assigned to a Group
In this example, an application-specific access policy is created and applied to an extra sensitive web application. Members of the sales team group can access this application from any type of device but only for 1 hour before authentication is required again.
- Network range is ALL RANGES.
- Users can access the content from All Device Types.
- Users belong to the group Sales Team.
- Authentication method is RSA SecurID.
- Session reauthentication after 1 hour.
The Sales Team user signs in and is authenticated based on the default access policy rules and can access the apps portal and resources. The user clicks the app that is managed by the strict access policy rule as specified in Example 2. The user is redirected to the RSA SecurID authentication sign-in screen.
After the user successfully signs in, the service launches the app and saves the authentication event. The user can continue to launch the app without signing in for up to one hour. After the hour, the user is prompted to reauthenticate through RSA SecurID.
