paint-brush
RBAC (Role-Based Access Control) via OAuth2.0 Scopes with WSO2 Identity Serverby@dinali
1,973 reads
1,973 reads

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

by DinaliSeptember 20th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

WSO2 Identity Server is a standard CIAM solution that is fully open source and powered by a strong IAM community. 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. The scope is a mechanism that is used in OAuth2.0 to restrict the access granted to an access token of a user. I hope you got a better understanding of how this works and how it works.

Company Mentioned

Mention Thumbnail
featured image - RBAC (Role-Based Access Control) via OAuth2.0 Scopes with WSO2 Identity Server
Dinali HackerNoon profile picture

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

After identifying who the user is with what the user has (authentication), next we need to do access control 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 bound 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.0 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

Get details of OAuth 2.0 scopes

GET request with Basic authentication.

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

Delete OAuth 2.0 scopes

DELETE request with Basic authentication.

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


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.

    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.

    <iframe width="560" height="315" src="https://www.youtube.com/embed/DF6EUB6kt7s" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>


    I 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.