MuleSoft provide instructions for setting up Entra ID as a client provider. However, they fall short of an end-to-end guide, and in particular they don’t tell you how to set up the Entra ID side. Complete the steps below to do this first, and then run through MuleSoft’s guide.
Entra ID App Registration
- Sign in to Azure Portal and navigate to Entra ID → App Registrations
- Create an App Registration. This will represent the Anypoint Platform.
- On the API Permissions tab, assign the following permissions:
- Application.ReadWrite.OwnedBy (Application)
- User.Read (Delegated)
- Make a note of the following details on the created application’s overview page:
- Client ID (Application ID)
- Tenant ID
- Click on endpoints and copy the value found in WS-Federation sign-on endpoint
- Click on Certificate & Secrets → New client secret
- Make a note of the secret (it will only be shown once, at creation)
Note, that handily there is a permission available that allows MuleSoft to have control over app registrations it creates while preventing it from interacting with other app registrations which are none of its business. This helps to alleviate some security and compliance concerns as the scope is limited to only what it needs.
MuleSoft Configuration
At this point you can go through the MuleSoft Configuration Walkthrough guide.
Go to Anypoint Access Management → Client Providers → Add Client Provider → OpenID Connect DCR for Azure
and fill in the following values with the details you copied down from the above steps:
- Issuer = the WS Federation sign-on endpoint URL
- Tenant ID
- Client ID
- Client Secret
The client provider is set up but now you need to associate it with one or more Environments:
Go to Access Management → Business Groups
Choose the Environment you want to be OAuth-enabled. In the client provider dropdown list, select the new client provider.
Behaviour of the Client Provider
The following are some observations of how Anypoint works after setting up the Client provider.
Secrets
Because Entra ID generates certificates with a maximum lifespan of 2 years, the following will be needed:
- Rotation of the secret used by the Client Provider so that it is continues to be able to make new clients after the initial 2 year period.
- Each client app that is created in Entra ID will also have secret with an expiry of 2 years expiry secret, so on an ongoing basis you will need to cater for monitoring of these secret expiry dates, along with a process for coordination of the replacement of these secrets with your client application providers/vendors.
The expiry date of the generated secret is not fed back to Anypoint (or at least it is not displayed), so you need to reply on the Entra ID portal to do this monitoring.
When you initially create a client app in Anypoint (via Anypoint Exchange → Request Access), behind the scenes it generates an App Registration in Entra ID. The client ID and secret are passed back to Anypoint, and so at the point of creation Anypoint and Entra ID are in sync. You can therefore use Anypoint to reveal the ID/secret and pass this to whoever manages your client application. However, if you then use the “Reset Secret” button in Anypoint, it changes the secret in Anypoint, but doe not sync it back to Entra ID.
The only secrets that matter are the ones held in Entra ID, because this is where the client will authenticate. Pressing the “Reset Secret” button in Anypoint has no effect, because the client app is never coming to Anypoint to authenticate.
To generate a new secret for a client, or to manage a rollover of a secret before it expires, you must use the Entra ID functionality, not the Anypoint functionality.
What if I don’t want OAuth on an API?
After setting an external client provider, if you go in to an API in API manager, and look at the settings tab, you will see this warning:
This might cause concern. What about the case where you just want a process API to connect to a system API, surely we aren’t going to be forced to use OAuth for this?
Thankfully, although it is not that obvious from the screens that are presented, this is not the case. The behaviour changes depending on which authentication policy you apply to an API:
If you choose Client ID Enforcement policy, then you are still able to use a basic client_id and secret. An App Registration is not created in Entra ID in this case.
If you choose OpenID Connect Access Token Enforcement, then the App Registration is created.
The OAuth flow is only invoked if the OpenID Connect policy is applied, otherwise the request is validated using the client_id and secret held locally in Anypoint.
Logging and Auditing
Entra ID
The Entra ID audit log shows the following events occurring when a new Client App is created:
| Action | Activity types and details |
| Client App created | Add Application Update to the Anypoint App Registration to set it as owner of the newly created App |
| Setting the client secret | Update Application – Certificate and Secrets Managment |
| Unknown final step | Update Application No propoerties identifed in the log. |
Disappointingly, there is nothing in the Sign In logs (either interactive or non-interactive) that indicates the usage of the App Registration. It is impossible to tell if or how often, for where etc the client app is being used! Poor form from Microsoft!
