Let’s explore how ABAC could be implemented effectively for Mulesoft API gateway through a custom policy.
How can we automate the processes of API registrations and access controls to make it easier to manage at scale? Attribute-based access control (ABAC) has unique advantages over role-based access control (RBAC) for API gateway management, especially when it’s enabled with the OAuth2 JSON web token (JWT). Let’s explore how ABAC could be implemented effectively for Mulesoft API gateway through a custom policy.
Background
By default, the Mule Anypoint Platform comes with its own identify provider (IdP) (ref2). This IdP is intended to help customers to jump-start their projects or create PoCs. It is not provided for production deployments, especially with a large number of client applications. For that purpose, Mule supports integration with external IdPs, such as Okta, OpenAM, etc.
Mule and External IdP Integration Solution
To access secured APIs, users or machines need to be registered with the external IdP either through Mule or at the IdP first, then request permissions for API accesses. OOB, Mule enables authorization and access control through RBAC. Authorizations to the APIs have enforced through Mule provided default policy - Client ID Enforcement Policy (ref3). For now, Mule can only be configured with a single external IdP since it’s configured at the organization level.
The main benefit of using an IDP configured through Mule is that many default policies are readily available to support OAuth2 token. However, there are scalability and configuration management issues. When the number of registered users/machines are more than a few hundred, managing the access rights to the APIs is overwhelming. It’s not uncommon for web applications to have users in hundreds of thousands. Also, Mule and the external IdP are tightly coupled since the client-ids need to be synced for the author and authN to work.
Identify Federation
Identify federation enables external users created in Mule dynamically and map external user groups to predefined roles in Mule. However, you cannot grant the user access to APIs through roles in Mule at runtime since no roles with such permission exist. (Even you can define such roles, it’s too much burden to manage mappings from LDAP groups to Mule roles with permissions to access a large number of Mule APIs.)
ABAC addresses the concerns of automation of user registrations and API access control more elegantly by decoupling the two. Managing access rights of a large number of users/machines is the wrong approach since the users do not and should not care about API credentials after they have SSO through the federation.
#integration #mule #jwt #api gateway #mulesoft 4 #api
