Configuring Claims for an Identity Provider

Configuring claims for an identity provider involves mapping the claims available in the identity provider to claims that are local to the WSO2 Identity Server. This is done so that the Identity Server can identify the user attributes in the response sent from the identity provider. See the Identity Server Architecture topic for more information on how claim mapping fits into the identity provider scenario.

In the Claim Configuration form, there are two sub forms.

Basic claim configuration - This involves a straightforward mapping of the claim that is used on the identity provider side with the claims local to the Identity Server.
Advanced claim configuration - This involves more advanced mapping, where the mapped claims can have specific default values.

To view the claim configuration section, expand the Claim Configuration form.

Configuring basic claims

Select the claim mapping dialect by either choosing to use a local claim dialect (i.e., a claim dialect local to the Identity Server) or define your own custom claim dialect (i.e., a claim dialect which exists in the identity provider that must be mapped to the Identity Server).

If you choose to Use Local Claim Dialect, select the claim you require from the User ID Claim URI dropdown which includes a list of all the claims defined in the Identity Server.
You can alternatively choose the Define Custom Claim Dialect option.
For custom claim dialects, you must map the attributes of the user in the identity provider to the claims that are local to the Identity Server. These claims can be part of the response that it sent from the identity provider to the Identity Server. This can also be used when provisioning users from the Identity Server to an external identity provider. These claim values are sent as part of the outbound provisioning request. Do the following to configure this.
1. Click the Add Claim Mapping button under Identity Provider Claim URIs. Clicking this button again enables you to perform more claim mapping.
2. Map the value of the corresponding claim in the identity provider to the claim in the Identity Server. Click the Delete button to remove the claim mapping.
3. Select the User ID Claim URI from the dropdown that includes the list of identity provider claims you defined. This is used to uniquely identify the user in the response sent by the identity provider. This is also used to identify the user in provisioning requests.
4. Select the Role ID Claim URI from the dropdown which includes the list of identity provider claims you defined. This is used to uniquely identify the role of the user in the response sent by the identity provider. This is also used to identify the role in provisioning requests.

Configuring advanced claims

You can make advanced claim configurations based on the basic configurations you have made.

Click here for more information on when advanced claims are useful

Provisioning scenarios where advanced claims are useful

The following scenario expands on two different scenarios where provisioning happens. For both these scenarios, advanced claims are very useful.

In the above scenario, Google Apps is configured as an identity provider in the Identity Server. When a user is added to the management console of the Identity Server, the user is provisioned to Google Apps using the Google Apps identity provider configuration in the Identity Server.

The next scenario is for Just-In-Time (JIT) provisioning. Salesforce is the service provider and Facebook is the identity provider configured in the Identity Server. When JIT provisioning is configured in the service provider configuration, the user is provisioned to the user store configured in the Identity Server. If the same user store is configured in the Google Apps identity provider configuration and JIT provisioning is enabled, the user is provisioned there as well. JIT provisioning happens while in the middle of an authentication flow. The provisioning can happen in a blocking mode or in a non-blocking mode. In the blocking mode, the authentication flow will be blocked until the provisioning finishes - while in the non-blocking mode, provisioning happens in a different thread. This can be specified in the service provider configuration.

In both these scenarios, only some specific user attributes must be configured for provisioning as the claims are different for both Facebook and Google Apps and must be mapped to the claims in the Identity Server.

Use the following instructions to configure advanced claims.

If you chose to Use Local Claim Dialect in the Basic Claim Configuration, do the following.
1. When you send provisioning requests from the Identity Server to the external identity provider, it may not be necessary to send all the requests. So, you can use the Provisioning Claim Filter to filter out the user attributes you need to send from the other available attributes. To use the Provisioning Claim Filter, select the claims that exist in the Identity Server from the dropdown list and click Add Claim. Clicking this button again enables you to add a new entry.
2. Enter a Default Value for your claim. This value is the default value used when provisioning this claim. This value will be used in all instances of this field, e.g., if all users are from one organization, you can specify the name of the organization as a default value using this field. Clicking the Delete button will remove this advanced claim.
If you chose to Define Custom Claim Dialect in the Basic Claim Configuration, do the following.
1. Select the Identity Provider Claim URI you defined from the dropdown list and click Add Claim. Clicking this button again will add a new entry.
2. Enter a Default Value for your claim. This value is the default value used when provisioning this claim. This value will be used in all instances of this field, e.g., if all users are from one organization, you can specify the name of the organization as a default value using this field. Clicking the Delete button will remove this advanced claim.