Configurations of WSO2 Identity Server-7.0.0 to Serve as the Key Manager or External IDP for your API Manager

In this article, I will b using the WSO2 Identity Server (is) 7.0.0 to configure WSO2 IS which will be used as the Key Manager for the WSO2 API Manager in my next article.

This provides detailed explanation on the relationship of the Users, Groups, API scopes and Applications in the WSO2 IS and how it can be used to use in scopes for authorisations in API.

This article will guide you through configuring the IS-7.0 since theres fantastic UI upgrade from IS-6.x.x versions which is highly user friendly as well.

There are following main sections that will be explained.

1. Component relationships
2. Configuring roles, scopes and application in the WSO2 IS
3. Send additional scopes than default set of scopes
4. Generating a token with scopes

Component relationships

Before moving on to configuring the Identity Server as the Key Manager for the API manager, please find the below explanation on how each and every component in IS integrates with each other when providing relavant scopes for application based grant types and user based grant types.

The above diagram shows the relationships of the components thats used by the applications and users. Ideally management or to organise the users and roles are done by the “Groups”, and for resources and scopes are done using the “API Authorizations”

Whenever an client credentials are used to generate tokens and if the particular application is authorised for those scopes, the associated scopes will be returned with the token.

Whenever an user generates token using user credentials, according to the roles available for the users and with regards to the scopes that are mapped to the specific roles will be shared with the token scopes.

As per the article, create an Application, several Users and some Groups in the identity server.

For this scenario I have created

mark_rec where I will associate with receptionist scope and user group and niomi_nurse where I will associate with nurse scope and user group

Configuring Roles and Scopes and Associate with an Application

As mentioned in the above section of the IS component relationships, the roles are associated with the scopes for a given API. So if we need to use scope based authorization for the APIs we need to

1. Configure some API resources and add scopes to it
2. Associate roles with the users and map the available scopes to the roles
3. Create users and Associate the created Roles with the Users
4. Create an application to Associate roles and API resources for the Application
5. Add the callback URLs and allowed origins in the application

Its possible to create roles from the applications itself and associate the scopes from application point of view as well as create roles separate to the application and go through the same process to add scopes and then later add the roles to the application

1. Create API resources and associate scopes

You could follow the below screens on how to create the API resource and associate with several scopes (add_pets and update_pets).

2. Create roles and associate scopes

Create two roles as receptionist and nurse and associate with add_pets and update_pets scopes

3. Associate the created Roles with the Users

Navigate to the roles section and select the created nurse role and add user Niomi and for receptionist role, add Mark.

4. Create an application to Associate roles and API resources for the Application

First it is needed to be selecting the necessary attributes to be sent as claims. Once you select those, the OpenID scopes will get automatically generated as well so that, it is possible to copy the values to be used in the application.

Also if the subject attribute can be changed as well and once done with the user attributes, click on update the application.

Once the attributes are finalised, goto API Authorization section and add the relavant APIs and the scopes that will be used within the application. And if the user is requesting some extra scopes, the Identity server will make sure to only return the necessary scopes that are associated with the application.

Next, Goto the Roles section and select the recently added nurse and receptionist roles and update the application again.

5. Add the callback URLs and allowed origins in the application

Also the callback URL is needed to be added since we are using the Code grant and also allow the localhost as the allowed origin. Furthermore add the https://localhost:9444/oauth2/token as the Audience

Note: Both Roles and Scopes needed to be added to the application eventhough the role itself associated with API resource and scopes

Send additional claims in OpenID scope than default set of claims

In the application, there will be different set of claims available for different scopes. The following is the list of claims that are available with the OpenID scope.

But there are scenarios, we need to add additional claims to be sent. Hence we need to add those claims to the OpenID scope. Inorder to do that, navigate to OpenID Connect in “Manage Attribute Mappings”

And lets say you need to add some claims to the profile, Click on it

Select on new attribute

Select some attribute that doesn't available but also has a value in the user profile as well. Eg: User ID

Once it is saved, it will be available in the User Attribute selection so that you can select it and send it with the scope that it is requested.

Generating Access Token

Test the application with Authentication Code Grant and check all necessary information is available in the token

By navigating to the application section, and going to the info section, its possible to find all the necessary information.

And in the postman, you could add a request and do the configurations and click on “Get New Access Token” . Note the scopes (openid groups profile roles add_pet) which are requesting as well.

This will direct you to the IS authentication endpoint which you need to provide username and password.

After successful login which will be able to see as the below screen

The token can be copied from the following screen.

Navigate to https://jwt.io/ and once you check the token content, you could see the information which includes the group that the user is in.

With this article, I suppose it was clearly explained on how to configure the WSO2 Identity Server to be served as a Key Manager for your API Manager solution.