My chatbot with Microsofts Bot Framework is online and working. It has an API, which is sadly publicly accessible.
But it shouldnt! The API should be secured and only accessible for Microsoft Accounts of my Tenant.
But most of the time the API is accessed by scripts.
Whats the best way to secure?
What is comfortable?
Like other public APIs, your API (your bot) needs to implement some form of user auth in order to validate authorized requests and reject unauthorized requests. Take a look at this sample (the C# version is linked, but the repo has samples in other languages) to see how you can implement user auth using the Microsoft Graph API. In addition to auth, Graph will also allow you to get info about the user, such as their Tenant ID (assuming your user logs-in and grants your bot permission). You can then implement whatever access controls are appropriate for your scenario.
Related
I have created a Microsoft Teams bot built using a Golang port of the Bot Framework. It is a multi tenant bot which lives in my infrastructure.
It is easy to add the bot as a "Teams Application" by selecting it from the marketplace (for free), however, to function correctly it needs additional Microsoft Graph permissions. Specifically read the title of a MS Teams Channel / Group Chat.
This seems to be a challenge for users as almost no one - even those 'in IT' seem able to correctly add the permissions required, even with documentation.
I've been helping them personally but it's not a commercial product so not viable in the long term.
I would like to find an OAuth2 flow which would allow a privileged user to authenticate with their Azure tentant and grant the necessary privileges for my application to do it's thing. Or, alternatively create the client registration in advance of installing the bot.
Every OAuth2 flow requires me to have (or know) my client_id before making the request. Given it's in the users Tenant, I don't have access to it; the users can authenticate against their Azure AD tenant though, so they must receive a bearer token which would allow them access to create or update permissions on an Azure Application.
There is chance to use the OAuth 2.0 client credentials. This grant is specified in RFC 6749. This grant is to access the web hosted resources. This resource will directly identify the application based on the identity of the application. In server-to-server communication we can use OAuth 2.0. This can be referred as "Service accounts" or "Daemons".
Microsoft identity platform and the OAuth 2.0 client credentials flow
I have a collection of static html files, I would like to share with clients signed into my Azure AD B2C.
What would be the best method of doing so?
Ideally, the solution could also read certain claims from the token and decide which html files the client is authorized to access.
My Azure AD B2C is configured in a way, where only legitimate customers can get accounts.
I would now want to grant them access to the documentation of the products they own.
These are provided in the Token as a string Array.
The best way I can think of to do this is to create a lightweight Azure App Service that can handle the authorization piece and control role-based access by directory for the static files. As stated by Hari Krishna, you're going to need some form of Javascript platform for retrieving an access token using the Auth code w/ PKCE flow. Once you have an access token, App Service can control access to your directory based on the user's role present on the token.
For your scenario the most supported scenario will be Auth code PKCE flow. Which is helps you to authenticate with the help of any JavaScript platform and no backend programming is required. Also, Make sure each page is authenticated since , this flow is designed for single page application.
I want to develop a SaaS application on Azure and deploy to the Azure marketplace. This app will be able to obtain information about the user's network. (for instance VNET information). Ideally I would like to have a single-page application that would authenticate with the user who subscribed to the app, and then make calls on a backend API tier, which would make calls to Azure management API endpoints.
The Azure docs layout a number of scenarios of how apps could interface with AD. how-to guides
I believe what im trying to do most closely matches the "Build a web app that calls web APIs" flow, which is an example of OBO. My question is, is that really describing what im doing? Is "calls web APIs" really an example of invoking APIs on the microsoft azure platform?
So my understanding is that I would develop my own API app, that would accept requests from my client browser code, which would contain an oauth token, and then the API layer would derive another token to pass onto the Azure API layer?
Im trying to keep the architecture as simple as possible, but im afraid I may be misinterpreting the Azure docs.
OBO (On-Behalf-Of) allows you to exchange an access token that your API received for an access token to another API.
The important bit is that the access token must have been acquired in the context of the user and must contain user information.
The new access token will then also contain this user's info.
So it allows your back-end API to call Azure Management APIs on behalf of the current user.
This means your API can't do anything the current user can't do.
It is limited to the user's own access rights.
The other option for authentication is to use client credentials authentication,
where your back-end API uses only a client id + certificate/secret to authenticate.
In this case the token will not contain user information.
To enable this approach, the target organization's users would have to assign RBAC access rights to your app's service principal, so it can act by itself.
You could also build a flow in your app where you setup these RBAC accesses on behalf of the current user.
Personally, I would prefer to use delegated access (OBO) whenever possible, as it will block the user from doing things they cannot do.
Though on the other hand, service principal-based access allows the organization to control your app's access better.
My application uses Azure AD and OpenID Connect to sign-in users (see https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect).
I want to be able to list users' Azure subscriptions when they've signed-in. I cannot figure what I need to do after a user has successfully signed-in and they've been redirected back to my app, i.e. how/where I get a hold of the necessary access token or credentials, and, to be honest, which is the correct API to call with said token/credentials. Can this be done? Is an entirely different approach necessary?
Look through the code in the example for an instance of AuthenticationResult. The access token can be accessed at AuthenticationResult.AccessToken and you can decide what you want to do based off that.
One of the notification events (raised as part of the sign-in flow) receives an authorization code. With the code, I was able to acquire an access token (using AuthenticationContext.AcquireTokenByAuthorizationCode) and, with that, I was able retrieve the subscriptions using this API https://management.azure.com/subscriptions. Note: ensure your AD application delegates permissions to the Service Management API.
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.