Building Secure MCP Servers: Authentication, Tool Discovery, and Authorisation Explained
Understanding how MCP works so that enterprise-grade systems can discover, authenticate, authorise, and expose tools based on user permissions.
Understanding how MCP works so that enterprise-grade systems can discover, authenticate, authorise, and expose tools based on user permissions.
APIs have become the building blocks of modern software applications, enabling data and services to be shared across diverse platforms and devices. As we have been understanding in this series, Azure API Management (API-M) is there to manage our APIs. So, the security of itself and the safety of the APIs it manages are equally important. This post will explore the options available to protect our APIs and API-M out of the box and look at examples of implementing some of them.
Azure API Management (API-M) policies are the heart and soul of the service. It is, in fact, the most powerful feature that makes API-M stand out as an API management suite. Policies are a collection of XML and C# code snippets executed sequentially on an API’s request and response flow, controlling its access behaviour and format of the payload. In this post, we will understand more about policies and some design considerations. We will learn how to use this powerful feature to enhance and protect our backend services and how it can genuinely shine as a management layer to our APIs.
Changes and enhancements are inevitable in any product that wants to keep up with evolving requirements. Azure API Management (API-M) offers offers robust features to facilitate this process. One of the key aspects of API Management is revisioning and versioning, which ensures that our APIs remain functional and relevant as our service evolves. In this post, we will explore the concepts of revisioning and versioning in Azure API Management, learn how to leverage these capabilities effectively and discuss some design considerations.
Azure API Management Products logically separates APIs into units to offer a subset of the APIs or different SLAs to consumers. It’s a powerful concept that makes API-M stand out to offer true enterprise-ready managed API service. So it’s important to understand the basic principles and design considerations of designing products in API-M, which this post will dive into.
Azure API Management (API-M) is a fully managed service offered by Microsoft Azure that enables organisations to create, publish, secure, and manage APIs at scale. It acts as a gateway between backend services and consumers. It provides a unified platform for API creators, administrators, and developers to collaborate and manage the entire API lifecycle efficiently. This post is first in its series that will examine how Azure API-M fits in the iPaaS architecture and several key features it offers to API developers and consumers.
Bicep is a Domain Specific Language (DSL) that defines and uses to deploy Azure resources. It provides a declarative way to express infrastructure as code (IaC) and enables you to define, manage effectively, and version your Azure deployments. It is crucial to structure your code properly for a maintainable and scalable Bicep project. This blog post will explore the best practices and guidelines I followed for structuring the Bicep codebase.
Standard Logic Apps are suitable when it demands better isolation, performance and control over the executing environment. Unlike Logic App per workflow in the consumption model, Standard Logic App can host unlimited workflows. Further, the Standard Logic Apps model separates the concerns of deploying infrastructure and workflows into two different flows. This blog will give an overview to understand What LogicApps are, what flavours it offers and step through package and deployment steps using Azure DevOps pipelines.
Azure allows organisations to connect to cloud resources in many ways securely. Azure Private Endpoints and Private Links are two powerful features this blog post will explore to understand when they are best to use to make your cloud environment compliant with many industry standards.
Azure provides a cost-effective way to host and deliver single-page applications and static websites. Whether you use modern JavaScript frameworks like React, Angular, Vue, or similar or basic HTML pages where you don’t need server-side processing to deliver your pages, Azure Storage account provides serving these static content as a scalable and reliable solution much cheaper compared to other options available. In this blog, we explore how we automate the deployment of such a website into an Azure storage account.
When automating infrastructure deployments in Azure DevOps using pipelines, we often face the challenge of extracting the values calculated within the infrastructure scripts in follow-up tasks. This post looks into how Bicep output variables can be accessed as Azure DevOps pipeline variables so that follow-up tasks can use those values to perform the utterly automated deployment.
Azure allows organisations an efficient way to classify Azure resources using tags. Azure tags are key-value pairs defined by users to manage and organise Azure resources for monitoring, billing and automation purposes. In this post, we look at how we do this effectively and cleanly using Azure Bicep and its native capabilities.
The ability to tag Azure resources significantly enhance resource management, cost allocation, and operational visibility. But like everything else, tagging also needs to be thought through and well-defined to ensure we find a balance to use it wisely. In this blog post, we will walk through the steps to define an effective Azure tagging strategy that aligns with the organisation’s needs and optimises resource management within the Azure environment.
When dealing with the Azure DevOps pipeline, we may have situations where we need to extract the current Azure subscription ID and use it as a variable in follow-up pipeline tasks. There are two ways of achieving this. One is storing the Azure subscription ID as a pipeline variable in a configurable place. Certainly nothing wrong with that. But we make the assumption we know it ahead of time.
It is undoubtedly one of the first questions I asked when I was a junior developer, and it is still a question from my team on a kick-off of a new project. How do we structure and set up our source code? What folder structure makes more sense? Is there a standard? Who decides the format and such standards? Let’s deep dive into this post to understand an ideal project folder structure.
Security is the primary concern in any application, especially cloud resources, when you don’t manage your infrastructure. Maintaining secrets, credentials, and permissions to secure communication of various application components is always a challenge. In this post, we deep dive into understanding what is a managed identity and particularly how to create and assign them to our Azure resources to establish secure communication.
This post will look at how to create an Azure service principal to integrate Azure DevOps Server with Azure services hosted in the cloud and a few essential things to consider when configuring it.
Before I dive into the article, I would like to post a question, and it is one of the general questions mostly I get from my team.
If you are a developer like me, it is not unusual what a “Hello World” means. It is the simplest fundamental way of ensuring your program or code is working in a new language. In a way, it’s your first step towards the incredible journey ahead.