This documentation is for WSO2 Identity Server 5.3.0 . View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Claim mapping for a service provider involves mapping claims that are used by the service provider to the claims local to the WSO2 Identity Server. See the Identity Server Architecture for more information on how claim mapping fits in to the overall scheme of things.

  1. In the  Claim Configuration form, select the claim mapping dialect by either choosing to use a local claim dialect or define your own custom claim dialect. 
    • If you choose to Use Local Claim Dialect, you need to fill in the following details.
      1. Fill in your requested claims by clicking the Add Claim URI button.
      2. Choose your Local Claim from the dropdown.
    • If you choose to Define Custom Claim Dialect, you need to do the following. 
      1. Add a custom claim URI by clicking on the Add Claim URI button. Clicking this button again enables you to map more claims.

      2. Add the Service Provider Claim and choose the corresponding Local Claim from the dropdown and select whether you want the claim to be a Requested Claim by using the checkbox.

         Click to view vital information when configuring claims for an OpenID Connect Service Provider

        Note: When mapping custom claims for a service provider configured with OpenID Connect, ensure to map the custom claims in the SP configuration as seen in the screenshot above AND also add the custom claims to a scope value in the oidc file.

        Why?

        This is required because OpenIDConnect claim scopes are supported from WSO2 IS 5.2.0 onwards. This means that when you request for an OIDC token, you can specify a single scope value that is bound to a set of multiple claims. When that OIDC token is sent to the UserInfo endpoint, only the claims which are common in both the OIDC scope config file and the SP claim configuration (i.e., the intersection of claims in both these configurations) will be returned.

        To do this,

        1. Click on Browse under Registry on the Main tab of the management console.
        2. Navigate to /_system/config/ and click on the oidc file. Expand the Properties section.
        3. Add the custom claims to the existing default scope openid by clicking on Edit. Alternatively, add a new scope for the custom claims by clicking on Add New Property and send it when getting the OIDC token along with the mandatory openid scope.

        Information on mapping claims

        The Local Claim list includes a set of standard claim values which are local to the WSO2 Identity Server. When adding a service provider, it is necessary to map the values of the claims local to the service provider with those provided in this dropdown list which are local to the Identity Server. This should be done for all values in the service provider unless they use the same claim name.

        Marking a mapped claim as a Requested Claim would ensure that the service provider definitely sends this claim to the Identity Server. This is useful particularly in cases where there are hundreds of claims and only specific ones need to be sent to the Identity Server.

  2. Select the Subject Claim URI and the Role Claim URI (for custom claims) from the dropdown. The claims you mapped are listed in the dropdown and you can choose among these claims.

    • When the authentication request comes into the Identity Server, the value of the claim specified as the Subject Claim URI is added to the authentication request. To expand more, when the user logs into the Identity Server, it identifies the user store that the user belongs to. The value of the claim specified as the Subject Claim URI can be found in this user store. This value corresponding to the claim is sent along with the authentication request.
    • The Role Claim URI is used to identify the claim that equates to the role of the user. This is linked to the permissions that you can apply for specific user roles.
Related Topics
  • No labels