In the realm of enterprise communication, safeguarding backend systems and authenticating incoming requests stand at the forefront of concern. Here we will delve into the creation of a specialized API, which is designed not only to extract the necessary information from backend systems but also to take a step beyond the traditional methods of authentication. It checks and authenticates incoming requests based on their source and the requester’s role. Our focus is to explore how the MuleSoft AnyPoint Platform, equipped with this API, facilitates secure B2B communication, providing tiered access to data in accordance with an individual’s role within an organization.
For this use case, a challenge emerged that necessitated a custom solution. Our needs surpassed the abilities of standard policies provided by the AnyPoint API Manager. We were seeking a dynamic micromanagement functionality to ascertain client application authorization grounded on various criteria, inclusive of data encryption using mutable algorithms. Neither could the Static Secure Module Configuration fit the bill, as we were presented with a dynamic symmetric key – similar to a refresh token – from an external identity provider. Further, the Basic Authentication Policy of the AnyPoint API Manager was not equipped to handle more than two fields.
Consequently, we constructed a custom solution using Spring authentication. This involved the dynamic decryption of unknown data from external clients, utilizing specific algorithms and modes, a procedure somewhat akin to implementing single sign-on (SSO) using SAML or OpenID Connect with an identity provider like Okta. Though the process was taxing, it ultimately proved to be a worthy investment.
Understanding the Context of B2B Communication
In the realm of business-to-business (B2B) communication, it is crucial to restrict access to authorized entities. For instance, car dealerships, taxi companies, and vulcanizers may require specific data and services. That is why we aim to create an API that focuses on providing services exclusively to these retailers while ensuring the segregation of data based on different roles such as CEO, Sales, Human Resources, Project Manager, and Employer.
Utilizing Spring Security for Basic Authentication
To secure the API and validate the incoming invocations, we employ the widely used Basic Authentication mechanism. The incoming request contains a Basic Authentication header that contains four values: username, password, role, and organization. After receiving the header, we decrypt it and extract values and put each one in different variables for further use. Then we create a new header by using only the username and password and validate it with the “Basic Security Filter” component.
We use the Spring security framework to validate the new Basic Authentication header. To do this, first, we must add the Spring Module to the application.
Then we create a “bean.xml” file in the resources folder and add the following code:
Here we reference the valid credentials from the properties file where they are stored. This step ensures that only authorized users with valid credentials can access the API’s functionalities. Lastly, we need to create the global elements required.
Decrypting and Validating User Credentials
When we receive the request, the username and password in the Basic Authentication base64 header are encrypted. Before we create a new header without the role and department values in it, we need to decrypt the username and password to validate them. To do this, we use the secure properties tool. To use the secure properties tool, first, you must download the jar and add it to the project. Then you need to reference the jar in the Java build path libraries.
This is the way to do it if you want to implement this individually, but if it is done for a client, then the jar should be deployed on the client’s Nexus repository. Then we invoke the Secure Properties Tool in the “Extract and Decrypt Credentials” Transform DataWeave script to decrypt the username and password that we received in the request. The decryption key, algorithm, and mode are dynamically retrieved from a separate third-party authorization service based on the organization and stored as a flow variable.
Role-Based Access Control
To enhance security and maintain data segregation, the API incorporates role-based access control (RBAC). RBAC allows us to define specific permissions and restrictions based on different user roles within the organization. For example, the CEO might have access to sensitive financial data, while the Sales team can view customer information. RBAC ensures that each user is granted appropriate access rights, minimizing the risk of unauthorized data exposure. We use the role value that we receive in the request to query data from the database based on that role.
Conclusion
Constructing a role-based, secure API for B2B communication is a critical requirement in today’s enterprise environment. By introducing features like basic authentication and role-based access control – akin to configuring single sign-on (SSO) using SAML or OpenID Connect on the MuleSoft AnyPoint Platform – organizations can secure and manage access to their backend systems. This strategy doesn’t only protect sensitive data but also ensures that the correct information is delivered to authorized users alone, in line with their roles and responsibilities. With careful implementation and adherence to security best practices, this API holds the potential to become a fundamental element in secure B2B communication across a variety of industries.
Authors:
Hristina Bendeva | Marin Apchevski
