In Azure API Management, products allow you to expose multiple APIs in a uniform manner towards your API consumers. In earlier versions of Azure API Management, a product was the only way through which you could expose your APIs. Nowadays, you can also create subscriptions that are scoped directly to APIs.
Lately, I was working on a project the heavily leveraged the concept of products. We defined three generic products, that handled all front- and backdoor security. Each API was linked to at least one of these products. It was a very powerful solution, but we needed a way to ensure that only product subscriptions could be used. Otherwise, we risked that all our security measures got by-passed.
We achieved this within our release pipeline, by dynamically injecting this inbound policy expression for every API.
<choose> <when condition="@(context.Product == null)"> <return-response> <set-status code="401" reason="Unauthorized" /> <set-body>Direct API access is not allowed. Provide a valid product subscription key.</set-body> </return-response> </when> <otherwise /> </choose>
Are you intensively using API Management products? Maybe it’s worth checking if by-passing these products imposes a risk for your organization. If yes, this might be your solution. Do you have other ways to deal with this? Don’t hesitate to let me know!
UPDATE: In the meantime, I blogged about another solution that leverages Azure Policy.