I've done some reading in regards to Azure AD, but I still can't wrap my head around it. The confusion might be there also because of how my company tries to standarize how a azure project should look like.
Imagine I have two things: SPA app (served by App Service) and API (on this App Service, ASP.NET). The approach that the company is suggesting is that both of those should have their App Registrations.
Now, I'd like the API to have access to Ms Graph. In order to do that, looking at other projects, I updated my AppRegistration to request for Ms Graph roles, Admin gave consent, and in API I used ConfidentialClient to reuse my Client Id/Secret to get token and then access MsGraph.
Why the hustle? Why not just use Managed Identity of my API and grant needed permissions using New-AzureAdServiceAppRoleAssignment?
Why do I need App Registration here? Do I need both? Should I access Ms Graph using my App Registration and confidential client in my API? How does my App Service relate to my App Registration in code?
Let's take a step back and define a few things that will make things easy to understand:
Your app service: this is just a compute environment, just as Azure Functions, Logic apps or VMs. This is where your code executes.
Azure AD App registration: this is an identity that you can use in your code to identify your service and get access to resources you need. The Azure AD app registration has several capabilities:
build an app in one tenant and used in multiple tenants (multi-tenant app)
consent framework, allowing you to request permissions and the owner to grant it
define roles and permissions, so that you can configure who is allowed to call your API
3-legged OAuth flows which allows you to act on behalf of the user
confidential client flows which allow the app to act on its own (like a service account)
Azure Managed Identities: this is also an identity that you can use to identify your service and get access to resources you need. It only has a subset of the capabilities of Azure AD app.
confidential client flow which allows the identity to act on its own (like a service account)
credentials managed for you by the platform
Depending on what you are trying to do, you can use one or the other identity: rarely if ever you will need both.
In your case, you need an identity to act on its own. So either app registration or managed identity will work. Your API may benefit from using an app registration if you want to define roles and permissions. The primary advantage of using an app registration in your scenario is that the consent model is simpler to use and understand. The disadvantage is that you need to manage credentials for the app. This pro/con is reversed when using a managed identity.
You don’t need both at a time. These are two ways to get the access of MS graph for your API. They are used for different purpose.
Managed Identity (Using System Identity)
· Use the Managed Identity if you don’t require your API to be authenticate from any provider.
· A managed identity from Azure Active Directory allows App Service to access resources through role-based access control (RBAC), without requiring app credentials
· It known as safe way to give your web app access to data is to use a system-assigned managed identity
· Currently, there's no option to assign any permissions(MS graph) through the Azure portal for Managed Identity
· When we do Manged Identity of any application its show only for Enterprise application.
Reference : Tutorial - Web app accesses Microsoft Graph as the app - Azure App Service | Microsoft Docs
App Registration.
· To set the authentication and authorization of your app from different provider its need your app registration id.
· It’s required to configure a service and get a token from the Microsoft identity platform endpoint that service can use to call Microsoft Graph under its own identity.
·In this using portal you can add permission (MS Graph) for your application.
Reference : https://learn.microsoft.com/en-us/graph/auth-v2-service
Related
I am wondering if it is possible to restrict access to an azure web app (it is functioning as an api, so I dont want public access just via the url) to API Manager through managed identity? Everything I can see is for using Azure HTTP Functions, not to a web app
Im assuming by doing so that users in the AD can also access the web app directly?
Yes, it is possible.
Your back-end API will need to check for either:
An application permission (appRole) defined on the API app registration and assigned to the Managed Identity through PowerShell
Or check that the object id in the token matches the Managed Identity
In the first option, other apps won't be able to use the API directly unless that permission is granted to that client application by an Application Admin/Global Admin.
The second option outright prevents other apps from using the API directly.
In both cases, you'll have the API Management policy get an access token targeting your API app registration.
I am new to D365/PowerApps and wonder if i have a Azure Service, (Azure Functions or WebAPP) that is secured with Azure AD tokens (App Registrations).
Can I get an Access Token to my external services using Azure AD from within a plugin step in d365? How do I get such token on behalf of the context the plugin when running as a user.
You'll need to use Flow and compose a http request to get the token:
https://flow.microsoft.com/en-us/galleries/public/templates/edfa8fde25644f149448c8d8cff44699/call-a-web-service-from-a-powerapp/
Here's a good explanation on how to do it using the REST API:
https://stackoverflow.com/a/36982924/1384539
If I understand your question correct,
You have an Azure function APP or external azure service and that is secured by creating Azure AD App with it's roles delegation and so on.
Now you need Access token for this Azure APP with client ID and Client Secret.
We had this similar thing in Dynamics 365 i.e When we wish to use Dynamics 365 Webapi, We need to create Azure AD App and then provide roles delegation so that this app will have access to Dynamics 365.
In Plugin we can give details with client Id and Secret and then generate Token which will be used for Furthure process during plugin Execution.
Note: Most of these plugins we run under System context.
Here are few examples which will lead you to your desired direction.
Most of the Examples also talk about creating Non-Interactive user in Dynamics but in your case that shall not be needed because you are not communicating with Dynamics via (Azure AD App) rather you communicate with Azure functions or so on.
Link 1
Link 2
Link 3
We are working on WEB APIs and want to integrate Azure AD for AuthN and AuthZ. We have successfully integrated the same. We have created enterprise applications, custom roles, assigned users for the same.
Now we need to allow access to APIs with AWS like keys (Secret / Access keys). Individual user can generate their own keys and store those in Azure AD so that when those keys are used, user can be authenticated.
I didn't find any way to achieve this using Azure AD. Any suggestions around same are welcome.
Meanwhile I have gone through custom store for keys. Please refer link : https://www.codeproject.com/Articles/1228892/Securing-ASP-NET-CORE-Web-API-using-Custom-API-Key
Thanks in advance.
Azure AD authentication uses tokens.
So any app wishing to call your API must authenticate with AAD and acquire a token for the API.
If these users are making apps within your organisation, then they can register their app in your AAD and require access to your API. They will create and manage their own keys.
If on the other hand these users are making an app for another organisation, you'll have to make your API a multi-tenant app.
And you'll need to have an on-boarding page in your API through which you will redirect their admin/user to the AAD login page, where they will consent to any permissions your API requires.
After this a service principal is created in their tenant.
Then they can register their client apps and require access to your API.
They will have full control which permissions they want to assign to each app, what roles to give to users etc. But of course the tokens will contain their tenant id so you can filter access on that.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas
Is it possible to gain access to the Azure Management APIs through the client ID and secret for a web app?
I have a web app through which i want to be able to manage Azure. I want to do this using the credentials of the application itself so that the current user does not have to be an azure administrator.
I have given the web app the necessary role on my subscriptions and obtained the access token through the client credentials grant flow in AD but i still get an unauthorized.
This is probably because the azure management API has no permission set other than delegated - the access works fine if i use the authorization code grant flow for the logged in user, but thats not what i want.
So to reiterate, if, given a web app that has RBAC to a subscription and is able to obtain an access token from AD, is there any way, without an interactive user, that the web app is able to use the management API??
Yes, you can obtain a token from AAD for a service principal and use that to manage resources as long as that service principal has all the access you need.
Make sure the token you get has a resource/audience of "https://management.azure.com" and is for the tenantId that the subscription is associated with.
You can also see this article from Brady Gaster that explains how to use Azure AD applications to manage Azure Services from an external app : http://www.bradygaster.com/post/using-windows-azure-active-directory-to-authenticate-the-management-libraries
EDIT : Azure AD supports Service to Service calls using OAuth 2.0 client credentials: https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx
Hope this helps,
Julien