Claim mapping and retrieving end-user information in WSO2IS.

Looking for a step by step guidance on basics of configuring claim mapping in WSO2 Identity Server? And a way to obtain mapped claims information relevant to an end-user using OpenID Connect? Then you will find this blog post worth your attention :)

Prerequisites:

• Download WSO2 Identity Server from here. Refer to the installation guide for more information.
• Set up the sample webapp, WSO2 playground from here for testing purposes.

Now you are ready to go.

First of all I will simply tell you what are claims. Claims is a set of information associated with a subject. Name, gender, email are a few examples for claims. These claims supports in identifying the end-user. Let’s see how to map claims from the WSO2IS management console.

Sign in to https://localhost:9443/carbon/admin/login.jsp using admin:admin credentials.

In the Main menu, click List under Claims to view available claim dialects. http://wso2.org/claims is the default (local) claim dialect for WSO2 Carbon.

In this example I will be mapping the claim Role available at http://wso2.org/claims as shown below

to http://wso2.org/oidc/claim (default dialect for OpenID Connect). I have taken the claim Role as it is not available as a claim in OpenID Connect dialect.

To make Role claim available as a claim for OpenID Connect dialect follow the the steps mentioned below.

• Click Add under Claims in the main menu.
• Select Add External Claim option available and add a claim with the following data.

Now you can see the claim group which is mapped to http://wso2.org/claims/role available in OpenID Connect dialect.

In this blog post we will do configurations to obtain gender, email and role of an end-user as his/her available claims by using authentication event information over the IDToken and getting extra claims of the authenticated user from the OpenID Connect UserInfo endpoint in WSO2IS. We have already added the Role claim as group for OpenID Connect. If you go through the available claims for OpenID connect you will see gender and email claims are already present. Therefore claim mapping is not necessary for these two claims. Make sure the below highlighted option in the image is set to true for all three claims so that these claims will be prompted during user registration.

Next let’s add a new user as user1.

• Click Add under Users and Role option in the menu.
• Add a new user as user1.

• Add a new role as finance. Assign user1 to the finance role.

Click on the User Profile for user1 available in the users list.

Add the relevant details for the user.

Next let us configure claims for an OpenID Connect Service Provider.

• Click Add under Service Providers option in the menu and add a new service provider with the name as playground.
• Under Inbound Authentication Configuration select OAuth/OpenID Connect Configuration and do the following configurations.

Callback URL : http://wso2is.local:8080/playground2/oauth2client

Add the claim configurations for service provider.

When configuring claims for an OpenID Connect Service Provider it is mandatory to add the custom claims to a scope value in the oidc file.

• Click on Browse under Registry on the Main menu.
• Navigate to /_system/config/ and click on the oidc file.

• Expand the Properties section .You can update an existing property or add a new property. I will be adding a new property as test with values gender, group and email.

Now let’s test the configurations using the playground webapp. Deploy playground in apache tomcat server and access it using http://wso2is.local:8080/playground2/oauth2client. Add the details as shown below.

• For grant type let’s have it as authorization code.
• Give the generated client id for service provider.
• For the scope let’s give the scope we have newly created test. Note that it should be given as “openid test” as it is a oidc defined scope.
• Callback URL: http://wso2is.local:8080/playground2/oauth2client
• Authorize Endpoint: https://localhost:9443/oauth2/authorize

Log in as user1.

Give the approval requested.

Enter the following details in the form that appears and click Get Access Token.

• Callback URL: http://wso2is.local:8080/playground2/oauth2client
• Access Token Endpoint: https://localhost:9443/oauth2/token
• Give the generated client secret for service provider.

At this step both ID Token and Access Token are received. Enter the UserInfo Endpoint as https://localhost:9443/oauth2/userinfo?schema=openid .

And now you can obtain the claims for user1 as shown below :)

Another approach:

After receiving the authorization code without following the other steps I have mentioned afterwards we can send a cURL request as given below:

curl -k -v --user client_id:client_secret -d "grant_type=authorization_code&code=authorization_code&redirect_uri=http://wso2is.local:8080/playground2/oauth2client" https://localhost:9443/oauth2/token

Replace client_id, client_secret and authorization_code with the relevant values accurately.

Example with sample values:

curl -k -v --user nceF9a1JAROj6591XL9KAcoZWxYa:4EilRu2r1ROjrWrTaO9EK4rgfBYa -d "grant_type=authorization_code&code=31b54219-4a28-3e73-b971-8a335bddcf5e&redirect_uri=http://wso2is.local:8080/playground2/oauth2client" https://localhost:9443/oauth2/token

Response body:

{"access_token":"ef9d4dd1-6ff7-306d-ab44-6a354c27e70c","refresh_token":"602fe745-1f6f-36a4-8d5c-5bfd6fa85c9e","scope":"openid test","id_token":"eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiSXlQZnJBd2hLaHhmOE85d0RlVnhPUSIsInN1YiI6InVzZXIxIiwiYXVkIjpbIm5jZUY5YTFKQVJPajY1OTFYTDlLQWNvWld4WWEiXSwiZ2VuZGVyIjoibWFsZSIsImF6cCI6Im5jZUY5YTFKQVJPajY1OTFYTDlLQWNvWld4WWEiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMlwvdG9rZW4iLCJleHAiOjE1MTY1NjM4MTIsImlhdCI6MTUxNjU2MDIxMiwiZW1haWwiOiJ1c2VyMUBnbWFpbC5jb20iLCJncm91cCI6WyJJbnRlcm5hbFwvZXZlcnlvbmUiLCJmaW5hbmNlIl19.Pgv1W1z9vZ3ZGpBXnhkoz_C7uuCDQ_EF1T0qZ3hTKAzOgLbQJ2iML4ZR8JGPmj6EfUUQ5I5TuEh8aaCczyXCAP6dZTlKuR4thFOVJICGdBLnnsydRwsgDesC3ky7BaV7PtaRsHlFkV9Xo40jG797jIUUW0WG18wzTE9moLYsGYY1h1ifFKDk_GJNJkfa1WVoX1oumbN1AGqJ28uplcB_U7dmP-IBawi-qNFveeejQLC-oTJkHLB8Jf4wtVQUiRFyDD7KvnXDV9Suwaq9ClD7plOP68niYfBqHIHljcKSSPX2rQ
AHONF_e2eoYxjrAwDpt-4xdObDB8492U9MDvUh4Q","token_type":"Bearer","expires_in":113}

Extracted ID token:

eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiSXlQZnJBd2hLaHhmOE85d0RlVnhPUSIsInN1YiI6InVzZXIxIiwiYXVkIjpbIm5jZUY5YTFKQVJPajY1OTFYTDlLQWNvWld4WWEiXSwiZ2VuZGVyIjoibWFsZSIsImF6cCI6Im5jZUY5YTFKQVJPajY1OTFYTDlLQWNvWld4WWEiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMlwvdG9rZW4iLCJleHAiOjE1MTY1NjM4MTIsImlhdCI6MTUxNjU2MDIxMiwiZW1haWwiOiJ1c2VyMUBnbWFpbC5jb20iLCJncm91cCI6WyJJbnRlcm5hbFwvZXZlcnlvbmUiLCJmaW5hbmNlIl19.Pgv1W1z9vZ3ZGpBXnhkoz_C7uuCDQ_EF1T0qZ3hTKAzOgLbQJ2iML4ZR8JGPmj6EfUUQ5I5TuEh8aaCczyXCAP6dZTlKuR4thFOVJICGdBLnnsydRwsgDesC3ky7BaV7PtaRsHlFkV9Xo40jG797jIUUW0WG18wzTE9moLYsGYY1h1ifFKDk_GJNJkfa1WVoX1oumbN1AGqJ28uplcB_U7dmP-IBawi-qNFveeejQLC-oTJkHLB8Jf4wtVQUiRFyDD7KvnXDV9Suwaq9ClD7plOP68niYfBqHIHljcKSSPX2rQ
AHONF_e2eoYxjrAwDpt-4xdObDB8492U9MDvUh4Q

The format of the ID token is as <header>.<body>.<signature>.

Decode from Base64 format the <body> of the ID token to obtain the claims.

Now you have successfully obtained the claims for an end-user from the ID token :)

I hope you enjoyed this article.

Thanks!