Integrating Mulesoft and OAuth2
This post will show you how you can create your own custom Anypoint platform API policy.
This policy will be used to verify authentication tokens from an OAuth2 provider, such as Microsoft or Google.
With minor modification/extension to the application code this API policy can be adjusted to any provider.
This post will only concentrate on verification of the tokens and not issuing/creation of OAuth2 tokens.
Set up your development environment
Mulesoft does not provide any environment to develop API policies. There were some plans to add this feature to Anypoint Studio, but I am unclear about what happened to those plans or why the option was removed from newer versions (> 7.15).
Instead you can setup this docker environment:
mikeacjonesThanks Michael
A few recommendations when working with docker-mulesoft-policy-tester:
- Mount your .m2 repository into the container to speed up the creation and startup times of the docker container, you will not have to wait for all of the dependency downloads to complete each time.
- The scripts (start.sh & update.sh) in the image assumes that your pom.xml file has specific tags like <version> on specific lines, see below:
...
# make sure the groupID matches the policy-config.json file
GROUP_ID=$(sed '3!d' policy-config.json | awk -F'"' '{print $4}')
sed -i "6s/<groupId>.*<\/groupId>/<groupId>$GROUP_ID<\/groupId>/" pom.xml
# update the version in the pom.xml
INITIAL_VERSION=$(sed '5!d' policy-config.json | awk -F'"' '{print $4}')
sed -i "8s/<version>.*<\/version>/<version>$INITIAL_VERSION<\/version>/" pom.xml
...start.sh uses sed, expects <groupId> on line 3 and <version> on line 8
You should be aware of this because it might cause 'redeploy.sh' to not work correctly and you will not see your code changes reflected in the container environment.
Now that you have a development environment setup we can continue with the next step.
Mulesoft/Dataweave code for the policy
This part will focus on the actual code for the policy.
Follow this workflow from Mulesoft to get started with your project structure:
The policy will consist of two parts.
- GUI code (my-custom-policy.yaml)
- Application code (src/main/mule/template.xml)
This is the validation flow taken from Nginx, i will show my implementation for Mulesoft/Dataweave:
Anypoiny Platform GUI:
Pseudo code:
<choice>
<when access_token missing>
return 403 Unauthorized "access token missing"
<otherwise>
post access token to introspection endpoint
<choice>
<when access_token is valid>
http policy execute next
<otherwise>
return 403 Unauthorized "access token is invalid"Application logic:
If the code reaches the <http-policy:execute-next/> statement, the token is considered valid and the request is either passed on to the next policy in the chain or to the application if no other policies are to be evaluated.
If the execute-next statement is not reached the request is dropped and a HTTP 403 (Unauthorized) is returned to the caller.
If the access-token is not found in the request header the policy will respond with a different 403 error message and drop the request.
A typical response from an OAuth2 Introspection endpoint can look like this:
{
"active": true,
"scope": "read write email",
"client_id": "3fsdf5",
"username": "aaronpk",
"exp": 1437275311
}Example response from introspection endpoint
The application logic in this case is that it checks that 'active' is true, and that the scope section match your setting in Anypoint Platform API Manager when you applied this policy to an API.
There are a few benefits of using a custom policy instead of the Mulesoft provided policy:
- Mulesoft provided OAuth2 policy is tightly integrated with DCR (Dynamic Client Registration) functionality for the provider side.
- Allows you to keep your existing client_id + client_secret authentication API policy without modifying existing API contracts.
- Allows segregation of duties: Access token is provided by a separate process/group.
Read more about how an token introspection endpoint works:
