I'm the owner (with my human account) of an Application Registration and I'd like to impersonate its Service Principal. How can I achieve that? I wasn't able to find any docs on this.
You cannot "impersonate" a service principal.
What you need is authenticating to the API you want to access using the application's credentials.
This is done using the OAuth client credentials flow (one HTTP request): https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow.
More info on this scenario: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-overview.
Related
I need to receive list of user's subscriptions using service principal.
For user which has token now it's easy - A GET call to https://management.azure.com/subscriptions?api-version=<API_version>
But how is ti possible for any user in Azure AD, if my service principal has enough permissions in Azure AD?
Thanks in advance!
You could not use the service principal to get the user's subscriptions(i.e. the subscriptions that the user can access in one tenant) via this REST API.
When you use the REST API Subscriptions - List, it will make the request depends on the access token passed, if you use the service principal to get the token, you can just get the subscriptions that the service principal can access, not the user.
In this case, your option here is to use the auth code flow or implicit grant flow(the Try it button in the doc use it, not recommended) to get the token, then use the token to call the REST API to list the subscriptions that the user can access.
I have a c# service, the service is running somewhere in the azure cloud without an user interface. some specific events should trigger new messages to a team channel.
According to this documentation, the Create Message https://learn.microsoft.com/en-us/graph/api/channel-post-messages?view=graph-rest-1.0&tabs=http is only supported by delegated account, not by the application tokens.
How can i create a delegated token for my service application without specific user account and without a login interface in the cloud?
Which Authentication Provider is the right one? https://learn.microsoft.com/en-us/graph/sdks/choose-authentication-providers?context=graph%2Fapi%2F1.0&view=graph-rest-1.0&tabs=CS
As you mentioned in the question : chatMessage , supports only the Delegated Permission type.
What exactly is Delegated Permission Type?
A permission which specify scope-based access using delegated authorization from the signed-in.
The reason on the emphasis of the above point is being that - for Delegated permission we would need the context of a user account
Coming back to your questions :
How can i create a delegated token for my service application without specific user account
You can obtain a token without a specific user account but this will not help your cause.In order to overcome this, I would suggest a creation of service account - this account has permission over the teams.Part 2 of this questions suggests which provider can help without the login prompt.
The steps include :
Register your app.
Configure permissions for Microsoft Graph on your app.
Get administrator consent.
Get an access token.
Use the access token to call Microsoft Graph.
Detailing of the steps is included in the article here : https://learn.microsoft.com/en-us/graph/auth-v2-service
without a login interface in the cloud
Now you could use the below option :
Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials
In this provider, you will be passing the creds of the service account.
POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=<YOUR CLIENT ID>
&scope=user.read%20openid%20profile%20offline_access
&username=<YOUR USERNAME>
&password=<YOUR PASSWORD>
&grant_type=password
You can generate the token for your service account by above request and application can consume the chatMessage API.
All of the examples on the microsoft azure site having to do with a client application or a service principal having access to azure apis all show the graph apis as the example.
I got those to work, but what I need to do is access the azure service management apis.
If I take an auth token that works for the graph api and use it for the service management api, I get an "Authentication failed." error.
I have added the api permission for "azure service management" and the user_impersonation delegated permission type to my public client app, but the management apis still fail.
Am I going about this all wrong?
I get the idea that the service management apis are authenticated a different way since there's absolutely no mention of using them anywhere in any of the auth examples.
I suppose you are using the client application or a service principal to access azure resources. If so, you are using the client credential flow, but the user_impersonation of Azure Service Management API is a delegated permission, it will not take effect in this flow.
The permission is used to be consent by the user who login to the AD App e.g. in the auth code flow, when it has been consent by the user, the App will be able to represent the user to access the azure resources, note the permission is from the user, not the app. So if you want to use this flow, the user should have a role in the subscription or specific resources.
To access the azure resources with the client application or a service principal, you just need to add the service principal as an RBAC role in the Access control (IAM) of your subscription or specific resource, no need to add any API permission in Azure AD, see this link. Then the service principal will be able to access the azure resources.
When you getting the token to access the azure resources, e.g. call the REST APIs, the scope should be https://management.azure.com/.default, not the https://graph.microsoft.com/.default, you can just get the token for one resource in one time.
I am working with Azure AD through OAuth 2.0 protocol and also creating a Service/ Dameon application to handle the authentication process for Microsoft Graph SDK. For the service/daemon, I make a HttpWebRequest and pass along the client_id and client_secret to generate an access_token where I then can supply to the Microsoft Graph SDK.
I also have successfully created a corresponding service principal to the target tenant, in which an admin has granted permissions to the application using the authorization code grant flow. The application then shows in Overview -> Quick tasks -> Find an enterprise app, within the (portal.azure.com).
My question is there an approach where I can leverage the service/daemon approach while also allowing an admin from the target tenant to authorize the application, that would allow the target tenant to create a client_secret to pass which would be unique to that tenant?
Short answer is no. When an admin consents your multi-tenant app:
A Service Principal is created for it in their tenant
Permissions requested by the app are granted in that tenant
This means your app can now authenticate with its client credentials (id + secret) against their tenant as well. So the same keys work in all approved tenants.
What that means is your app is free to get an access token for any of them at any given time, no matter who is signed in. So it puts some responsibility to your app to keep data separated.
If you get an access token from https://login.microsoftonline.com/company.com/oauth2/token, the resulting token will contain that tenant's identifier. And APIs like the Microsoft Graph API will only give you data for that tenant with that token. So your app must make sure to only use a token that has a tenant id equal to the user's tenant id claim.
I would say that juunas' answer is 99% correct. The short answer is basically no, and the considerations he mentions are also solid.
But I believe that this would be technically possible under certain considerations. When the admin consents to your daemon service, a service principal is created in your customer's tenant. Service principals do allow addition of credentials that can be used as client secrets on a per-tenant basis. The thing is, there's not really a way to add a credential to a service principal programmatically from your app. You would have to get an administrator to run some script to add the new credential to their tenant's service principal.
Even if you went through all this, you would need to make sure that your service is also isolated on a customer/tenant basis. Security-wise, it's sort of pointless to create per-tenant client secrets if your singular daemon has access to all of the secrets.
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