anypoint.platform.max_federation_expiration_time=<expiration time in seconds; specify 0 to disable caching>
OpenID Connect OAuth 2.0 Token Enforcement
Policy Name |
OpenID Connect OAuth 2.0 Token Enforcement |
Summary |
Allows access only to authorized client applications |
Category |
Security |
First Mule version available |
v3.8.0 |
Returned Status Codes |
400 - Invalid token |
401 - Unauthorized or Connection error when connecting to the authorization server |
|
403 - Forbidden, invalid client application credentials |
|
500 - Bad response from authorization server, or WSDL SOAP Fault error. |
This policy is only available in a Federated organization configured to use OpenID Connect as Client Management solution. |
The OpenID Connect OAuth 2.0 Token Enforcement Policy restricts access to a protected resource, by only allowing HTTP requests if the token provided in such request is a valid one and, optionally, the required OAuth scopes are fulfilled. The policy validates the token, by connecting to a OpenID Connect authorization server. The token is obtained specifying the credentials of an authorized client application when performing the OAuth dance.
Before applying this policy, make sure that you are familiar with its prerequisites
When you apply the policy, you may optionally define a space separated list of OAuth 2.0 scopes to be enforced by it. OAuth 2.0 scopes are a way to further limit access to a resource protected by OAuth. You may define words like READ, WRITE, or some others that make sense in the context of your organization (eg. CONTRACTOR, PUBLIC, EMPLOYEES_ONLY, etc).
Supported Grant Types
OpenID Connect supports two types of OAuth grant types:
-
Authorization code
-
Implicit
For performing the OAuth dance, you will be required to provide client application credentials. For this protocol only, take into account that client application client Secret reset is not supported. |
Performance
After the system validates a token, by default the token is cached until expiration to improve the performance. In certain cases, such as revoked token scenarios, you might reduce or even disable caching.
To control token cached time before retrying validation against the OAuth Provider, specify the following property:
Communicating to the OAuth provider through a proxy
To enable the OpenID Connect OAuth 2.0 Token Enforcement Policy to use the Gateway proxy settings, specify the following property:
anypoint.platform.external_authentication_provider_enable_proxy_settings=<true|false(default)>
Setting the previous property to true makes the policy use the runtime proxy settings if specified. For example:
anypoint.platform.proxy_host=localhost anypoint.platform.proxy_port=8080
Leveraging OAuth provider information
When a token is successfully validated by the OAuth provider, the provider sends back to the policy who requested the token validation, some extra information, including fields that are OpenID Connect side configurable.
Token validation response example from the authorization server:
{
"uid":"john.doe",
"mail":"john.doe@example.com",
"scope":["uid","mail","cn","givenName"],
"grant_type":"password",
"cn":"John Doe",
"realm":"/",
"token_type":"Bearer",
"expires_in":3600,
"givenName":"John",
"access_token":"fa017a0e-1bd5-214c-b19d-03efe9f9847e"
}
The fields returned by the OAuth provider are processed by the policy, and:
-
For each field, the original request to the protected resource is enriched with HTTP headers in the form:
X-AGW-
+ key=value-
[Mule 4] As part of the policy configuration, you may choose to not Expose Headers. In that case, the request will not be enriched with
X-AGW
headers.
-
-
For further processing within the flow, the original unparsed response from the provider is made available for further processing.
-
[Mule 3] A flow variable
['_agwUser']
is setup. To access a particular value in the map, specify it directly using a MEL expression. For example:#[flowVars['_agwUser']['mail']]
-
[Mule 4] The information is stored in an
authentication
object. Supposing that a "mail" field is returned, its value can be accessed using the following DataWeave 2.0 expression:#[authentication.properties.userProperties.mail]
-
You can use the extra information to further tune your business logic. |
Open ID Policy for Anypoint Service Mesh
The Open ID Connect OAuth 2.0 Token Enforcement policy works in the same way for Anypoint Service Mesh (non-Mule applications), excluding the following limitations:
-
The policy does not offer the option to expose headers.
-
The policy does not include the option to enable third-party authentication server TLS validation using self-signed certificates.