Although the template generates code for graph api, there is not a simple example or procedure to test the authentication of a brand new generated virtual assistant and then consume this api.
A procedure, an example or configuration to enable the usage of graph client asking for authentication activation, after have the generated yeoman source code for virtual assistant in typescript, and a way with examples to deploy local skills in typescript.
develop a new skill in typescript and use the botskills connect tool to try to see the changes to the virtual assistant solution and see the portions of code changed.
a brand new skill generated has a similar and large portion of the source code of the original virtual assistance generator. To some simple deployment scenarios it is not practical to create a brand new bot solution for just a fragment of functionality of the overall virtual assistant (i.e: when the load of request is not meaningful). So there are some descriptions of parameters of the botskills tool to recognize the local manifest, but does not exists a real one typescript example working with local skills and does not exists an example of skills asking for oauth credentials in typescript.
@andhdo Would a documentation page showing how you can take a Virtual Assistant and add an authentication step prior to calling the Graph be enough for what you need? This would also include the manual configuration steps required to create the authentication connection?
Yes, It could be an initial start point, as a similar way basic examples of authentication does. Then it could be a good complement for local typescript skills development enabling & disabling authentication.
OK - makes sense - I'll update this work item and get the docs updated next week for this. It's come up a few times as you say it's useful to do authentication purely within VA and not rely on Skills for some scenarios.
The foundation is covered here and I'll focus it down for VA (and it will be much simpler than this)
https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-authentication?view=azure-bot-service-4.0&tabs=aadv1%2Ccsharp%2Cbot-oauth
Yes; i've made the exercise to run this scenarios, but the idea is to implement it the best way inside virtual assistant without duplicate the code already made by Microsoft.
Thanks for your help, and hope to see the result.
Hi @andhdo, this doc should cover what you need: https://github.com/microsoft/botframework-solutions/blob/next/docs/reference/skills/manualauthsteps.md
Reopen if needed.
Hi @andhdo, this doc should cover what you need: https://github.com/microsoft/botframework-solutions/blob/next/docs/reference/skills/manualauthsteps.md
Reopen if needed.
Hi @lauren-mills, Would you mind to tell us How can i reopen this issue?
that because:
The steps to add authentication directly to VA should be the same as the steps to add them to a skill as listed in the document (hence why I pointed you to it.)
I want to confirm that you are making all these changes to the VA Bot registration, and the VA app registration, correct?
Can you go into the bot registration, in the settings tab, then select your OAuth connection and click "test connection" at the top and let me know what it says? Thanks.
Yes; all according the procedure. see below the executed steps:
install all requirements to run VA scaffold:
npm uninstall -g yo
npm install -g yo
npm install -g windows-build-tools
npm install -g npm
npm install -g botdispatch
npm install -g ludown luis-apis qnamaker [email protected]
npm install -g chatdown
npm install -g botskills
npm uninstall -g generator-botbuilder-assistant
# select the following line according release or development versions you want to run. see https://github.com/microsoft/botframework-solutions#user-content-js table for versions
npm install -g generator-botbuilder-assistant
yo botbuilder-assistant --assistantName "bot-1835" --assistantDesc "my assistant" --assistantLang "es,en" --assistantGenerationPath "." --noPrompt
then the generation started and build process immediate after it.
then correct issues if needed to run applictions runs locally
-> index.ts: omit credentials parameter return new MultiProviderAuthDialog(oauthConnections) in development, master version;
-> index.ts: change skill.msaAppId by skill.msAppId in development, master version
-> add msAppId and attributes to skills.json file.
-> ignore resources autogenerated in the build process by the bot-builder-tools (who manages the cognitive models)
provision the components in azure:
taking care that you dont have any components who enters in conflict with the provisioned as a code (delete previous resource groups, azure-ad-registrations and luis.ai models with same identifier using the console or command line tools).
first, you need to establish the connection with azure, and choosing a subscription with money (because all is money in az)
az login
az account set --subscription <SUBSCRIPTION_TO_WORK>
and then executing the generated script
cd bot-1835
.\deployment\scripts\deploy.ps1 -languages "es-es" -name "<VA_NAME>" -location "westus" -appPassword "<VA_PASS>" -luisAuthoringRegion "westus" -luisAuthoringKey "<LUIS_AUTHORING_KEY>" -parametersFile ".\deployment\resources\parameters.template.json" -debug
VA_NAME:
VA_PASS:
LUIS_AUTHORING_KEY: from
after that (and crossing the fingers to all become succesful), then you can start lowering the level of the resources that are expensive for the subscription
output loks like that:
> Creating resource group ...
> Validating Azure deployment ...
> Deploying Azure services (this could take a while)...
> Updating appsettings.json ...
> Deploying cognitive models ...
> Initializing dispatch model ...
> Parsing general LU file ...
> Deploying general LUIS app ...
> Setting LUIS subscription key ...
> Adding general app to dispatch model ...
> Parsing chitchat LU file ...
> Deploying chitchat QnA kb ...
> Adding chitchat kb to dispatch model ...
> Parsing faq LU file ...
> Deploying faq QnA kb ...
> Adding faq kb to dispatch model ...
> Creating dispatch model...
> Setting LUIS subscription key ...
+ To publish your bot, run 'C:\MyPathToDir\bot-1835\deployment\scripts\publish.ps1 -name 1835-dev1 -resourceGroup 1835-dev1 -projFolder "C:\MyPathToDir\bot-1835\src '
> Done.
npm run start
$appReg2 = (az ad app create --display-name "<VA_AZADREG_NAME>" --password "<VA_AZADREG_PASS>" --available-to-other-tenants false --reply-urls "https://token.botframework.com/.auth/web/redirect")
$appReg2json = ($appReg2 | ConvertFrom-Json)
VA_AZADREG_NAME=
VA_AZADREG_PASS=
then add graph api permissions
profile
Mail.Read
Mail.Send
User.Read
User.ReadBasic.All
and
ClientSecret:
use thinfo of the previous step to update oauth in botchannels-registration generated
then test the connetion
(it asks for oauth claims) and then shows the token
It seems like you have the authentication setup on your Virtual Assistant project. What are you missing that you would like our help with?
Despite the configuration made, the project never requests for authentication to the user using VA. I've already added the authentication for the project but it would never activates the dialogs for authentication. I've already added the authentication for the project but it never activates the dialogs for authentication
additional steps made in the application according documentation and errors seen in kudu:
{
"oauthConnections": [
{
"name": "Outlook",
"provider": "Azure Active Directory v2"
}
], ...
"local:start": "npm run build && node ./lib/index.js NODE_ENV=development",
"start": "node ./lib/index.js",
npm run clean
npm run build
.\deployment\scripts\publish.ps1 -name <VA_NAME> -resourceGroup <VA_NAME>
To prompt for authentication, you will need to add an OAuthPrompt into your dialog at the desired place, providing the connection information when you configure it.
This sample dialog from the Microsoft/botbuilder-samples repo should help: https://github.com/microsoft/BotBuilder-Samples/blob/master/samples/javascript_nodejs/18.bot-authentication/dialogs/mainDialog.js
This is a good clarification because the method really does not add authentication to your bot, you must do some additional steps to secure your actions:
Some additional questions:
MultiProviderAuthDialog already created that works with the skills in the method buildAuthDialog at index.ts is not used for any purpose .The OAuthPrompt will automatically retrieve a token for a user if they've already logged in elsewhere for that OAuth connection. If you add the OAuthPrompt in where you want it, and the user has already logged in, it will just continue with the next step.
I'm not sure what you're asking here. You shouldn't need a user to authenticate to use Cognitive Services (LUIS, QnA, etc). You just need the key for that service. Please clarify this question for me.
The MultiProviderAuthDialog registration in startup is only created for configured skills in your skills.json config. If there are no skills, it is not used.
2: I mean: if exists (don't know if already exists or is it planned) a Middleware to ask for authentication credentials to the user before bring access to execute the maindialog requests logic, so you can let this logic intact
I think that I've found a solution according your comments:
create a kind of circuitBreaker dialog: a waterfall dialog of 2 steps: an authentication step and main step. first step calls the loginActivityDialog and the second one, calls the previously generated main dialog only if oauthPrompt has generated a token.
in index.ts do something similar to the buildAuthDialog logic, to get oauthConnection configuration from settings and bypass to LoginActivityDialog
/* eslint-disable */
function buildAuthDialog2(settings: Partial<IBotSettings>): LoginActivityDialog|undefined {
const oauthConnections: IOAuthConnection[] | undefined = botSettings.oauthConnections;
if(oauthConnections!==undefined) {
const loginDialog = new LoginActivityDialog(oauthConnections);
console.log(`created`);
return loginDialog;
} else {
throw new Error(`You must configure at least one supported OAuth connection to use authentication`);
}
return undefined;
};
/* eslint-enable */
this is the less invasive method i've found untill now; however it lacks of 2 things: (1) it couldn't propagate the token to call graph if needed. (2) it's not the original middleware i thought
Glad to hear you were able to get the prompt working. For accessing the token, it should be available in the next step (after the OAuthPrompt) in stepContext.Result.
If you would like some advice on creating the Middleware you want, I would suggest going to our Stack Overflow, since it is better for general bot advice than this repo.