Grant service principal access to application in other tenant
Asked
3 years, 4 months ago Active
1 year, 2 months ago Viewed
5k times
I have an Azure AD service principal in one tenant ( OneTenant ) that I would like to give access to an
application in another tenant ( OtherTenant ).
4
The service principal in tenant OneTenant is a managed service identity for an Azure Logic App. So what I
actually want is to call an API from my Logic App. This API is protected by an Azure AD application in
OtherTenant .
1
The application in OtherTenant defines a number of roles and the service principal in OneTenant should have
one of these roles so it can call the API.
I tried the following:
set the app in OtherTenant to multi-tenant
ran the following PS command to attempt to add the SP to a role in the app:
New-AzureADServiceAppRoleAssignment `
-ObjectId <object-id-of-sp-in-one-tenant> `
-Id <role-id> `
-PrincipalId <object-id-of-sp-in-one-tenant> `
-ResourceId <app-id-in-other-tenant>
(both logged in in OneTenant and OtherTenant )
This gives an error stating that either app-id-in-other-tenant or object-id-of-sp-in-one-tenant can
not be found, depending on where I am signed in.
I also tried creating a Service Principal in OneTenant based on the app-id from OtherTenant In that case I get
an error message: Authenticating principal does not have permission to instantiate multi-
tenantapplications and there is not matching Applicationin the request tenant.
azure-active-directory
Share Edit Follow Flag edited Nov 30, 2018 at 7:44 asked Oct 4, 2018 at 12:07
Ronald Wildenberg
30.9k 12 85 128
3 Answers Active Oldest Score
Ok, I finally got around to testing if the solution presented by Rohit Saigal works. It does point in the right
direction but is not complete.
6
First step is to create a service principal in OneTenant that represents the application in OtherTenant . So
while signed in to OneTenant , run the following script:
$spInOneTenant = New-AzureADServicePrincipal -AppId <app-id-in-other-tenant>
Next step is to run the New-AzureADServiceAppRoleAssignment cmdlet with the following parameters:
New-AzureADServiceAppRoleAssignment `
-Id <role-id> `
-ObjectId <object-id-of-sp-in-one-tenant> `
-PrincipalId <object-id-of-sp-in-one-tenant> `
-ResourceId $spInOneTenant.ObjectId
The trick is to use the object id of the service principal you created in the previous step as the ResourceId .
Share Edit Follow Flag
answered Nov 30, 2018 at 7:53
Ronald Wildenberg
30.9k 12 85 128
I like that this is at least an option. I have a backlog item to do something like this in another tenant (big thank you!).
How are you authenticating? Can you share secrets?
– Jason Phillips
Feb 21, 2020 at 2:45
Correct me if I'm wrong, but this workaround only works if the JWT validation on the resource server fails to validate
the authority claim - which is a security hole. The fundamental problem here is that SP from OneTenant can not get
a token from the OtherTenant because there's no way to make OtherTenant aware of the SP from OneTenant .
– Eugene Tolmachev
Jul 27, 2020 at 13:40
@EugeneTolmachev no, there are no "get token" operations involved here. ServicePrincipal created in current tenant
is representation of that App-id-in-other-tenant in the current tenant for purpose of granting permissions
(stackoverflow.com/questions/54066287/…). Basically code says "whenever app-id-in-other-tenant tries to create
token call app-id-in-one-tenant check if spInOneTenant was granted any roles for it".
– Alexei Levenkov
Sep 29, 2020
at 3:39
@AlexeiLevenkov the "get token" is implied. This is why this whole granting is being discussed - to get access to an
application, i.e. acquire token from AAD given the app as the target scope/resource. You can instantiate my multi-
tenant application in your tenant, but each AAD tenant will issue it's own "authority" claim - this is by design and
correctly implemented claims verification MUST check that the token-issuing authority is the one it trusts. I.e you
can't call my service, if you obtain the token using your AAD tenant, unless I specify your AAD as the issuing authority.
– Eugene Tolmachev
Sep 30, 2020 at 19:22
Taking the command as is from your question:
4 New-AzureADServiceAppRoleAssignment `
-ObjectId <object-id-of-sp-in-one-tenant> `
-Id <role-id> `
-PrincipalId <object-id-of-sp-in-one-tenant> `
-ResourceId <app-id-in-other-tenant>
Try changing the last parameter value i.e. ResourceId
Currently you're passing <app-id-in-other-tenant>
Replace that with <object-id-of-API-in-other-tenant>
Share Edit Follow Flag answered Oct 5, 2018 at 6:01
Rohit Saigal
8,519 2 13 27
@RonaldWildenberg did the suggestion work for you or still facing issues?
– Rohit Saigal
Oct 8, 2018 at 17:13
Sorry, busy with other stuff. Testing right now if this works.
– Ronald Wildenberg
Oct 9, 2018 at 9:25
Still waiting for someone to run part of my PS script because I do not have sufficient privileges to execute all of it
– Ronald Wildenberg
Oct 25, 2018 at 10:03
Hi Rohit, I tried the same, but it does not work: New-AzureADServiceAppRoleAssignment : Error occurred while
executing NewServicePrincipalAppRoleAssignment Code: Request_ResourceNotFound Message: Resource '<object-
id-of-API-in-other-tenant>' does not exist or one of its queried reference-property objects are not present.
– Tom
Nov 12, 2018 at 12:23
@Tom is your scenario exactly like the one described in question above or there are some differences?
– Rohit Saigal
Nov 14, 2018 at 3:01
The question/answers presented here were helpful, but yet it took me some time to work through the details
and actually make it work, so allow me to elaborate some more on the above, as it might help others too.
0
Scenario
Two tenants:
Home Tenant .
Other Tenant .
One Azure App Service API app , with access managed by the Home Tenant .
One Logic app placed in a subscription in Other Tenant that need to securely access the API app in the
Home Tenant .
Approach
Application registration
For the API app to delegate identity and access management to Azure AD an application is registered in
the home tenant ’s Azure Active Directory. The application is registered as a multi-tenant app.
You also need to create an app role (see documentation: How to: Add app roles in your application and
receive them in the token), lets call it read.weather .
Configuration of Other Tenant and Logic App
To provide the Logic App access to the API app do this:
1. Enable a system assigned identity for the logic app - i.e. use Managed Identity. Note down the system
assigned managed identity Object ID ( {18a…} ), you will need it in a minute.
2. Create a service principal for the application in the Other Tenant using this command, where appId is
the appId of the application registered in Home Tenant (e.g. lets say it’s {1a3} here):
New-AzureADServicePrincipal -AppId {appId}
This command will output a json document which includes among other things an objectId for the service
principal just created.
[... more json ...]
"objectId": "b08{…}",
[... more json...]
You should also see the appRoles, including the app role read.weather you just created, om the json output
from the New-AzureADServicePrincipal command:
[... more json...]
"appRoles": [
{
"allowedMemberTypes": [
"Application"
],
"description": "Read the weather.",
"displayName": "Read Weather",
"id": "46f{…}",
"isEnabled": true,
"value": "read.weather"
}
],
[... more json...]
3. To tie it all together make an app role assignment using the command:
New-AzureADServiceAppRoleAssignment -Id {app role ide} -ObjectId {system assigned identity object id}
-PrincipalId {system assigned identity object id} -ResourceId {object id of service principal}
E.g. something like this:
New-AzureADServiceAppRoleAssignment -Id 46f… -ObjectId 18a… -PrincipalId 18a… -ResourceId b08…
4. Now we are ready to set up the HTTP request in the Logic App using the URI to the API app using
Managed Identity for authentication.
Notice that the audience is needed and has the form: api://{appId} .
But wait…!
Does this mean that anyone could do this, if only they know the appId of your application registration, and
wouldn’t this compromise the security of the API app ?
Yes, it does, and yes indeed it could compromise the security of the API app .
If you look at the access token being created and used as bearer from the Logic App it is a valid access
token, which contains all the necessary claims, including the app role(s). The access token is however issued
by Other Tenant and not Home Tenant .
Therefore, if you have a multi tenanted application and you want to guard it against this scenario, then you
could check the issuer ( tid more likely) of the incoming access token calling the API and only accept it if the
issuer is the Home Tenant , or you could make the application a single tenant app.
Or, you could require that the issuer matches a list of tenants that the API trusts.
Share Edit Follow Flag edited Dec 5, 2020 at 14:47 answered Nov 9, 2020 at 8:39
1iveowl
1,452 1 18 29
