I am currently trying to get Graph API to work using only the Azure Portal. For example, I can configure Azure AD authentication in my code (example) or I can configure it through the Azure Portal (example).
Is there some way to configure Microsoft Graph through the Azure Portal like in my second example? So effectively, I would not need to write any configuration in my startup class and let the app service itself configure and inject the ITokenAcquisition or, even better, the GraphServiceClient?
The reason I am trying to do this is that I don't really want to deal with handling token caching myself and was wondering if there is a simpler way of doing it.
Related
This is more of an 'Is this possible' question. A developer on the team suggested using Azure AD for user management, but one of the requirements is that the app admin be able to add/manage user access through the application without having to go to the Azure Portal.
So the question is, is the Graph API (or some other mechanism) full featured enough to replace the portal (at least for basic user set up and management) and allow all actions to be done from the application UI?
Thanks.
Simple answer to your question is Yes. Graph API can be used to manage users and their access to applications instead of using Azure Portal. In fact, Azure Portal itself makes use of Graph API to perform these operations.
You may also need to use Azure REST API if you're planning on managing Azure resources as well through this custom application especially Authorization APIs if you want to manage access to Azure resources (Azure Role-based access control) through your application.
I trying to programmatically create an AWS application within Azure AD with SAML identity provider. I have already done everything needed on the AWS side, but am struggling for Azure. I need to create the enterprise application, and then download the Federation Metadata XML file.
I know how to do this through the Azure console, but am trying to automate the process and need to do all of this through code. I have looked into Graph API and terraform, but cannot seem to find the best way to do this, and am looking for suggestions, or if anyone has done this before.
So I found out a pretty decent way to do this using Microsoft Graph API, for anyone interested,
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial
If I look at the Azure activity logs in Azure Portal some of the logs are initiated by Microsoft internal services like "Microsoft Azure Policy Insights". In my application we are getting the Azure activity logs using the Rest API for Activity logs. Is there a way to filter out internally generated logs (initiated by Microsoft Services) from the ones generated by actual users or applications configured in the account? I thought of using caller as a way to differentiate. For users caller has an email address assigned. But the problem with this approach is this approach will filter out any logs for applications as well. Let me if there is any other way to achieve this.
Unfortunately I don't believe there is a way to achieve this scenario.
I am designing an application that will consist of:
SPA written in React, deployed to an instance of Azure App Service
REST API written in .Net Core Web API, deployed to another instance of Azure App Service
Azure SQL Database in the same Azure tenant as the app services above
All these resources will be connected to the same instance of Azure AD (also in the same tenant).
Conceptually, I suppose the authentication could work roughly like this:
The user connection to the SPA and obtains an auth token
The token would then be passed to the API and then the API will use that token to authenticate the user to the SQL Database (this seems possible)
However, I have not been able to find any walkthroughs or other documentation that would demonstrate this seemingly straightforward way of implementing authentication. Seems like this is a typical enough scenario for it to be widely documented by bloggers or Microsoft itself, so not being able to find it makes me wonder if I am not thinking about this right, or maybe I am not looking in the right places.
Can someone please help me figure out what is the right way to approach this and point me to some online resources that could guide me through this?
Thank you!
It's much more common for the REST API to use its Managed Service Identity to obtain a token for Azure SQL Database, and use that. It's always been rare for web apps to use the browser user's identity to connect to SQL Server.
See, eg: Tutorial: Secure Azure SQL Database connection from App Service using a managed identity
I have configured the Azure AD Authentication for my asp.net core project using the services of "Microsoft.AspNetCore.Authentication.*" packages. The project is expected to be deployed to Azure App Service as a Web App.
While I enabled Azure AD authentication, I also see there is an option to enable the same at the Web App level through Application Settings on Azure Portal.
I have question around which option is recommended. I do see when I don't leverage Azure AD authentication configured via nuGet packages, I don't have OpenId connect service plugged into the StartUp.cs file. And I think these services are pivotal in populating the authentication properties like User.Identity.Name. On the other hand with just portal enabled authentication, I don't see this information populated. So, I presume if I want to do further work with logged in user's identity, like leveraging current claims information for authorization, I won't be able to achieve that with portal only authentication.
Your assessment is basically correct. The portal-enabled authentication runs completely outside your application and isn't capable of setting User.Identity.Name when using .NET Core (that level of integration only works with ASP.NET 4.x).
My recommendation is to use the ASP.NET Core NuGet package so you can get the full integration. It's a lot more work to set up, but once you get it working you should be in good shape and get the full end-to-end experience you want.
If you are interested in using the portal-enabled Azure AD authentication support, then take a look at this StackOverflow question to learn how you can get it to work with User.Identity.Name.