I want to implement a process along the lines of;
Staff member creates Salesforce Contact
Personalised registration link is sent to client
Client registers for the web application with Azure AD
Client fills in profile information which is stored against the SF Contact
Web application has access to logged in client's profile information
My initial thoughts were to send an identifier for the SF Contact in the registration link which is then attached to the AD user (does AD support custom attributes during signup?). When the user signs into the web app and completes their profile, update the Contact using the Salesforce REST api. Profile data would then also be pulled into the web app as required via the same means.
Is there a better approach to this problem?
Related
In my ASP.NET web app I have added Sign in with Azure button. The project has already got its database to authenticate the user. So from Sign in with Azure button I am getting the email id using Microsoft Graph and then using that email id to create the token for specific user from the database.
The issue is that user can have multiple id registered in Azure AD but only single id is registered in Database. After signing in with id (that is not registered in database) Azure will authenticate the user but its email id won't work because that email id isn't registered in Database. The user will be re-directed to the homepage. But now when we again click on Sign in with Azure button then he's not being asked for different account details but signing in with old credentials again automatically.
You can check this out https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
This will sign-out all the users from Azure AD using the URL above.
Link to the documentation also check this one
I want to develop a custom ASP.NET Web API which can be used to send out emails as a user using the Microsoft Graph API. I think this will be a Multi-tenant application. Below are few ideas I have and some questions:
I have a working ASP.NET MVC web application where different users can login using their unique credentials provided by us.
I have an "Email Setup" section in my web app. Every user will navigate to this section one-time and be redirected to the "https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={{client_id}}&response_type=code&redirect_uri={{redirect_uri}}&response_mode=query&scope=offline_access%20user.read%20mail.read&state=12345"
On the consent screen user will sign in using their Microsoft Office 365 credentials and provide consent to my app.
On providing consent, user will be redirected back to my web app and I will get Access token for the code returned and store the access token in a SQL database.
User navigates to a page to send email, fills in the To, Subject, Body, Attachments etc. and clicks on the "Send" button.
On send button, my ASP.NET web app will call our custom Web API to send the email. The API will have an endpoint that knows the user and will get appropriate access token from the SQL database to send email on that user's behalf.
Questions:
Do I need to register an Azure App with type "Multi-tenant" since I want to support users from different tenants?
What kind of scopes/permissions will be required in order to "Send Email" as the user?
Do I need Delegated/Application permissions on the Azure side?
How can I ensure that the email that is sent, also gets saved to that user's "Sent Items" folder on Outlook?
According to the sending email graph api, we can see it provides the Application api permission, that means you can create an azure ad application and assign the Mail.Send permission to this api and using client credential flow to generate access token to call this api, so it's not necessary to creating a multi-tenant azure ad application via this way.
And certainly, if you insist on auth code flow to generate access token to using delegate permission to call the api, you should creating a multi-tenant application so that users from different tenant can generate access token through this azure ad application.
Kick tires around. We want use Azure B2C for identity management for our web application that embeds PowerBI. PowerBi Embedded and the application are on a separate tenant that is used for our organization. Can this still be done?
You could use Embed content for your customers, also known as App owns Data.
User logs in using Azure B2C
Application back-end will verify user log-in and receive user details
Application back-end should generate embed token. This means that you need to understand how to link a B2C user to a report id / role etc. You can do this in your back-end based on metadata or a table lookup.
You can also include the username and roles if you would like to use Row Level Security (RLS).
I created Azure AD b2c, created user flows and configured with MVC core application. I am using Local Account as Identity Provider. Authentication and sign up is working fine. Some users are signed up and able to access the application. No my requirement is to show all users in AD in my applications users screens so admin can manage/view instead going to azure portal.
To read the users I provided Users.Read.All permission in API permission under my application, also using Graph API to load the users data. I am able to get users data but not email in it.
Can you please let me know if is there any chance to get the users data along with email.
Thanks.
Unable to authorize multiple users for a BOT within the same organization using Azure AD authentication
Following are the steps we tried.
1. Created an office 365 organization, so as to be the admin of the Azure AD
Registered the Azure AD app thru app registrations on Azure in the same Org, and then assigned the permissions to the app to read emails and calendar, by following the URL - https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-authentication?view=azure-bot-service-4.0&tabs=csharp%2Cbot-msgraph-auth
Then created the web app bot under azure
Then under [OAuth Connection Settings] settings of the bot added the Azure AD app details, first added as Azure AD V1.0 with as per the recommendation in the URL of Microsoft
Used the standard template code of the project - BotAuthenticaionMSGraph from the Github sample code repository - https://github.com/microsoft/BotBuilder-Samples/tree/master/samples/csharp_dotnetcore
In the sample code, we just need to edit the appsettings.json file to add the [ConnectionName, MicrosoftAppId, MicrosoftAppPassword]
Then published the local bot code to the app service of the web app bot on Azure
Tested the Bot Auth on the [Test in Web Chat] on Azure -- It works for my Azure AD
Then enabled the Directline Channel for bot and distributed bot to other users of the same organization
The issue is here - when the other user opens the bot, they can see the emails and calendar of the admin user who has already logged in initially. So when the other user logs off and logs in thru his AD credential, then only his emails and calendar data is available since then.
Issue - So, at a given point of time only one user's o365 data is visible globally on the bot chat, and not individual user's data who logs in for that session. The AD token is not per user session but instead its a universal token across for all the conversations.
When I use the Azure AD V2, I get the bad request while trying to login.
Please help. Thanks.
https://github.com/microsoft/BotBuilder-Samples/tree/master/samples/csharp_dotnetcore
used the BotAuthenticaionMSGraph project
Expected is, every user should be able to log in individually, and only his data shud be visible on the bot conversation distinctively.
I have tested the sample code and it works fine for both Azure AD V1 and V2.
I followed Azure AD v2 to configure it. Don't forget to enter Mail.Read Mail.Send openid profile User.Read User.ReadBasic.All for Scopes. It's different from Azure AD V1. Otherwise, it will return 400 bad request while trying to login.
I didn't reproduce the first issue. Could you tell where the other user opens the bot? From "Test in Web Chat"?
Update
You need to be aware that your are dealing with two user identities:
The user’s identity in a channel.
The user’s identity in an identity provider that the bot is
interested in.
See Security considerations. When a bot asks user A in a channel to sign-in to an identity provider P, the sign-in process must assure that user A is the one that signs into P. If another user B is allowed to sign-in, then user A would have access to user B’s resource through the bot.
To enable the protection, you need to configure trusted Origins and tamper-proof user IDs.
You can refer to the sample code.
And this blog Using WebChat with Azure Bot Service’s Authentication provides more detailed infomration.