A policy contains one or more access rules. Each rule consists of settings that you can configure to manage user access to their application portals as a whole or to specified Web applications.
For each rule, you determine the user base by specifying a network range. A network range consists of one or more IP ranges. You create network ranges from the Identity & Access Management tab, Setup > Network Ranges page prior to configuring access policy sets.
Select the type of device that the rule manages. The client types are Web Browser, Identity Manager Client App, iOS, Android, and All device types.
Set the priority of the authentication methods for the policy rule. The authentication methods are applied in the order they are listed. The first identity provider instances that meets the authentication method and network range configuration in the policy is selected, and the user authentication request is forwarded to the identity provider instance for authentication. If authentication fails, the next authentication method in the list is selected. If Certificate authentication is used, this method must be the first authentication method in the list.
You can configure access policy rules to require users to pass credentials through two authentication methods before they can sign in. If one or both authentication method fails and fallback methods are also configured, users are prompted to enter their credentials for the next authentication methods that are configured. The following two scenarios describe how authentication chaining can work.
In the first scenario, the access policy rule is configured to require users to authenticate with their password and with their Kerberos credential. Fallback authentication is set up to require the password and the RADIUS credential for authentication. A user enters the password correctly, but fails to enter the correct Kerberos authentication credential. Since the user entered the correct password, the fallback authentication request is only for the RADIUS credential. The user does not need to re-enter the password.
In the second scenario, the access policy rule is configured to require users to authenticate with their password and their Kerberos credential. Fallback authentication is set up to require RSA SecurID and a RADIUS for authentication. A user enters the password correctly but fails to enter the correct Kerberos authentication credential. The fallback authentication request is for both the RSA SecurID credential and the RADIUS credential for authentication.
Authentication Session Length
For each rule, you set the length that this authentication is valid. The value determines the maximum amount of time users have since their last authentication event to access their portal or to launch a specific Web application. For example, a value of 4 in a Web application rule gives users four hours to launch the web application unless they initiate another authentication event that extends the time.
Custom Access Denied Error Message
When users attempt to sign in and fail because of invalid credentials, incorrect configuration, or system error, an access denied message is displayed. The default message is
Access denied as no valid authentication methods were found.
You can create a custom error message for each access policy rule that overrides the default message. The custom message can include text and a link for a call to action message. For example, in a policy rules for mobile devices that you want to manage, if a user tries to sign in from an unenrolled device, the follow custom error message could appear:
Please enroll your device to access corporate resources by clicking the link at the end of this message. If your device is already enrolled, contact support for help.
Example Default Policy
The following policy serves as an example of how you can configure the default policy to control access to the apps portal. See Manage the User Access Policy.
The policy rules are evaluated in the order listed. You can change the order of the policy by dragging and dropping the rule in the Policy Rules section.
In the following use case, this policy example applies to all applications.
For the internal network (Internal Network Range), two authentication methods are configured for the rule, Kerberos and password authentication as the fallback method. To access the apps portal from an internal network, the service attempts to authenticate users with Kerberos authentication first, as it is the first authentication method listed in the rule. If that fails, users are prompted to enter their Active Directory password. Users log in using a browser and now have access to their user portals for an eight-hour session.
For access from the external network (All Ranges), only one authentication method is configured, RSA SecurID. To access the apps portal from an external network, users are required to log in with SecurID. Users log in using a browser and now have access to their apps portals for a four-hour session.
When a user attempts to access a resource, except for Web applications covered by a Web-application-specific policy, the default portal access policy applies.
For example, the re-authentication time for such resources matches the re-authentication time of the default access policy rule. If the time for a user who logs in to the apps portal is eight hours according to the default access policy rule, when the user attempts to launch a resource during the session, the application launches without requiring the user to re-authenticate.