About Identity Provider Policies

About identity provider policies.

An identity provider policy allows you to define which identity providers are visible in the Sign In page either when a user is accessing a specific app or trying to access resources that are protected by an identity domain. Identity provider policies can also decide whether users authenticate into an identity domain through identity providers or with a local authentication factor.

The following type of identity providers available in an identity domain:

• SAML identity provider: This type of identity provider supports the SAML 2.0 (Security Assertion Markup Language 2.0) standard. You use a SAML identity provider when you want to establish trust between an SAML-compatible identity provider such as Active Directory Federation Services so that users in your organization can access resources protected by the identity domain.

  If you want your users to be redirected to a specific SAML identity provider automatically so that they can access an app, then ensure that the identity provider policy associated with the app has only the SAML identity provider assigned to it. If multiple identity providers are assigned to the identity provider policy, then users will be prompted to select one of the identity providers from the Sign In page.

• Social identity provider: By linking an identity domain user account to a user's social accounts, the user can access an identity domain using their social credentials, such as Facebook, Google, LinkedIn, Microsoft, and X (formerly Twitter).

• Passwordless authentication provider: Allows users to bypass the standard web-form-based authentication. Passwordless authentication allows access to the protected resource without the need for entering the user name and password every time. However, the first time Sign In uses the standard login form.

• Local identity provider (Local IDP): Authentication into an identity domain happens locally by the user providing their credentials (user name and password) in the Sign In page.

The identity provider policy allows you to configure whether local authentication is displayed in the Sign In page for the user.

For example, suppose you've created several social identity providers and SAML identity providers, and you want to configure which of these identity providers will appear in the Sign In page when the user attempts to authenticate into the identity domain using a particular app. Without identity provider policies, you couldn't configure this. So, if you had all these SAML and social identity providers activated and set to appear in the Sign In page, they would all be displayed.

The identity domain provides you with a default identity provider policy that contains a default identity provider rule. This rule has the User Name-Password local authentication factor assigned to it. This way, at the bare minimum, users can authenticate with their user names and passwords. However, you can build upon this default policy by adding other identity provider rules to it. By adding these rules, you can prevent some of your identity providers from being available to users to authenticate into the identity domain. Or, you can allow other identity providers to be available only to those users who access the identity domain from an IP address contained in one of your network perimeters. Both the My profile console and the Admin console use the identity provider rules that are assigned to the default identity provider policy.

Suppose your company has restrictions as to who can sign in to the identity domain locally (by supplying their user names and passwords) and who must use an external identity provider. Company employees must authenticate by using Active Directory Federation Services (AD FS), contractors and partners must use their own SAML identity providers, and all other users (such as consumers) can use either their user names and passwords or a social identity provider.

To accomplish this goal, you can create two identity provider rules for the default identity provider policy. The first rule is applicable only to company employees. These users must sign in with AD FS which is the employee identity provider. The second rule is applicable only to those users that have user names that end with @partner1.com. They can sign in with the partner 1 SAML identity provider. The third rule is applicable only to those users that have user names that end with @partner2.com. They can sign in with the partner 2 SAML identity provider. The final rule is a catch-all rule for all users (consumers). These users can use either their local passwords or a social identity provider.

Because you can define several identity provider rules for an identity provider policy, the identity domain must know the order in which the rules are to be evaluated. To do this, you can set the priority of the rules. For the previous example, you can have the company employee rule evaluated first. If a user meets the criteria of this rule (that's, the user is an employee), then the user must authenticate with AD FS. Users who aren't employees don't meet the criteria of this identity provider rule, and so, the rule with the next highest priority is evaluated. For this example, this is the partner 1 rule where the user's username must end with @partner1.com. These users must authenticate using the partner 1 SAML identity provider. For users who aren't employees or who don't have usernames that end with @partner1.com, the identity domain evaluates the rule with the next highest priority number: the partner 2 rule where the user's username must end with @partner2.com. These users must use the partner 2 SAML identity provider to authenticate. All other users meet the criteria of the catch-all rule so they can use either their local passwords or a social identity provider to sign in.

In addition to the default identity provider policy, you can create identity provider policies and associate them with specific apps. Suppose you have several apps and you want to assign different identity providers to each app. For example, you might have two apps, and you want users to authenticate from Facebook or LinkedIn. So, you can have one identity provider policy for one app and the Facebook social identity provider, and another identity provider policy only for the second app and the LinkedIn social identity provider.

An identity domain displays a maximum of four identity providers on the Sign In page. If you assign more than four identity providers to an identity provider policy, then a View all link appears on the page. Select the link and all identity providers associated with the policy appear.