Implementing Basic Authentication and JSON Threat Protection in MuleSoft
Introduction
- This blog will contain the steps that is necessary to implement the basic auth and threat protection policy on top of API.
- For demonstrating this I’ll be going with a usecase where I’ll be creating records into the Salesforce custom object and how we restrict the access for API using basic auth and prevent the API from the attacks by making use of threat protection policies.
Pre-requisites
- We need to have an active Anypoint platform account as well as Anypoint Studio should be set up.
- We need to have a Salesforce developer account.
- Create a Salesforce custom object with some fields, as per the requirement.
- Click on create in the home section, which is on the right-hand side. Then click on a custom object, then fill in the name of the custom object. Then click on fields and relationship, then select the fields with the respective type of information.
- In this scenario, we’ll be having 5 fields i.e. StoreId c, StoreName c, StoreLoc c, StoreEmail c and StorePhone__c, where all the fields are having Text as the type of information stored in it.\
- We need to keep the security token handy for that, click on profile and then click on setting which is on the right-hand top corner of the screen type security token in the quick find section, and click on reset security token.
- The security token will be sent to the registered mail ID.
Implementing Basic Authentication and JSON Threat Protection in MuleSoft
- Policies are some set of rules applied on top of our API to enforce security, govern the behavior and manage traffic.
- These policies standardize the APIs and protect from the attacks.
- There are some scenarios where we need to make use of policies. Some of the scenarios are:
- When we want only authenticated user can access the API.
- When we want control the number of requests coming to API.
- There are other scenarios where it can be useful, such as restricting the access to the API on the basis of IP address.
- In this blog, we will discuss about the how to implement basic authentication and json threat protection on top of APIs. For this instance, we’ll create an API for which will store records to salesforce.
Steps:
- First, we will create an API specification for this instance.
2. Next, we’ll publish the API specification to exchange.
3. Then we will create a new Mule project and scaffold it.
4. Next, we will add 2 loggers which determines the start and end of flow.
5. Then we’ll create a new mule configuration file for the implementation.
6. Next, we’ll add a flow reference in between the start logger and the end logger to call the implementation flow.
7. Then we’ll add a transform message into a flow to map the records to the salesforce custom object.
8. Now we’ll place a salesforce create a component to create the record in the Salesforce custom object and we’ll configure it as it is done below. Here, we will refer to the username, password, and security token from the secure file.
9. Next, we’ll add a transform message to transform the response coming back from Salesforce into JSON format.
10. Next, we’ll import the API to the API manager from the exchange. For that, we need to navigate to the API manager and click on Add API. Then, select Add new API and select the gateway as Mule team, proxy type as a Basic endpoint, and mule version as Mule4.
Select the API that is scaffolded with the application and click on next. As of now, no need to configure downstream and upstream. Then save it, and the API will be registered into the API Manager.
11. Next, we’ll add the API instance id ad configure the flow name as the main flow in the API autodiscovery.
12. Then we’ll deploy the application to CloudHub, while deploying we need to pass the key for the decryption of secure properties, client_id, and client_secret.
13. Once the application is deployed, we’ll apply the polices to our API.
- For basic auth, we need to configure the username and password.
- For example, if we don’t pass the correct username and password then it will throw an error shown below.
- For threat protection, we need to configure the following:
- Maximum depth allowed: It specifies the maximum depth allowed for the body. If the value of this field is 2 then the depth cannot exceed 2. For example, we’ll send this body which is having depth as 3 then it will throw an error which is shown below.
[
{
“a”: {
“b”: “c”,
“d”: “e”
}
}
]
- Maximum string value length: It specifies the maximum length of value. If the value of this field is 15 then the length of name cannot exceed than 15. For example, we’ll send this body which is having length of the value greater than 15 then it will throw an error which is shown below.
{
“name”: “Donald Bradman123”
}
- Maximum object entry value length: It specifies the maximum string length allowed for object entry name. If the value of the field is 4 then the field name cannot exceed 4. For example, we’ll send this body which is having length of the field greater than 4 then it will throw an error which is shown below.
{
“CustomerName”: “ABCDEFGH”
}
- Maximum object entry count: It specifies the maximum entry in an object. If the value for this field is 2 then object entry cannot exceed 2. For example, we’ll send this body which is having field count greater than 2 then it will throw an error which is shown below.
{
“a”: “b”,
“c”: “d”,
“e”: “f”
}
- Maximum array element count: It specifies the maximum number of elements allowed in an array. If the value for this field is 1 then the elements array cannot be more than exceed 1. For example, we’ll send this body which is having array element count greater than 2 then it will throw an error which is shown below.
[
{
“a”: “b”
},
{
“c”: “d”
}
]
(Note: If the value for any of the above fields is -1, it implies that it does not have any restriction for that.)
14. Lastly, we’ll pass the body that meets the above criteria to check if we get a successful response.
