TurnContext.TurnState is missing ClaimsIdentity in streaming scenarios

[stevengum]

Version

4.10.3

Describe the bug

The ClaimsIdentity is not populated in the TurnState for streaming scenarios.

To Reproduce

1. Setup the 24.bot-authentication-msgraph sample
2. Configure Direct Line ASE or Direct Line Speech for the bot
3. Ping the bot via Web Chat
4. Check bot's logs for error, Unable to get the bot AppId from the audience claim.

Expected behavior

The bot should have the ClaimsIdentity available for normal streaming scenarios.

Additional context

There exists a workaround for populating the ClaimsIdentity in a BotFrameworkHttpAdapterBase subclass, which adequately works for Direct Line ASE. However, this route does not support dynamic setting which means it will not work on a bot using multiple Bot Channels Registrations with Direct Line Speech. (e.g. multiple AAD AppIds)

The BotframeworkHttpAdapter should populate the ClaimsIdentity during a successful upgrade for Direct Line Speech.

Direct Line ASE/Single AAD AppId workaround:

    public class AdapterWithErrorHandler : BotFrameworkHttpAdapter
    {
        public AdapterWithErrorHandler(IConfiguration configuration, ILogger<BotFrameworkHttpAdapter> logger, ConversationState conversationState = null)
            : base(configuration, logger)
        {

            // For OAuth + Direct Line ASE scenarios, create and store a ClaimsIdentity with the AppId of the bot.
            var appId = configuration.GetSection(MicrosoftAppCredentials.MicrosoftAppIdKey)?.Value;

            ClaimsIdentity = new ClaimsIdentity(new List<Claim>{
                new Claim(AuthenticationConstants.AudienceClaim, appId)
            });

[xieofxie]

See related #4254

[stevengum]

After speaking with @carlosscastro, because NamedPipe connections don't perform any auth, deriving the AppId of the active bot is undesirable from a security standpoint. Additionally, it could lead to unintended consequences if multiple bots are hosted in one .NET app.

There's no further work to be done on this issue for R11, and instead will be picked up for R12 when the CloudAdapter and BotFrameworkAuthentication induce a reexamination of the streaming implementation.

Removing R11 milestone and P0 label.

---

11/10/2020 Edit (scoped to Direct Line ASE bots)

The developer-provided ClaimsIdentity needs to contain the Bot's AppId that is used for the User OAuth flows. As indicated in my original post, this appId needs to be the value found on the Audience Claim. The ClaimsIdentity with this AudienceClaim will have a pointer set on the TurnContext.TurnState, which is where the BotFrameworkAdapter.CreateOAuthApiClientAsync() will check for the AppId.

Mentioned in this comment, there are no incoming request authentication flows for DL-ASE. (i.e. an Activity sent from the channel arrives and the Adapter authenticates the request)
This means the SDK cannot determine which AppId to use for the User OAuth flow if a BotFrameworkAdapter's ICredentialProvider maintains multiple AppIds.