How to authorize Azure multi tenant application to provision resources in customer tenant

1
votes

I am building a multi tenant application and it has to provision few azure resources(resource group, even hub, storage hub etc) in customer(say target) tenant during a account setup process .

I followed the azure doc to register an app . I can see the service principal created in target tenant under "Enterprise Applications" and this app has delegated type "azure service management API" permission . Application in target tenant

Question: I wanted to write an function app in source tenant(which is my tenant) in PYTHON which can fetch subscriptions/provision resources in target account . I tried azure.identity.ClientSecretCredential in function something like example to fetch list of subscriptions , it retuned Zero subscriptions . I think ClientSecretCredential doesn't fit for delegated type permission, until i add explicit role-assignment to the service principal , it wont have authorization . post says the same .

Is it must to use AuthorizationCodeCredential , but it requires auth_code which needs user interaction . So, need to develop a web page which prompts for user consent and redirect the auth_code to this function using this function as redirect URI ?

Is there any other way ? Any code reference would help .

Also, what is difference between MSAL and azure.identity package classes . Any documentation on this regard , when to use which API, I have seen various examples using either of them .

1
pythonazureazure-active-directoryazure-functionsazure-authentication
ClientSecretCredential uses client credentials flow. If you add explicit role-assignment to the service principal, you should be able to use azure.identity.ClientSecretCredential. What is the issue now? Why do you have to use AuthorizationCodeCredential? – Allen Wu
@AllenWu as we don't have control over target tenant(it is the customer tenant) , can't use ClientSecretCredential . Basically I want to automate the customer account setup process like creating some azure resources etc . – Pintu
Of course maybe you could use UsernamePasswordCredential to include the user token and delegated permission to list the information you want. But in this case the user also need to has access to the subscriptions/provision resources in target account. In another word, you also need to assign the corresponding RBAC role to the user (Corresponding to the service principal of ClientSecretCredential). Besides, UsernamePasswordCredential is not recommended by Microsoft. – Allen Wu
I totally understand your requirement. If you don't have a target tenant user (or the enterprise app (service principal)) who has been assigned RBAC role, you have no access to the subscriptions/provision resources because the lack of permission. Even though there is an app registration in their own tenant, it will require the RBAC operation I mentioned as well. – Allen Wu
There is another method (another design), you can use auth code flow to get the access token for Azure Rest API in your front app and send the access token to your function, then call Azure Rest API in the function app. – Allen Wu

1 Answers

1
votes

AuthorizationCodeCredential is not suitable for function app because it is impossible to implement interactive login in the function app according to my experience.

Maybe you could use UsernamePasswordCredential, it may be unnecessary to assign RBAC role. Adding the delegated permission is enough. Anyway, using ClientSecretCredential (it's necessary to assign RBAC role to the service principal/enterprise app in this case) or UsernamePasswordCredential should be OK.

In short, if you want to use user token (AuthorizationCodeCredential or UsernamePasswordCredential) to call Azure Rest API, you need to know (or enter) the credentials of the target tenant user.

Other design: you can use auth code flow to get the access token for Azure Rest API in your front app and send the access token to your function, then call Azure Rest API in the function app.

You can learn about the differences between MSAL and azure.identity package from this post.