Identity Provider Routing Rules
Identity Provider (IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta.) routing rules enable you to direct end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. to identity providers based on the user's location, device, email domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https)., attributes, or the appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. they are attempting to access. (This feature is also known as IdP Discovery, because these routing rules allow Okta to discover which identity provider to use based on this context.) You can create a rule for each of your providers or for different combinations of user criteria. When an end user attempts to sign in, the active rules are evaluated, and the first one that the user matches is applied.
IdP routing rules are useful in the following scenarios:
- On-network vs. off-network — You can maintain alternate or legacy authentication for off-network users and use Okta for on-network users.
- Mobile users — Mobile users, identified by device, can route authentication to a third-party identity provider with specific functionality.
- Hub-and-spoke organizations — These organizations may manage users, Active Directories, policies, apps, and workflows in one of the "spoke" organizations, but require access to the central organization for certain apps, such as Workday, for other reasons. Users can authenticate from an app using an SPAn acronym for service provider. Generally, an SP is a company, usually providing organizations with communications, storage, processing, and a host of other services. Within Okta, it is any website that accepts SAML responses as a way of signing in users, and has the ability to redirect a user to an IdP (e.g., Okta) to begin the authentication process.-initiated flow to the "hub" organization which uses routing rules to authenticate into the "spoke" organization seamlessly. (If you have more than one Okta orgThe Okta container that represents a real-world organization., you can use separate identity providers for each org to keep groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. of users separate.)
- Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. — You can route desktop users to Integrated Windows AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. (IWA) and mobile users to Okta for authentication.
- Multiple customer organizations — You can send users across multiple orgs to a different org for authentication, based on the email subdomain.
- Required discovery by user attribute — In some B2B scenarios where the email domain does not necessarily correlate to the identity provider, you can direct authentication based on user attributes.
When IdP routing rules are configured to select a provider based on the end user's domain or attributes, the end-user sees a modified sign-in screen that accepts the email and short names.
The sign-in is evaluated against the set criteria and the user is redirected to the appropriate sign-in screen for the desired identity provider.
Note: Routing rules improve the end-user sign-in experience, but they do not provide security enhancements. You need to configure user authentication policies for your IdPs independently of your routing rules.
Before using this feature, you must configure:
- OktaIWA Web agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations.. See Configure Desktop SSO.
Limitation: IdP Discovery on ChromeBooks only supports the Okta Identity Provider and third-party Identity Providers that have announced support for ChromeBook.
To configure Identity Provider routing rules, navigate to Security > Identity Providers, and then click the Routing Rules tab. The default rule specifies Okta as the default identity provider. To add an additional provider, click Add Routing Rule.
- Enter a Rule Name.
- Indicate your routing specifications.
- User's IP is: To specify a zone, at least one network zone must already be defined. For information on zones, see IP Zones.
- User's device platform is: Select any combination mobile and desktop devices. Note: iOS devices may bypass your iOS routing rules. See Routing rules for macOS devices below for recommended configuration and end user settings.
- User is accessing: To add an application or app instance, start typing the application name. A list of all matching apps appears.
- From the User matches menu, 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 is not 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.
In Use 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.
Maintaining Routing Rules
Active rules are evaluated in the order that they are shown on the Routing Rules page. The first active rule that the user matches is applied.
Note: There is no limit to the number of rules you can add. However, routing performance is affected by the number of rules that must be evaluated before a match is found.
- To change the priority of rules, hover over the area to the left of a rule number. Drag it into the order you want.
- To activate, deactivate, edit, or delete a rule, click the rule name, and then click an action button on the right. You cannot modify the default rule.
Routing rules for macOS devices
Due to a change in the way that Safari reports device user agents, Okta cannot 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:
- 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.
Okta Mobile is not supported for use with Identity Provider Routing Rules.Top