Customer Case Example
One of our customers had a custom Authorization Service for authorizing certain Paths. For Authentication they were utilizing Okta. They wanted an Authorization policy that can be applied at a global level so that there is no need for each API to call their own custom authorizing service from mediation logic. They had many API’s and having mediation policies for each API was not an option.
WSO2 Default mediation gateway flow can be extended with different types of extensions. The three main extensions are listed below.
[1] Custom Sequences [2] Custom API Handlers [3] Custom Synapse HandlersCustom Sequence
Synapse sequences can be engaged in the request in flow or the response out flow. This approach requires mediation sequences to be created for each API. Whenever a new API is created a custom sequence can be added for Authorization.
Custom API Handler
In this approach a custom handler (extending org.apache.synapse.rest.AbstractHandler class) is written and signature is added to each API. If change needs to be made for all API’s then velocity_template.xml is edited. Problem with this approach is that all existing API’s must be deployed again. Also, there are cases where unsecured APIs are there and this change effects those too. Apart from these, this change will make the upgrades harder as changes to the velocity file will need to be manually merged. Issues with this approach is well documented in wso2 documentation (https://docs.wso2.com/display/AM210/Writing+Custom+Handlers)
Approach
We decided to go with the custom synapse handler approach for our project as there would be no need to manually add a Handler signature in each API, unlike when using a Custom API Handler, as referenced above.
High Level Steps
1) Write a custom Java code that implements org.apache.synapse.SynapseHandler interface and methods (handleRequestInFlow(MessageContext messageContext) and handleRequestOutFlow(MessageContext messageContext) ). handleRequestInFlow(MessageContext messageContext) is the method that executes just after request hits the synapse engine (APIM) and holds the logic for deciding if request needs to be sent to backend or not.
2) Create a JAR and deploy it to ${wso2_APIM}/repository/components/lib directory. This can be automated using Jenkins pipelines
Implementation Steps
1) Extend the global handler to connect to Authorization Service
2) Override the handleRequestInFlow(MessageContext messageContext) to call the Custom Authorization service and set the isAuthorized Flag based on the response.
3) Pass this flag(isAuthorized) to Mediation Sequence (if Any). If there is no mediation sequence just keep it empty.
4) Override the handleRequestOutFlow(MessageContext messageContext) to check the flag Status.
Conclusion
Overriding the synapse handler allows to put custom validations before request reaches the endpoint. Since this is a global policy, each API needs not to be changed/redeployed.
