Andrew Wilson's Blog

{ ... Plan - Architect - Develop - Reflect - Improve - Repeat ... }

Azure API Management | Unintentional Removal of Request Forwarding to Backend

Problem Space I have recently been working on an API scoped policy within API Management, the policy ideally should not be impacted by any policies defined higher up in the hierarchy. For reference, this means that any policies defined at the Product, Workspace, or Global level will not be inherited at the API scope for the given API Definition. See diagram below: Ideally this means that my API traffic will start at my non-hierarchical policy definition, conduct any policy processing prior to being sent off to the backend, and then sent back to the calling outbound system.

Azure API Management | Governing Product Visibility and Access via Groups

Overview In API Management, users and groups are a core aspect of the Developer Portal and are used to manage the visibility and access to respective products and their APIs. One of the common questions that I often get asked is, “how do I appropriately govern the groups effectively so that I can ensure that the correct groups and users have access to the appropriate resources and those who don’t… well don’t?

Microsoft.Web/Connections | Access Policies

Problem Space I have recently been adding email alerting to some Logic App Standard workflows as part of the error handling flow. In doing so I made use of an existing Office 365 Outlook Connector in the Azure Subscription; the connector is not built in for Standard Logic Apps but is rather part of the Managed Api Connections. Managed Api Connectors require more than just the connection details to be detailed in the Logic Apps connections.

Easy Auth | Standard Logic App with Azure API Management

Overview The recent work that I have been doing with Standard Logic Apps and linking them as backends to Azure API Management has relied on the use of the Logic App Workflow SAS key for security. This is a valid authentication approach, but there are risks that you need to be aware of as well as best practices that you need to be abiding by. Such as: Some Potential Risks:

Bicep | User Defined Types

Problem Space Over the years of developing Infrastructure as Code (IaC) with either ARM templates or Bicep (since it was released in 2020), I have made it my best practice where possible to use well-defined base type parameters (Strings | Integers | Booleans) so that the templates are usable and maintainable by collaborators apart from myself. This usually equated to where possible avoiding the use of Object and Array parameters, although in many cases the use of these types was inevitable given the complexity of the infrastructure and resources being deployed.