A policy contains one or more access rules. Each rule consists of settings that you can configure to manage user access to their apps portal 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.

Each identity provider instance in your deployment links network ranges with authentication methods. When you configure a policy rule, ensure that the network range is covered by an existing identity provider instance.

You can configure specific network ranges to restrict from where users can log in and access their apps.

Select the type of device that the rule manages. The client types are Web Browser, Identity Manager Client App, iOS, Android, Windows 10, Mac OS X, and All device types.

You can configure rules to designate which type of device can access content and all authentication requests coming from that type of device use the policy rule.

In the policy rule, you set the order the authentication methods are applied. 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 this 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.

For each rule, you set the number of hours that this authentication is valid. The re-authenticate after 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.

When users attempt to sign in and fail because of invalid credentials, misconfiguration 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 custom error message could read

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.

The following policy serves as an example of how you can configure the default policy to control access to the apps portal and to web applications that do not have a specific policy assigned to them.

The policy rules are evaluated in the order listed in the policy. You can change the order of the rules by dragging and dropping the rule in the Policy Rules section.

1

For the internal network 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.

2

This default policy applies to all Web applications that do not have a Web-application-specific policy.