Manage & Restrict Role Based Access Of Endpoints Within An Application

Author: Kishan Jasani

Problem Statement (Scenario based)

• The Product Owner of any project needs to manage and restrict role-based access to endpoints within a Mule application. This ensures that an individual resource within a team can only access endpoints for which permission has been granted, rather than having access to all endpoints.

• To interpret the statement above, let’s consider an example scenario. Suppose the client requires a Mule application with three different endpoints, and they need to grant access to a specific endpoint for a particular consumer only.

For example:

• developer1 should access only the test1 endpoint.
• developer2 should access only the test2 endpoint.
• developer3 should access all (test1, test2 and test3) endpoints.

Solution

• To address the problem mentioned earlier, we will create two different Mule applications.

1. mule-oauth-provider-app

• This application will act as an Oauth provider. 
• It is not mandatory to use only this application as an Oauth provider. Instead we can use any other third party Oauth provider also.
• In this application, we will create 2 flows. 
• First flow will be used to create clients and generate a token.
• Second flow will be used to validate a token.
• We will create 3 scopes (dev1, dev2 and dev3) here and provide access to only particular endpoints to each scope.

2. test-client-app 

• This application will act as a client application which will consume the Oauth provider application. 
• This will be the main application where we will implement three different endpoints, and we will restrict the accessibility of these endpoints according to users’ requirements.
• We will create 3 endpoints (test1, test2, test3) here and restrict accessibility of each endpoint as per user.

• First, we will attempt to create an OAuth provider application within MuleSoft. You can skip this step if you already have another OAuth provider in place.

• Open Anypoint Studio and create a Mule application with the name mule-oauth-provider-app. 
• Add the following two modules to the application from Anypoint Exchange.

Create a flow to generate a client using an HTTP Listener, Create Client, and Set Payload Component. Use the default configuration for the HTTP Listener and set the path to /createClient.

Create configuration for OAuth provider.

While configuring the OAuth provider, also configure the Client Store and Token Store.

Here, I have attached a screenshot of the Create Client Configuration.

In the Set Payload component, set the payload as ‘Client Created.’

Create another flow for token validation using an HTTP Listener, Validate Token, and Transform Message Component. Use the same configuration for the HTTP Listener and set the path to /validate.

Here, I have attached a screenshot of the Validate Token configuration.

• After that, we can deploy this application to CloudHub.
• We will now have the following three endpoints active in this application.

• createClient : To Create a client
• /token        :  To generate Auth token
• /validate    :  To validate the token

• We will use all these endpoints after we create another application.

• Secondly, we will create a client application where we will implement restrictions to endpoints. 
• To implement the client application, we will create RAML with OAuth 2.0 policy added in the security schemes. 

• In the RAML mentioned above, we will have 3 endpoints (test1, test2 and test3) where we will restrict the access.
• Publish this RAML to Anypoint Exchange.
• Open API Manager from Anypoint Platform and Click on Add API.

Select Mule Gateway and click on Next.

Select our API from the list and create API instance ID for our application.

After creating the API Instance ID, select ‘Policies’ from the left palette and click ‘Add Policy.

Apply the Client ID Enforcement Policy from the list with the default configuration.

Add another OAuth 2.0 policy for the ‘test1’ endpoint.

While configuring this, add ‘dev1’ and ‘dev3’ to the scopes and provide the validation URL (/validate) of the authentication provider application.

In the advanced option, select GET method and test1 endpoint.

Similarly, add another OAuth 2.0 policy for the ‘test2’ endpoint. Mention ‘dev2’ and ‘dev3’ in the scopes and provide the validation URL (/validate) of the authentication provider application. In the advanced options, select the GET method and the ‘test2’ endpoint.

Similarly, add another OAuth 2.0 policy for the ‘test3’ endpoint. Mention ‘dev3’ in the scopes and provide the validation URL (/validate) of the authentication provider application. In the advanced options, select the GET method and the ‘test3’ endpoint.

Here is a screenshot of the applied policies

• Afterward, create a new application in Anypoint Studio named ‘test-client-app,’ add the RAML we created in Exchange, and scaffold all the flows.
• After scaffolding, we will not change anything in any of the flows.
• We will configure API Autodiscovery for this application, including the main flow and the API instance ID created in API Manager.

Deploy this application to CloudHub and don’t forget to add environment credentials in the runtime properties.

After successful deployment, ensure that the API Instance ID is in an active state in the API Manager.

• Let’s test this Implementation.

• To test this scenario, we will first create a contract for ‘developer1’ and generate a token for them.
• Open test-client-app from Anypoint Exchange.
• Request access to create a contract.

Select the API Instance and create an application named ‘dev1’ to request access.

• Note down Credential (ClientID and ClientSecret).
• From Postman, Send request(/createClient) to create client with this credential.

Afterward, send a request to ‘/token’ with the same credentials to obtain a token for ‘dev1’ scope.

When we hit the ‘test1’ endpoint with the access token and ‘dev1’ scope credentials, we will receive a successful (200) response.

When we hit the ‘test2’ and ‘test3’ endpoints with the access token and ‘dev1’ scope credentials, we will receive a Forbidden (403) error.

• Now, we will create a contract for ‘developer2’ and generate a token for them.
• Open test-client-app from Anypoint Exchange.
• Similarly, we will request access to create a contract.
• Select the API Instance, create an application named ‘dev2,’ and request access.

• Note down the credentials (ClientID and ClientSecret).

From Postman, Send request(/createClient) to create client with this credential.

Afterward, send a request to ‘/token’ with the same credentials to obtain a token for ‘dev2’ scope.

When we hit the ‘test2’ endpoint with the access token and ‘dev2’ scope credentials, we will receive a successful (200) response.

When we hit the ‘test1’ and ‘test3’ endpoints with the access token and ‘dev2’ scope credentials, we will receive a Forbidden (403) error.

• Now, we will create a contract for ‘developer3’ and generate a token for them.
• Open test-client-app from Anypoint Exchange.
• Similarly, we will request access to create a contract.
• Select API Instance and create an application with name dev3 and request access.

• Note down Credential (ClientID and ClientSecret).

Using Postman, send a request to ‘/createClient’ to create a client with these credentials.

Afterward, send a request to ‘/token’ with the same credentials to obtain a token for the ‘dev3’ scope.

We will receive a successful (200) response when we access any (test1, test2, and test3) endpoint with the access token and ‘dev3’ scope credentials.

This is how we can restrict endpoint accessibility within an application using Client ID Enforcement and OAuth 2.0 policies.