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
* /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
* /permission/admin/manage/identity/applicationmgt/view
Delete OAuth 2.0 scopes
DELETE request with Basic authentication.
Permission required:
* /permission/admin/manage/identity/applicationmgt/delete
* /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/
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
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.