I have a registered App which requires several application permissions (getting them through Admin Consent flow).
The app is multi-tenant and is already serving a lot of users.
Now I would like to add some more permissions to what the App is requesting and I just want to make sure that adding these permissions won't effect my current users that are using the app.
I understand that in order for the new permissions to apply on existing users, their corresponding organizations admins will have to re-consent, but other than that, I would like to make sure (cant find it in docs) that current users will still be able to use the app the same way as they did before (without the features that requires the new permissions).
Is that really the case? nothing won't 'stop working' because of the permissions change?
When you add permissions to an app registration, previous consents do not get revoked. however depending on the scopes that your app requests, it may force a new consent window to appear. since you are using application permissions, regular users cannot consent to the permissions. for example if your client is requesting a .default scope, then it will try to get all the permissions specified in the api permissions, which would include the new permission (that needs consent). if your token requests only include the old permissions in the scope, then nothing should change.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#example-3-the-user-has-consented-and-the-client-requests-additional-scopes
But, I don't believe that the application will fail even if consent hasn't been given to the new application permissions, but it will fail to receive the new scopes if requested. and any resulting function that uses those additional permissions will fail, until an admin consents to those new permissions.
Related
I'm trying to manage multiple outlook calendars using a single account as a proxy, so all other accounts share their personal calendar with this "master" account and within this one i can add, edit or delete events "for everyone".
The problem is that i can't get the account grant the Calendar.ReadWrite.Shared to the app, even though that in my app this permissions are configured as recommended.
Azure portal - app permissions:
permissions of the app in azure portal
msalconfig:
msal configuration used
The "funny" thing is, with the account used to create the app in the first place everything works, but with any other account not.
I even created another app with the intended final account and nothing. This is the, incompplete permissions, resul:
actual result
This is the desired result:
desired result
If you just want to make a proxy to modify calendars for all users, have you tried application-only Auth and grant Calendars.ReadWrite permission with application type to it? Based on this permission official comment: Read and write calendars in all mailboxes which seems to meet your requirement.
TL;DR
How can I delegate my user permissions to a service principal in Azure Ad when the usual interactive way (e.g. web app with consent screen popup) is not feasible? This is because I cannot configure the MSI in the Azure Portal properly to work that way.
More detail
I want to grant an application permission to access the Graph API on behalf of a user. Usually, this is a well-documented scenario in which you create an app registration, acquire delegated user permissions by asking permission for the needed scopes, and then use these permissions in the app.
The app that needs Graph access is a background service that is to work on its own without user intervention/activity. For this use case, the common approach is to use application permissions. In my case this is not feasible, because application permissions require admin-consent and are all-or-nothing kind of permissions. There is no way this will be granted for me. Rightfully so, because its overkill.
But on the other hand that's really a pity. A pity, because I've found an example on how to assign Graph API application permissions directly to a Managed Service Identity rather than to a self-registered app. And my service (as an Azure Functions app) already has a MSI assigned to it. So this would be the perfect fit, b then again, there is no way I'll get those application permissions.
So what is the workaround? We have this one user principal which has all the required permissions we need for our background service. What I want to do is to delegate this user's permissions to the Function App/MSI. In order to do this, I used this SPA-template by the MSAL team to have something that will prompt me the permissions popup.
This however failed because the implicit oauth flow was not enabled. To remedy this, you usually need to update the app manifest in the portal. However, since this is a MANAGED service identity, and not a self-registered one, the MSI is not listed in the portal under app registrations. So I cannot set this property to true.
Doing the same via Azure CLI also failed because apparently the MSI is not identified as an app.
az ad app update --oauth2-allow-implicit-flow true --id <appId_of_MSI>
This yields the following error:
ResourceNotFoundError: Resource '<appId_of_MSI>' does not exist or one of its queried reference-property objects are not present.
It shows fine when doing this
az ad sp show --id <appId_of_MSI>
So in summary: I cannot complete the process of delegating that user's permissions interactively. Is there any other way? Maybe via CLI?
The fallback the solution is to create a separate unmanaged/self-registered app identity. But I want to really avoid this because then I would need to manage and rotate client (app) credentials again, which the MSI took care of for me.
Why o why can't I just assign fine-scoped application permissions 😒
Any help on this is greatly appreciated. Cheers.
In my experience Managed Identities don't support the scenario you are suggesting.
They do not have an app registration and in that way cannot authenticate users interactively.
I would go with your fallback solution; a normal app registration and use that to access Graph API on behalf of the user.
This is what we do in our projects at least.
App permissions -> Managed Identity if possible. Delegated permissions -> normal app registration + secret/certificate in Key Vault, retrieved with Managed Identity.
My AD tenant has user consent disabled, i.e., all permissions added to AD app registration need an admin consent.
For an application using static permissions/scopes (v1.0 OAuth/OpenId endpoint), is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Microsoft docs say: "The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources." Does it mean that for my scenario, all users need to wait for admin consent before they can access the app?
I receive the below error when a user tries logging in to the app using the Open ID Connect flow. For reference, my login URL is similar to https://login.microsoftonline.com/{tenant}/oauth2/authorize?response_type=id_token&client_id=b8ad6a99-cd23-40a6-a1b4-1184af990aa2&redirect_uri=https%3A%2F%2Flocalhost%2F&state=13ccfb84-cfd1-4cb0-bfe3-bb2c227e19f7&client-request-id=4d76947a-0000-48af-aeff-7bc2d5e40000&x-client-SKU=Js&x-client-Ver=1.0.17&nonce=ef1caa16-d3fe-4523-a9c9-000000000000
is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Yes, you can.
When the admin consent the API permission of an AD App(App registration), the permissions essentially will be given to the service principal(Enterprise application) in your AAD tenant. Actually if you use the AD App in your tenant, the permissions are essentially from the service principal.
You could refer to the screenshot below, there are four permissions, the two permission has been granted.
Navigate to the Overview, click the option Manage application in local directory.
Then in the Permissions, you will find the two permissions which have been consent.
When you add the new scopes, the app will keep working, but it will only be able to access the old scopes until the admin consents to the new scopes.
Thanks!
Alex Simons
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
I have a UWP app that uses WebAccountManager for AAD authentication. I also have a service, hosted in Azure, used by the UWP app. That service uses the token the UWP app sends to get another on-behalf-of token (I think that's what it's called) to then call other service APIs as the user (e.g. Microsoft Graph and Outlook REST API). In other words, UWP app calls WebAuthenticationCoreManager.RequestTokenAsync to get a token, sends it to my service, my service calls AuthenticationContext.AcquireTokenAsync to get an on-behalf-of token to use when calling the Outlook REST API, for example.
In the AAD registration for my service, the "Required Permissions" list all the services and permissions/API calls it might make on behalf of the user (E.g. "Microsoft Graph"-> "Have full access to user calendars")
When my UWP app creates the WebTokenRequest to pass into the RequestTokenAsync function, it currently passes an empty string as the value for "scope." What should it be passing for the scope parameter? Should it be passing the full and exact list of permissions that the service declares are required? If so, how do I get that permission list to the client? Just hard-code and update the list whenever the service required permissions list changes?
In Azure Active Directory, there are two fundamentally different ways to specify the permissions your app requires when authenticating.
Static Consent
Dynamic Consent
Back in the Azure Active Directory V1 endpoint, you would set "Required Permissions" to other APIs when registering your client application. This is setting up Static Consent. These permissions are fixed, and when you trigger the user to consent to these permissions, the user has to consent to them all at once. Additionally, if at some point your app wants to add new permissions to other APIs, you will need to force the user to go through the full consent experience again, which may even require special logic on your application.
This is why in the V2 endpoint, Microsoft developed Incremental and dynamic consent.
With the v2.0 endpoint, you can specify the permissions your app needs dynamically, at runtime, during regular usage of your app. To do so, you can specify the scopes your app needs at any given point in time by including them in the scope parameter of an authorization request.
Here, you can specify only the permissions your app needs to complete the flows it is trying to accomplish at that time. If you need more access, you can simply add it during your authentication experience, and it will prompt the user only for those new permissions.
Now let's return to your question. If you are using the V2 endpoint, you should be using Dynamic Consent, which means that the settings in "Required Permissions" do not really matter to you. You should be keeping the list of scopes your app requires in your app settings.
Some situations in the V2 endpoint still require Static Consent, like service to service calls with direct application permissions. For those situations you would pass the scope <resource>/.default as noted here. This might also work for delegated tokens, but it is better to just use Dynamic Consent.