RBAC (Role-Based Access Control) via OAuth2.0 Scopes with WSO2 Identity Server

WSO2 Identity Server is a standard CIAM solution that can is fully open source and powered by a strong IAM community. You can freely download WSO2 Identity Server from here and try this out. Here I am using latest released Identity Server 5.10.0 and sample pickup-dispatch.

After identifying who the user is, what the user has (Authentication), the next thing we need to do is control the access for the application based on the user's roles (Authorization). Hence Role-Based Access Control is a really important feature for enterprise software applications.

The scope is a mechanism that is used in OAuth2.0 to restrict the access granted to an access token of a user. In WSO2 Identity Server, there are two types of scopes available.

1. OIDC scopes — These are the scopes that bind to user attributes(WSO2 claims). You can use OIDC scopes to limit access user’s attributes.

eg: If the access token is taken from Scope openid, the user’s full details can be viewed. If scope email is used, the only PRIMARY email address will be visible(This can be configured as shown here).

2. OAuth2.0 scopes — These are the scopes that bind to roles (DEFAULT) and permissions(PERMISSION). By default these scopes will be bind to roles, but if you want you can bind these to permissions as well. For now, in WSO2 Identity Server Permission binding is used in the internal purpose only

In this blog, I will show you how we can use OAuth 2.0 scopes for Role-Based Access Control of a third party application.

Step1: Create OAuth 2.0 scopes and bind to roles

For OAuth2.0 scopes we do not have a UI option in the management console. But we have rest APIs to create OAuth2.o scopes with its relevant role binding.

Here I am creating a scope called “write_access” which bound to role called “manager”. You can refer below APIs for the creation of this scope.

Create OAuth 2.0 scope

POST request with Basic authentication.

Permission required:
* /permission/admin/manage/identity/applicationmgt/create

curl -k -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H  "Content-Type: application/json" -d '{
   "name": "write_access", 
   "displayName": "write_access",
   "description": "write access scope",
   "bindings": [
      "manager"
    ]
  }'  "https://localhost:9443/api/identity/oauth2/v1.0/scopes"

Get details of OAuth 2.0 scopes

GET request with Basic authentication.

Permission required:
* /permission/admin/manage/identity/applicationmgt/view

curl -k -X GET -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" "https://localhost:9443/api/identity/oauth2/v1.0/scopes"

Delete OAuth 2.0 scopes

DELETE request with Basic authentication.

Permission required:
* /permission/admin/manage/identity/applicationmgt/delete

curl -k -X DELETE -H "Authorization: Basic YWRtaW46YWRtaW4="  "https://localhost:9443/api/identity/oauth2/v1.0/scopes/name/write_access"

For more information on this OAuth 2.0 scope related API calls you can refer our official swagger documentation: https://is.docs.wso2.com/en/latest/develop/oauth2-scope-management-rest-apis/

Step 2: Register a third party application that needs RBAC

In this step, I am registering our sample pickup-dispatch application available here.

• Click on Add Service Providers and register a service provider name called pickup-dispatch.
• Click on Inbound Authentication Configuration -> OAuth/OpenID Connect Configuration and click on configure.
• Add the call-back URL as below

• Next, enable role-based scope validator and update as shown in the below image.

• Update the client-id and secrets in the dispatch.properties file in WEB_INF/classes folder of the pickup-dispatch web app.
• Add the scopes “write_access” to the scope list in the property file and restart the tomcat server to apply the changes.

Step 3: Create Users and manager role and try out

Here you can create two users called Alex and Bob. A role called a manager and assign it only to Alex.

Now we are ready to try out the scenario. You can see, only Alex can access the application, for Bob the authorization will fail.

Hope you got a better understanding of how OAuth2.0 scope based Access Control works and the difference between two types of scopes available in WSO2 Identity Server.

Please follow me and clap !!! It will encourage myself to write more :) Let me know your feedback as well