Refer to the exhibit. An organization is running a Mule standalone runtime and has configured Active Directory as the Anypoint Platform external…

The most effective and direct method to restrict API access to a specific group of internal users, given the existing infrastructure (Mule standalone runtime, Active Directory) and constraints (no budget for new components), is the Basic Authentication - LDAP policy. Active Directory is an LDAP-compliant directory service. This policy can be configured to connect directly to the existing Active Directory to authenticate users based on their credentials and, crucially, to verify their membership in a specific group. This approach leverages existing systems without requiring additional software or infrastructure, thereby adhering to the budget constraint while providing robust, user-group-based access control.

B. Apply a client ID enforcement policy; the specific group of users will configure their client applications to use their specific client credentials

This policy authenticates the client application, not the end-user. It cannot differentiate between users or user groups if they share the same client application.

C. Apply an IP whitelist policy; only the specific users' workstations will be in the whitelist

This method is brittle and unmanageable. It controls access from specific machines, not for specific users, and fails if users have dynamic IPs or work remotely.

D. Apply an OAuth 2.0 access token enforcement policy; the internal Active Directory will be configured as the OAuth server

Standard Active Directory is not an OAuth 2.0 provider. This would require an additional component like Active Directory Federation Services (ADFS), which violates the "no budget for other system components" constraint.

1. MuleSoft Documentation, "Basic Authentication: LDAP Policy": This document details how the policy connects to an LDAP v3 compliant server, such as Active Directory. It explains the configuration for User DN search base, User DN search filter, and how these can be used to authenticate a user and implicitly check their attributes or group memberships stored in the directory. (MuleSoft Docs -> Anypoint Platform -> API Manager -> Policies -> Basic Authentication: LDAP Policy).

2. MuleSoft Documentation, "Client ID Enforcement Policy": This source clarifies that the policy's purpose is to allow access only to registered client applications, identified by their clientid and clientsecret. It does not provide a mechanism for end-user authentication or group validation. (MuleSoft Docs -> Anypoint Platform -> API Manager -> Policies -> Client ID Enforcement Policy).

3. MuleSoft Documentation, "IP Allowlist Policy": This documentation confirms that the policy works by checking the inbound request's IP address against a configured list of allowed IPs, demonstrating it is a network-level control, not a user-level one. (MuleSoft Docs -> Anypoint Platform -> API Manager -> Policies -> IP Allowlist Policy).

4. Microsoft Documentation, "Active Directory Federation Services Overview": Official Microsoft documentation explains that components like ADFS are required to extend Active Directory's capabilities to provide standards-based identity solutions, including OAuth 2.0. This supports the reasoning that standard AD alone is insufficient. (Microsoft Docs -> Windows Server -> Identity -> AD FS).