search

Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.36k stars 4.75k forks source link

[FEATURE REQ] Add constructor to allow using custom audience, appId for authenticating with Load Balancing through Azure API Management #44455

Open dawwa opened 4 months ago

dawwa commented 4 months ago

Library name

Azure.AI.OpenAI

Please describe the feature.

Summary This is to request a workaround or a support to be added into the OpenAIClient constructor that will allow to use custom audience, appid, etc.

Background We are using the OpenAIClient to send request to Azure API Management endpoint, which is for load balancing, we are facing a challenge when attempting to switch from Key Credential to MSI Managed Identity Credential for security requirement.

We need construct a client in this way

var client = new OpenAIClient(new Uri("https://MyLoadBalancerEndpoint.azure-api.net/"), MyManagedIdentityCredential);

The current implementation of OpenAIClient is always taking the hard coded AuthorizationScopes azure-sdk-for-net/sdk/openai/Azure.AI.OpenAI/src/Generated/OpenAIClient.cs at 890c9db5ed61de874896781ba91941ebdd42a36f · Azure/azure-sdk-for-net (github.com)

As seen in the code above, the scope used by the passed in tokenCredential is always this hard coded one.

private static readonly string[] AuthorizationScopes = new string[] { "[https://cognitiveservices.azure.com/.default"]

However, the API exposed by the associated AAD App of our load balancer is something like api://myLoadBalancerApp

Explored Options We have 2 options w/o creating custom OpenAIClient

  1. Accept https://cognitiveservices.azure.com/ audience on LB AuthZ check, then use LB's own identity to authenticate to OAI
  2. Pass through token with https://cognitiveservices.azure.com/ audience and let OAI endpoint do authz

Option one is simple, but eventually will allow any user in the corp tenant to call our LB, and the security requirement policy is that we should not assume trust to everyone in the corp tenant.

Option two will require to add all user/app roles to rg where we have oai endpoints deployed, the downsides of this option is that lb will not perform any authorization and will just pass through the request, so if someone will try to ddos us, they will ddos oai endpoints, not lb

Refs

github-actions[bot] commented 4 months ago

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jpalvarezl @trrwilson.

trrwilson commented 3 months ago

Thank you, both for filing here and for the ongoing off-thread discussion to clarify the credential mechanisms being used and the requirements. As you've noted, the transference of TokenCredential configuration into the new client is currently limited and we're actively exploring how we should best apply the Azure.Core authentication constructs to the new client derived from System.ClientModel.

In the interim, it's possible to work around this by manually updating the authentication header values via a custom PipelinePolicy, which is semantically very parallel to the Azure Core equivalent. We'll add more formal documentation for this soon, but as a quick reference, this gist demonstrates a very rudimentary header application to outgoing requests: https://gist.github.com/trrwilson/6c33e9d82bf46c592070aa2961f6eb68