Identity Provider Discovery
Note: This feature is available for all Preview organizations. It is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature for Production organizations at this time.
When configured, Identity Provider Discovery redirects users to different identity providers based on specified criteria. These criteria include location, device, 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. or app instance being accessed, the user's 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)., and specific user attributes. For organizations that have more than one Okta orgThe Okta container that represents a real-world organization., the separate orgs can use separate identity providers and 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.
Note: Identity Provider Discovery is designed to improve usability and to enhance the end-user experience. It does not provide additional security enhancements.
Limitation: Identity Provider Discovery on ChromeBooks only supports the Okta Identity Provider and third-party Identity Providers that have announced support for ChromeBook.
When Identity Provider Discovery is 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, as shown below.
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.
Identity Provider Discovery is 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 — organizations that manage users, Active Directories, policies, apps, workflow management etc. in one of the "spoke" organizations, but require access to the central organization for certain apps, such as Workday, or other reasons. Using Identity Provider Discovery, 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 Identity Provider Discovery to authenticate into the "spoke" organization seamlessly.
- 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 Authentication (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
Before using this feature, you must have an additional identity provider configured. For information on configuring an additional SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. identity provider, see Configure Inbound SAML. Identity Provider Discovery does not support Social Identity Providers.
To configure Identity Provider Routing Rules (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. Discovery), navigate to Security > Identity Providers, and then, click the Routing Rules tab. The default rule is shown that specifies Okta as the default identity provider. To add an additional provider, click Add Routing Rule. The screen shown below opens.
You must name the rule. In addition to the name there are four types of routing specifications. Note that all specified conditions must be met to trigger the rule. After defining the conditions, you specify the identity provider to use.
- User's IP Address — choices are Anywhere, In zone, and Not in zone. To specify a zone here, at least one network zone must already be defined. For information on zones, see IP Zones.
- User's Device Platform — choices are Any device, any of these mobile devices: iOS, Android, Other mobile (e.g. BlackBerry), and any these desktop devices: Windows, macOS, Other desktop (e.g. Linux). You can select any desired combination of devices.
- User is accessing — choices are Any application or to specify applications. To add an application or app instance, start typing the application name. A list of all matching apps appears from which you caRegex on loginn choose. You can specify multiple applications.
- User matches — based on the user attribute login
User attribute specifies an attribute name, a type of comparison, and a value to match. After selecting User attribute, the item shown below appears.
Choose an attribute from the list and choose the type of comparison to use from the second list. The expanded drop down lists are similar to the following example, varying by the user attributes in your org.
After choosing from the drop down lists, enter the value to use for comparison. If you choose Regex for the type of comparison, enter a valid regular expression for the value.
- Use this identity provider — choose the identity provider from the drop down list to use when all the criteria are met.
When done, click Create Rule. After creating a rule, the following prompt appears to allow you to activate the rule.
- If you activate the rule, it is immediately in effect.
- If you do not activate the rule, it is listed on the Routing Rules screen as inactive.
Maintaining Routing Rules
The Routing Rules screen shows all rules, active and inactive.
To activate, edit, deactivate, or delete a rule, click the rule name, and then click an action button on the right. You cannot modify the default rule.