overambitious api gateway | Versatile Digital DNA

I came across the term ‘Overambitious API Gateways’ from Thought Works tech radar. The point is, whether is it good or bad to have business logic in the API Gateways? Since the term Gateway is not a functional requirement and serves the purpose of a reverse proxy; it is quite obvious that including business logic in an API gateway is NOT a good design. But the idea behind the overambitious API gateways, seems to be a finger pointing at the API Gateway vendors, rather than considering the solution design and development and how the API Gateways should be used.

I prefer the term ‘Thick API Gateways‘ over overambitious API Gateways because the implementation is up to the developer regardless of what the tool can offer. This ensures an anti-pattern.

With the advent of microservices architecture, API Gateways gained another additional boost in the developer tool box, compared to other traditional integration technologies.

giphy

Microservices favor the patterns like API composer (aggregation of results from multiple services) Saga (orchestration of services with compensation) at the API Gateway. API Gateways also host other business logic like authorization, model transformation and etc. resulting a Thick API Gateway implementations.

Having said, though thick API gateway is a bad design and brings some awkward feeling at night when you sleep, in few cases it is quite inevitable. If you’re building a solution with different systems and orchestration of the business flows is easy and fast at the API gateway. In some cases it is impossible to change all the back-end services, so we should inject custom code between the services and API gateways to achieve this, which would result other challenges.

At the same time, as developers when we get a new tool we’re excited about it, and we often fall into the ‘if all you have is a hammer, everything looks like a nail‘ paradigm. It’s better to avoid this.

giphy1

Let’s see some practical stuff; in fact, what kind of business logic the modern API gateways can include? For example, if we take the gateway service offered in Azure API Management (APIM), it is enriched with high degree of programmable request/response pipeline.

Below APIM policy, I have provided an authorization template based on the role based claims.

The API gateway decides the authorization to the endpoints based on the role based claims. The sections are commented, first it validates the incoming JWT token, then sets the role claim in the context variable and finally handle authorization to the endpoints based on the role claim.

	<policies>
	<inbound>
	<!– validates RS256 JWT token –>
	<validate-jwt header-name="massrover_token" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized"
	require-expiration-time="true" require-signed-tokens="true">
	<audiences>
	<audience>audience id</audience>
	</audiences>
	<issuers>
	<issuer>issuer id</issuer>
	</issuers>
	<required-claims>
	<claim name="role" match="any">
	<value>admin</value>
	<value>moderator</value>
	<value>reader</value>
	</claim>
	</required-claims>
	<openid-config url="https://massrover.idenityserver/.well-known/openid-configuration" />
	</validate-jwt>

	<!– sets the role claim to the context variable –>
	<set-variable name="massrover_role"
	value="@(context.Request.Headers["massrover_token"].First().Split(' ')[1].AsJwt()?.Claims["role"].FirstOrDefault())" />

	<!– performs authorization based on role claim and allowed http method –>
	<choose>
	<when condition="@(context.Variables.GetValue("massrover_role").Equals("admin"))">
	<forward-request/>
	</when>
	<when condition="@(context.Variables.GetValue("massrover_role").Equals("moderator")">
	<when condition="@(context.Request.Method.Equals("delete", StringComparison.OrdinalIgnoreCase))">
	<return-response>
	<set-status code="403" reason="Forbidden" />
	<set-body>Moderators cannot perform delete action</set-body>
	</return-response>
	</when>
	<otherwise>
	<forward-request/>
	</otherwise>
	</when>
	<when condition="@(context.Variables.GetValue("massrover_role").Equals("reader")">
	<when condition="@(context.Request.Method.Equals("get", StringComparison.OrdinalIgnoreCase))">
	<forward-request/>
	</when>
	<otherwise>
	<return-response>
	<set-status code="403" reason="Forbidden" />
	<set-body>Readers have only read access</set-body>
	</return-response>
	</otherwise>
	</when>
	<otherwise>
	<return-response">
	<set-status code="405" reason="Not Allowed" />
	<set-body>Invalid role claim</set-body>
	</return-response>
	</otherwise>
	</choose>
	<base />
	</inbound>
	<backend>
	<base />
	</backend>
	<outbound>
	<base />
	</outbound>
	<on-error>
	<base />
	</on-error>
	</policies>

view raw

jwt claims based authorization.xml

hosted with ❤ by GitHub

Note: This is a thick API gateway implementation and the pros and cons of this is subject to the problem in hand. This above is a practical elaboration of one thick API implementation.

Share this: