New Feature: Azure Active Directory

[TimothyMothra]

Azure Active Directory

Application Insights SDK has a new requirement to support AAD.

• MS Docs: Azure AD authentication for Application Insights
• MS Docs: https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-whatis

Scope of Work

• Configuration
  • TelemetryConfiguration to accept TokenCredential via CredentialEnvelope
  • AspNetCore configuration - this is omitted because these settings should be configurable from a text config file.
• Support AAD in
  • InMemoryChannel
  • ServerTelemetryChannel
    • RetryPolicy via AuthenticationTransmissionPolicy
      • ExponentialBackoff - this is omitted because not helpful for clientside errors.
  • QuickPulseServiceClient
• Token Caching
  • Azure.Identity implementation provides caching for most scenarios.
  • Our own caching - under discussion. Guidance was to rely on Azure.Identity implementation.
• Logging
  • Configuration logging
  • InMemoryChannel
  • ServerTelemetryChannel
  • QuickPulseServiceClient
  • AuthenticationTransmissionPolicy
  • collect Azure.Identity logs - this is cut. The decision is to not take on the task of troubleshooting other products.
• Changelog
  • review changelog for completeness
• Tests
  • investigate adding new E2E tests.
• Outstanding Todos
  • Before Stable release, re-review all changes to the PublicApi
  • After Stable release, update public doc with stable version
  • Transmission.CreateRequestMessage()
    • should we block transmission if token is unavailable?

Requirements

• AAD should be optional for existing customers.
• If AAD is enabled, there will be no backchannels for AAD-less telemetry. Data will be dropped!
• Proper authentication will look like an additional token in all request headers.
  • Services are responsible for validating tokens.
• Application Insights SDK will not be responsible for creating tokens. We will rely on existing work from the Azure SDK
• Affected Endpoints:
  • Ingestion
  • Live Metrics (aka QuickPulse)
  • Profiler (not in this repo)
  • Snapshot (not in this repo)

Implementation Details

OTel Exporters must follow the exact scenarios defined by Azure SDK.
That is, client sdks receive the TokenCredential in the constructor.
This approach is influencing our approach for Application Insights.

For Application Insights, we must support all existing customers to the best of our ability.
Here we're making a best-effort to align with the Azure.Core and Azure.Identity libraries.

TokenCredential

We've been advised by the Azure SDK team to use Azure.Core.TokenCredential. Implementations of TokenCredential will handle the lifecycle of a token (creation, renewal, caching, expiration).

• abstract class Azure.Core.TokenCredential
• full guide on implementation classes: Azure.Identity for dotnet
• example implementation: Azure.Identity.DefaultAzureCredential

TokenCredential defines two methods; GetToken() and GetTokenAsync(). These methods provide the token as a string which will be included in HTTP requests.

Supported Frameworks

• AI SDK: net452, net46, netstandard2.0 source
• Azure.Core: net461, netstandard2.0, net5.0 source nuget
  • contains TokenCredential
• Azure.Identity: netstandard2.0 source nuget
  • contains DefaultAzureCredential

IMPORTANT: Because of the framework mismatch, AI SDK cannot take a direct dependency on Azure.Core. Some reflection will need to be used.

TelemetryConfiguration

An instance of TokenCredential needs to be set on the TelemetryConfiguration and propagated to internal classes.

Code Path

We have three classes that communicate with Azure Monitor services (ingestion and live metrics).

Each class will need to acquire the TokenCredential from the TelemetryConfiguration.
To that end, I'm capturing each class's relationship with TelemetryConfiguration and tracing the call stack where these classes make calls their respective service.

TelemetryConfiguration

Note: TelemetrySink ctor will initialize InMemoryChannel w/ TelemetryConfiguration.

InMemoryChannel.Flush()

• InMemoryTransmitter.Flush() > InMemoryTransmitter.DequeueAndSend() > InMemoryTransmitter.Send()
• Transmission.SendAsync()

ServerTelemetryChannel.Initialize(TelemetryConfiguration)

• ServerTelemetryChannel.Flush()
• TelemetryBuffer.FlushAsync()
• TelemetrySerializer.Serialize()
• Transmitter.Enqueue()
• TransmissionSender.StartSending()
• Transmission.SendAsync()

QuickPulseTelemetryModule.Initialize(TelemetryConfiguration)

• QuickPulseTelemetryModule.CreateStateThread() > QuickPulseTelemetryModule.StateThreadWorker()
• QuickPulseCollectionStateManager.UpdateState()
• QuickPulseServiceClient.SubmitSamples() > QuickPulseServiceClient.SendRequest()

Note: QuickPulse has two endpoints; Ping and SubmitSamples. Both must support AAD.

Logging

Must be able to investigate configuration scenarios.

Should emit Verbose EventSource logs as the Token is set and propagated to internal classes.

Code Examples

Customers will be responsible for creating their instance of TokenCredential

var defaultAzureCredential = new DefaultAzureCredential();

The string token can be retrieved as follows:

var scope = "https://storage.azure.com/.default"; // example from Blob Storage
var tokenRequestContext = new TokenRequestContext(new string[] {scope} );
var accessToken = defaultAzureCredential.GetToken(requestContext: tokenRequestContext, cancellationToken = CancellationToken.None);
string token = accessToken.Token;

[czb182]

What is the benefit of this integration? Protecting data I'm guessing? Anything else?

[TimothyMothra]

@czb182 this is an opt-in feature ensures that only authenticated telemetry is ingested into your Application Insights resource.
There's a little more information here: https://docs.microsoft.com/azure/azure-monitor/app/azure-ad-authentication?tabs=net#configuring-and-enabling-azure-ad-based-authentication

We're in Preview right now, I think there will be a blog post about this feature when it's closer to general availability.