Configure identity provider routing rules
Configure routing rules for each of your identity providers (IdP) or for different combinations of user criteria. Users who don't meet the conditions of your routing rules are evaluated by the default rule, which specifies Okta as the identity provider.
To create routing rules that aren't bound to a specific IdP, see Configure dynamic routing rules.
Before you add routing rules, you need to configure the Okta IWA Web agent and at least one additional identity provider (social identity providers are accepted). See Add a SAML 2.0 IdP and Generic OpenID Connect.
If you want to prompt the end user for their Okta username and password on the same page as your list of available identity providers, be sure that the Okta sign-on policy is configured for Password / IDP. This combination is recommended for your rules that offer Okta as an identity provider or if you intend to prioritize the default routing rule.
Note that IdP Discovery on ChromeBook only supports the Okta identity provider and third-party identity providers that have announced support for ChromeBook. Okta Mobile isn't supported for use with Identity Provider Discovery.
If you want to route users based on an IP address, define at least one network zone. See Network zones.
- In the Admin Console, go to Security > Identity Providers.
- On the Routing Rules tab, click Add Routing Rule.
- Enter a Rule Name.
- Configure the routing conditions.
IFUser's IP is
To specify a zone, at least one network zone must already be defined. For information on zones, see Network zones.
ANDUser's device platform is
Select any combination of mobile and desktop devices.
iOS devices may bypass your iOS routing rules. See Configure a routing rule for macOS devices.
ANDUser is accessing
To add an application or app instance, start typing the application name. A list of all matching apps appears.
Select which login attributes the user must match.
- Anything includes all users.
- Regex on login allows you to enter any valid regular expression based on the user login to use for matching. This is useful when specifying the domain or a user attribute is not sufficient for matching. For example, .*\+email@example.com matches logins for the domain @company.com but only if +devtest is included before the @ sign.
- Domain list on login specifies a list of the domains to match (without the @ sign); for example, mytest.com. It isn't necessary to escape any characters (which is required when using a regular expression).
- User attributes specify an attribute name, a type of comparison, and a value to match. Note that if you choose Regex for the type of comparison, you must enter a valid regular expression for the value. For example, (Human Resources|Engineering|Marketing) for the Department attribute in your Okta user schema.
THENUse this identity provider
Select the identity provider to use when all the criteria are met.
- Click Create Rule, and then indicate whether you want to activate the rule immediately.
Due to a change in the way that Safari reports device user agents, Okta can't differentiate between app requests that come from macOS devices and those that come from Safari on iPadOS devices.
To prevent iPadOS devices from bypassing iOS policies, configure a Deny/Catch-All routing rule that applies to macOS and iPadOS devices. To prevent iPadOS device users from being affected by your macOS app routing rules, inform them that they must do one of the following options.
- Option 1: All websites accessed from Safari (iPadOS 13 and higher). In iPad settings, go to Safari settings > Request Desktop Website and then turn off the All Websites setting.
- Option 2: Per-website basis. Open Safari, tap Aa on the left side of the search field, and then tap Request Mobile Website.
- Option 3: Access the target app through their Native App or Okta Mobile.