{"id":5,"date":"2023-01-11T19:57:26","date_gmt":"2023-01-11T18:57:26","guid":{"rendered":"https:\/\/d.r5.wbsprt.com\/matejbobaly.com\/?p=5"},"modified":"2023-01-11T19:57:26","modified_gmt":"2023-01-11T18:57:26","slug":"securing-service-to-service-http-triggered-azure-functions-using-client-certificates","status":"publish","type":"post","link":"https:\/\/matejbobaly.com\/?p=5","title":{"rendered":"Securing service-to-service HTTP-triggered Azure Functions using client certificates"},"content":{"rendered":"\n
\nThe code from this post is available from GitHub: https:\/\/github.com\/matejbob\/ClientCertificateAuth.git<\/a> .\n<\/pre>\n\n\n\n
Introduction<\/h2>\n\n\n\n
Beyond any doubt, Azure Functions<\/em> became a very popular serverless solution. Simple development model and smooth integration with other components of architecture using out-of-the-box triggers and bindings rank among the biggest strengths of Azure Functions.<\/p>\n\n\n\n
For the purposes of this article, Azure Functions can be divided into two categories based on the type of the client they’re intended to be consumed by:<\/p>\n\n\n\n
  • Web or mobile API<\/strong> (e.g., REST API or GraphQL): one or more Azure Functions comprise an API consumed by a user-facing front-end <\/li>
  • Service-to-service<\/strong>: Azure Function is a part of bigger architecture and as such it is invoked by other components of the system or by an external service<\/li><\/ul>\n\n\n\n
    Distinction between these two categories is key when deciding on the authentication method. In the first case, identity of the user comes into play. If authentication is required, typically either an Identity Provider<\/strong>, explained below, or a custom authentication mechanism is leveraged to sign in the person using the application. On the other hand, in the second case, it’s identity of the calling component that is involved and, unlike the former, this is when certificate-base authentication is practically applicable. In other words, certificate-based authentication is usually not a feasible option for user-facing APIs.<\/p>\n\n\n\n
    Another important division of Azure Functions when weighing up authentication alternatives is the type of the Azure Function trigger. In this regard, Azure Function can be:<\/p>\n\n\n\n
    • HTTP-triggered<\/strong>: Function is triggered by an HTTP request<\/li>
    • Other <\/strong>(e.g. using Timer Trigger, Azure Service Bus Trigger, Azure Cosmos DB Trigger etc.) <\/li><\/ul>\n\n\n\n
      As certificates pertain to HTTP, it’s obvious that it’s only this category of Azure Functions that can take advantage of certificate-based authentication.<\/p>\n\n\n\n
      From the argument given above, it follows that, in practice, service-to-service HTTP-triggered Azure Functions are suitable for certificate-based authentication. Remarkably, this type of Azure Functions is one of the most common.<\/p>\n\n\n\n
       Summary of alternatives <\/h2>\n\n\n\n
      When it comes to securing an service-to-service HTPP-triggered Azure Function, these are basic options to consider:<\/p>\n\n\n\n
      • Anonymous<\/strong>: no authentication\/authorization is performed, the Function may be called by anybody without any constraints<\/li>
      • API key<\/strong>: in order to invoke the Function caller must include secret API key<\/em> in its HTTP request<\/li>
      • Identity Provider<\/strong>: App Service <\/em>hosting the Function can use an OAuth2-based provider, e.g. Azure AD, to enforce authentication<\/li>
      • IP filter<\/strong>: when the hosting App Service is a part of Virtual Network in Azure, network traffic can be limited to specific source IP addresses, IP filtering should not regarded as a reliable security mechanism because of issues like IP address spoofing <\/li>
      • Client certificate<\/strong>: leveraging public-key cryptography and TLS, the caller presents a TLS certificate containing public key to the Function host and proves to posses corresponding (secret) private key<\/em>, based on this proof the Function host concludes that the caller is the subject described in the presented certificate<\/li><\/ul>\n\n\n\n
        The first three approaches are all well-documented on the Internet. This post focuses on the last option, namely authentication using client certificates.<\/p>\n\n\n\n
        Advantages of using client certificates<\/h2>\n\n\n\n
        Authentication based on client certificates stands somewhere between the API key authentication and using an identity provider when robustness, flexibility, scalability but also complexity are considered. It should be regarded as a more secure alternative to API keys involving little additional effort rather than a fully-fledged replacement for identity provider. <\/p>\n\n\n\n
        In my experience, teams often choose API keys to secure Azure Functions. The main reason is simplicity of this technique. Caller includes an API key know to both sides of the communication in its HTTP requests, the Azure Function host verifies that it’s the expected API key and if this verification succeeds, it handles the request.<\/p>\n\n\n\n
        \"\"
        API key authentication<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n
        The important aspect of API key authentication is the fact the API key travels over the wire and, as a result, possibility of the API key getting compromised can not be ruled out. Users with sufficient permissions to read the API key value on the server side may also cause a leak of the key.<\/p>\n\n\n\n
        As opposed to the API key authentication, if client certificates are used, the secret which is the private key in this case is neither sent from to the caller to the Function host nor is it stored in the Function host. Possession of the private key associated with a specific TLS certificate is instead proven by the caller using mutual TLS<\/em> or mTLS<\/strong> in short. This eliminates the possibility of the secret information getting leaked from the Function host. The function host is only aware of the TLS certificates that are permitted to invoke the Functions it hosts. Note plural here, unlike the single API key, multiple client certificates may be pinned <\/em>and trusted by the Function host which allows authenticating and authorizing multiple identities corresponding to individual certificates. <\/p>\n\n\n\n
        \"\"
        Client certificate authentication<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n
        We’re going to show that client certificates allow securing only selected endpoints while keeping the rest of them public, i.e., accessible anonymously. It should be relatively easy to expand this access control and manage access to endpoints per identity. However, this technique is not discussed further in this article.<\/p>\n\n\n\n
        Disadvantages of using client certificates<\/h2>\n\n\n\n
        Identity providers supporting the standard OAuth 2.0 client credentials flow<\/strong> present a more advanced alternative to client certificates featuring higher flexibility, robustness and more fine-grained access control. Identity provider should be the first choice when the set of consumers of the Azure Function is dynamic, meaning that new consumers need to be added and existing consumers need be removed often. Also Identity provider is a no-brainer when the number of consumers is high or when role-base authorization rules are anything but simple. As it has already been pointed out, Identity provider affects complexity which can be an overkill when none of the conditions above holds true. When the set of consumer is small and relatively static, client certificates present an attractive option.<\/p>\n\n\n\n
        Sample code<\/h2>\n\n\n\n
        Visual Studio 2022<\/strong> should be used to follow the sample code. Create a new project using Azure Functions <\/strong>template:<\/p>\n\n\n\n
        \"\"
        Create a new project<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n
        Name new project ClientCertificateAuth<\/strong>:<\/p>\n\n\n\n
        \"\"
        Configure new project<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n
        Select .NET 6.0 Isolated<\/strong> runtime and Anonymous <\/strong>authorization level:<\/p>\n\n\n\n
        \"\"
        Runtime and authorization level<\/strong><\/figcaption><\/figure><\/div>\n\n\n\n
        After Visual Studio creates new project, delete the default source file Function1.cs<\/strong>.<\/p>\n\n\n\n
        In the code below we define two Azure Functions that comprise our service. The first Function named PublicFunction <\/em>should be callable anonymously as indicated by AnonymousAccessAttribute<\/strong>. By default, when this attribute is not applied, the Function is secured using client certificates. Therefore the second function named SecuredFunction<\/em> uses client certificate authentication.<\/p>\n\n\n\n