ISO clarification+answers to modern bot template with user defined MSI's + SSO

[andrewconnell]

The July'24 update of the TTK for VSC announced the switch to using user-assigned managed identities for bots when deployed to Microsoft Azure.

Cool... I'd much rather use managed identities in production!

But...

I can't find any further details on this in the BotFW / Teams / TTK context... just the link to MSI's in the announcement. I've scoured the popular sample repos (Microsoft-Teams-Samples, teams-dev-samples, & TeamsFx-Samples) with no luck... I'm trying to answer the following questions, but without samples or further docs (that may exist but I haven't found yet), I'm struggling with this...

1. Dev => prod story - the bot template for a simple command mixes auth configurations.
   • For instance, the bot auth code uses an Entra ID app with the client ID & secret... not the UserAssignedMSI...
   • but the Azure Bicep deployment files only use UserAssignedMSI...
   • How is that supposed to work... the bot is coded to use single/multi-tenant (MicrosoftAppType) authenticating with an AAD app, but in production, it uses the MSI...
   • 🙋‍♂️ Q1: Are you just supposed to create an AAD app for your bot that you ONLY use while developing your bot locally, but when you publish to prod, when you set the bot type (MicrosoftAppType) to UserAssignedMSI, you can delete your "development AAD APP" & the BotFW SDK just ignores the password and magically auths to connect to the bot resource?
2. SSO - let's say you have a bot & implementing SSO... set aside the above question for now...
   • 🙋‍♂️ Q2: am I correct in understanding you will STILL need the Entra ID app where you define the scopes and preconsent clients just like you do with a web-based SSO implementation (ignoring NAA for now)?
   • 🙋‍♂️ Q3: so... in prod if you're using the user-assigned MSI, you'll still have an Entra ID application & you need to configure the OAuth2 connection settings on the bot to auth with that Entra ID application, correct?

[therealjohn]

Hi @andrewconnell

Q1: I think some of our templates/samples are missing some config and need updated - which one are you testing with?

Our templates should have been updated to set the app type as an env var and an action in the YML specifies it:

const config = {
  MicrosoftAppId: process.env.BOT_ID,
  MicrosoftAppType: process.env.BOT_TYPE,
  MicrosoftAppTenantId: process.env.BOT_TENANT_ID,
  MicrosoftAppPassword: process.env.BOT_PASSWORD,
};
...
teamsapp.local.yml
  # Generate runtime environment variables
  - uses: file/createOrUpdateEnvironmentFile
    with:
      target: ./.localConfigs
      envs:
        BOT_ID: ${{BOT_ID}}
        BOT_PASSWORD: ${{SECRET_BOT_PASSWORD}}
        BOT_TYPE: 'MultiTenant'
...

But for remote environments, in the azure.bicep its set like this:

When the type is UserAssignedMSI, the BF SDK is not going to require a password (client secret).

You can't F5 / debug with Managed Identities, so the local environment still uses Client ID / Client Secret with an Entra ID App.

Q2: Yes
Q3: Yes

[andrewconnell]

Thanks @therealjohn! I was spinning on Q1 for a few days... now I realize I was chasing a unicorn.

[andrewconnell]

Sorry... missed these questions...

@therealjohn said:

Q1: I think some of our templates/samples are missing some config and need updated - which one are you testing with?

The Bot > Chat Command template... it does have the changes in the Bicep files.

To the best of my knowledge, none of the templates contain an SSO example (unlike the tab template Tab > React with Fluent UI).

[therealjohn]

Take a look at this sample: https://github.com/OfficeDev/teams-toolkit-samples/tree/dev/bot-sso

[andrewconnell]

@therealjohn said:

Take a look at this sample: https://github.com/OfficeDev/teams-toolkit-samples/tree/dev/bot-sso

Thanks for sharing this sample... I've been poking through it and other pieces... but I'm still very confused what Microsoft recommends for Bot SSO.

To be clear, I understand the questions in my OP thanks to your response, but what follows are more general bot SSO "what are you supposed to do? questions... I thought I got it, but the sample you shared is now making me question other fundamental things...

There are multiple bot samples across various MSFT repos and all seem to implement bot SSO in a different way, some use the BF token cache (like this one), some don't (like the sample you shared).

What I'm struggling with right now: the sample you share doesn't seem to use the OAuth2 connection configuration within the bot registration, rather it seems to always get a new token rather than relying on the Bot Framework token cache (unless I'm missing something).

I looked at the implementation of the TeamsBotSsoPrompt from the @microsoft/teamsfx package... it seems to hard code ignoring the use of the BF token cache...

Yet the docs walk you through doing a completely different SSO configuration, configuring the CloudAdapter with the Teams SSO token middleware from the BF SDK... and that uses the token cache. The sample you shared doesn't do that extra step..

Is it as simple as "Well, you can just add that if you want to use the BF token cache... use the sample I shared, but when you configure the CloudAdapter, just add the extra stuff to use the token middleware that will use the BF token cache like this sample does)

I can't find any explanation of the usage for the TeamsBotSsoPrompt in the Teams Dev docs... only API references...

So this is VERY hard to understand what you're supposed to do. It's very confusing even for someone (ie: me) who understands how Teams bot SSO works...

My understanding is that in production, you WANT to use the BF's token cache via the connection you create in the bot registration in the Azure AI Bot Service... right?

If so, then the sample you referenced seems to ignore it... unless I'm missing something... because it doesn't reference the connection name anywhere.

Can you understand the confusion? Maybe help un-confuse me?

[Benjiiim]

I do love the move to managed identities in production as well. And I do like that it will help democratizing the good practice of having two App Registrations (one to secure the communication with the bot service and the other one for user authentication/SSO). As most of the samples and even the official documentation is still using a single App Registration, that won't be an easy move...
If I may add an additional question, is it safe to use MSI for the bot App Registration (not the SSO App Registration) even in a Multi-tenant configuration (ISVs/Startups targeting the Teams Store for example) or is it only a Single-tenant thing?
I'm asking as it is confusing for me that we have to choose between these three values for the bot App Type: UserAssignedMSI, SingleTenant or MultiTenant and the Bot Service documentation is not clear on this point.