I have created a bot that is going to sit on a public website. At the moment, I am simply pasting the iframe snippet with the Secret key that was generated by the bot framework on to the page. I am a bit concerned about making the secret key public. I understand that any developer will be able to embed the bot anywhere they like. What else can they do with the secret key? Are they able to use the secret key to view other conversations with users?
What are all the advantages of using the token instead.
I have read through the following documentation:
https://learn.microsoft.com/en-us/bot-framework/channel-connect-webchat
Thanks!
Related
I am implementing a login flow which uses the Google Client ID and Google Client Secret. I am considering the security implications of the Google Client Secret and who should be able to have access to it.
Currently the Client secret is stored in an environment variable, but I would like to know what someone with access to this secret could do with it to determine which developers should have access to this environment variable and if I should setup a different OAuth2 application in development vs production.
Client id and client secret are similar to a login and password. They give your application the ability to request consent of a user to access their data. If you are storing refresh tokens it would also give the user access to create access tokens from your refresh tokens.
Googles TOS states
Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.
You should not be sharing this with anyone. It should only be used by you and your developers.
Yes Ideally you should have a test and production client ids. Test client id can be used by your developers the only one who should be using your production verified project client ids is your production environment. I would store them in some for for secrete store personally.
It depends on which type of OAuth application you specified.
When creating an OAuth client ID in Google Cloud (and with that, a client secret), you are asked to specify the type of application you are creating:
If you choose Web App, your client secret should really be secret, as its treated as such by Google and is used to authenticate your own server. You should therefore hide it and especially not include it in open sourced code.
However, there is also the option of creating a Desktop app, which means you want to use OAuth without having your own server. For this case the documentation by Google says:
The process results in a client ID and, in some cases, a client
secret, which you embed in the source code of your application. (In
this context, the client secret is obviously not treated as a secret.)
So in this case it's fine (even required) to include the client secret in your app for your users.
I have a Bot published from Bot Composer into Azure. The bot is a simple QnA Bot. I need to securely embed it within a webpage. The iframe embed code generated has the Bot Key embedded in the URL. How do I secure this so
users cant see the Key,
limit access to users from my tenant?
Thanks in advance.
Generally speaking, if you want to hide something from the end user, you need to place it somewhere where they do not have access to. Normally, you create some kind of script that is running in the backend of your webpage and deals with creating the tokens with your secret key. These "non-critical" tokens need be to be passed to your Web Chat.
The limitation to your tenant user, you need to implement an authentication system.
I have my bot ready and working with Direct Line Secret in WebChat (by passing &s=SECRET in URL) and on other channels.
I am interested in the integration of front-end Custom Chat Application using Direct Line ClientJS (link at bottom).
After going through the documentation on Bot Framework I came to know that it can be done in 2 ways:
Pass Direct Line secret from front-end Chat Application in ClientJS
Passing Token from front-end Chat Application (But, this requires Direct Line Secret to be passed to generate token first time)
As I develop bots for my clients with their respective use-cases which
need to be kept private with client servers.
So, anybody having Direct Line Secret can easily obtain Bots Logic (i.e Not actual code, but what answer bot replies to particular question) by just passing that Direct Line secret in Microsoft Bot Framework provided WebChat client (by passing s=SECRET in URL)
So, basically, how do I hide the secret from others?
Direct Line Client : https://github.com/Microsoft/BotBuilder-Samples/tree/master/Node/core-DirectLine
Authentication Mechanism : https://learn.microsoft.com/en-us/bot-framework/rest-api/bot-framework-rest-direct-line-3-0-authentication
Programming Languages:
FrontEnd - Angular.js with Typescript
Backend - Node.js on Heroku
You need to follow method #2 as described in the section Generate a Direct Line Token. Then you won't have to use the secret in your WebChat page at all.
A Direct Line token is a key that can be used to access a single conversation. A token expires but can be refreshed.
This way your client will use the generated token on a per-conversation basis, and there's no need to embed the secret in the WebChat page. Also when you are using the token it will expire, so you have additional security there as well.
Indeed, you you need put the secret altogether for direct line but there are ways you can handle in you bot code to avoid using to other people.
Follow the below steps:
1) you can pass the domain where you want to implement with user login context.
2) login context will go in bot code and will be check server side that the user which is logged in having authorized to access or to use your chat bot.
3) Restrict your bot to that particular domain.
4) Check authentication in bot using sign in feature via card.
I hope above liners will help you.
do let me know in case you need more help.
I'm using the express-stormpath package with a new application I've created in my account at Stormpath.com.
I use stormpath in my app I have to provide an application HREF provided in the application page in the stormpath admin, I also have to provide a API Key and Secret.
I've been creating a new API key/secret for every app I've made on the one admin tenant assigned to the account, the one I signed up with.
And I use that API key/secret to authorize my express application with Stormpath.
So in my admin account I have a long list of API Keys and I have no idea which key is for which app.
Is this how I should be doing it?
It just feels very messy. I see that normal application users can be given API keys/secrets, what are these for? Can I create an admin users for each app and use their API keys and secrets without making them a stormpath administrator?
Does that make sense? I've tried emailing the support directly.. but they didn't really understand any of this. :/
First of all, this is a great question, so I’m not sure why you’re being down voted. API keys can be a confusing topic. I’ll try to clear up the mystery around them before answering your specific questions.
In Stormpath, there’s two types of API keys: Tenant API keys, and Account API keys. Tenant API keys are what you need in order to make API calls to Stormpath. They identify you as an administrator of your Stormpath Tenant, and give you full read/write access to all of your Tenant’s data (in other words, anything and everything you’ve stored in Stormpath). By definition, an administrator has access to the Stormpath API and the Admin Console (aka the webpage you see when you log into Stormpath).
There’s also the notion of Account API keys. Accounts are people (or devices) that are signing up to use your web app, mobile app, or API service. In Stormpath, Accounts are stored in Directories, which in turn are stored in Applications. You can read all about this here. I like to think of Account API keys as a more secure version of a username and password. They’re really useful if you’re building out your own API service and want users to authenticate before they start making requests to your API.
That’s really all there is to it. API keys authenticate you — nothing more, nothing less. There’s tons of articles out there debating whether or not API keys are more secure than other methods, so you’re free to check those out. But in Stormpath, in order to communicate with our API, you must identify yourself as a Stormpath Tenant administrator. As you build out your own web app, mobile app, or API service, you can choose how you want your users to interact with your services.
I hope this helps clear things up.
If you want to create any other type of roles/permissions for your users, you’ll need to learn about authorization and how it works in Stormpath. I won’t elaborate on that here, but you can read all about it in our docs.
so far I've not been able to get this working with the bot framework. I spent all day but only managed to get .net api example (https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet) working with AD B2C. I'm not sure where it grabs the bearer token that I want to pass to BotUserData...
I've tried following https://azure.microsoft.com/en-us/blog/bot-framework-made-better-with-azure/
but in reality the solution does not build successfully and I've resorted to just taking code from there and into my bot framework sample template....however, when it asks me to login through MS and I do, I am not able to proceed and it doesn't seem like that blog is using the AD B2C policies.
so how do you integrate AD B2C with Bot Framework? Is it possible to call /Account/SignIn URL from bot framework to authenticate the user? Afterwards, how would you capture the token and pass it to BotUserData?
You might want to take a look to the Facebook Auth sample to get an idea of a potential flow for the Auth scenario. For Azure AD, you need to do a similar flow.
Let's say your user send a "Login" message to your bot. The bot should respond with an auth URL and ask the user to login to the service using that URL. You can use the GetAuthorizationRequestURL method of ADAL for that.
Then you will have a Web API which will basically expose an endpoint that will be the reply URL of Azure AD. Once the users completes the login, a message will be posted to your Web API where you will be able to get the authorization code and perform the calls to get the Access Token. After that, you can just do the same they are doing in the Facebook Sample Web API which involves resuming the conversation with the Bot, sending a message with the access token (so it can be persisted in the PerUserInConversationData bag (check this line of code).
After that you have the access token available to perform any call that requires an access token.
Update
There are two new samples that you might want to take a look since they are implementing the workflow being discussed.
GraphBot from the BotBuilder repo.
AuthBot from Mat Velloso
Hope this helps.
Follow this tutorial for Bot side code development, i focus on configuration at B2C and Azure level here:
OAuth Connection
Client id
This is taken from the Application ID field in your B2C app's properties. It's the equivalent of a Microsoft app ID taken from any other AAD app registration.
Client secret
This is generated using the steps in this tutorial.
Select Keys and then click Generate key.
Select Save to view the key. Make note of the App key value. You use the value as the application secret in your application's code.
Use AAD V2 configuration in oAuth settings in bot channel registration - new oauth connection settings.
Fill the above details by following the steps and values we got from them.
Authorization/Token/Refresh URL
I followed on this one with
https://login.microsoftonline.com/tfp///oauth2/v2.0/authorize
for the Authorization URL and
https://login.microsoftonline.com/tfp///oauth2/v2.0/token
for the Token and Refresh URL's.
For I used the URL format (kyleorg.onmicrosoft.com) rather than the GUID format, but using the GUID also seems to work.
is the name of a user flow, like B2C_1_userflow. I created one with this tutorial.
Scopes
Using the scopes openid offline_access I am able to sign in successfully, but to my astonishment the token returned is empty.
Then I found this document which suggests using the client ID itself as a scope.
When I reuse the value from the Client id field in my Scopes field, a token is returned successfully and my bot is able to use the connection.
You can combine this with other scopes as needed, but for the sake of experimentation I highly recommend getting the simplest implementation to work first.
Let me know if these instructions work, and if they don't then we'll see if the difference lies in how we've set up our B2C apps.
As a bonus, I should mention that after you get a token you can paste it into https://jwt.ms/ to decode it and see if it recognized your B2C user correctly. Always refresh the page when pasting a new token to make sure it doesn't keep showing you the information from the last token.
Referred this document.