Reputation: 5621
I was actually able to set up this scenario but there is a very confusing part in the Azure Portal that I could only fix with PowerShell and I would like to ask if this: Is this behavior by design or if there is another part of the portal where I could make this configuration without using PowerShell?
Ok, so steps to create this scenario:
Update application B's manifest to add new appRole which is 'admin' and allowed types is "user" and "application" See: https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#approle-type
Register application A in tenant (implicitly creates service principal)
Go to application A's required permissions blade.
Question 1: Why is does the role only show up in the application permissions section and not also delegated permissions?
I set the appRole to be of type "application" or "user" but it will only show up in the "application permissions" second of the UX. My understanding is that if you are requesting a token on behalf of user using refresh tokens then you use the delegated permissions section, if you are requesting token using secret or certificate you should get the application permissions.
Now, select the 'admin' application permission from app B and save
You can verify this updated the requiredPermissions
second of the application A's manifest to include the admin role from app B.
Now I went to my application code and used ADAL to acquire token such as:
var authenticationContext = new
AuthenticationContext("https://login.windows.net/<tenant-id>",
TokenCache.DefaultShared);
var clientCredential = new ClientCredential("<app-A-app-id>", "<app-A-key");
var authenticationResult = authenticationContext.AcquireTokenAsync("<app-b-
resource-id/app-id-url>", clientCredentials);
authenticationResult.AccessToken
Now, take the token over to jwt.io for inspection and I expected the token to have the "roles": [ "admin" ]
claim in it but it did not. At this point I tried going back to B's manifest adding custom oauth2Permissions
(see: https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#oauth2permission-type) and then updating A to require those, but again generated a new token and it didn't have these listed as scopes in the token either.
I was thoroughly stumped until I started investigating with PowerShell.
If you use the snippet from here:
Get-AzureADServiceAppRoleAssignment -ObjectId $spA.ObjectId
It returns Nothing! Even though I had gone to apps required permissions and selected the role from B!
This brings Question 2: What does it mean to select application permissions in the Portal if they do not create app role assignements?
I manually created the role assignment using: `New-AzureADServiceAppRoleAssignment -Id $role.ObjectId -PrincipalId $spA.ObjectId -ResourceId $spB.ObjectId -ObjectId $spA.ObjectId which translates into create role assignment of 'admin' when service principal A requests token for resource / service principal B.
Question 3: Why do we need to specify both ObjectId and PrincipalId both to be the object id of principle A?
Question 4: If possible, how do I create application role assignments in the portal?
Since the explicit setting of application A's required permissions to B didn't have any affect on the token. I verified that even with all required permission removed, (No dependency on B) I could still acquire a token for B resource with A credentials. Question 5: Does this mean any app in the tenant can request token for any other application in the tenant? My previous understanding was that application A had to explicitly set required permissions on the apps it was able to request tokens for.
For example, if you wanted to your web api to make a request to the microsoft graph api, shouldn't you have to declare this?
Upvotes: 3
Views: 2896
Reputation: 58723
Why is does the role only show up in the application permissions section and not also delegated permissions?
Because an appRole is never a delegated permission. App roles can be assigned to users by assigning them to the app and selecting a role for them. It is used to give certain users/groups certain roles in an app.
If you want a delegated permission, then you define an oauth2Permission.
What does it mean to select application permissions in the Portal if they do not create app role assignements?
It only sets up the required permission. To create the app role assignment, you must grant the permissions as an admin. This can be done with the Grant Permissions button in the portal, or with prompt=admin_consent
when signing in Azure AD.
Why do we need to specify both ObjectId and PrincipalId both to be the object id of principle A?
Actually when creating an app role assignment manually through the Graph API you don't have to specify the ObjectId. Is it mandatory with PowerShell?
If possible, how do I create application role assignments in the portal?
Answered above, run admin consent.
Does this mean any app in the tenant can request token for any other application in the tenant?
This one I'm actually not sure about, have to test later. But anyway, there won't be any roles in the token right? So your authorization should block it anyway?
Upvotes: 3