So, I have a WPF application, and I wanted to integrate SSO to it.
I successfully made it with "App registration" under Azure.
But now I have a problem, the users under the Azure AD can successfully connect to the app, but I want to specify which users in my AD can access to this app.
I didn't find any way to do this, and I see that in "Enterprise application" we can do so.
I wanted to know if there is any way to do it with "App registration" or if I must switch to use "Enterprise Application" and if so how can I handle the authentication in my WPF app .
In my case I use this to authenticate in the wpf app with "Tenant" and "clientId" from the app registration:
PublicClientApp = PublicClientApplicationBuilder.Create(ClientId)
.WithRedirectUri("https://login.microsoftonline.com/common/oauth2/nativeclient")
.WithAuthority(AzureCloudInstance.AzurePublic, Tenant)
.Build();
authResult = await PublicClientApp.AcquireTokenInteractive(scopes)
.ExecuteAsync();
The "registered application" is just a notification to the AAD that this application uses AAD for authentication. Once your user logs in, you can check that the user belongs to a security group that is allowed permission to use the application. There may be a better way to do this, but I check in the application itself.
To grant access only for a specific subset of users/groups in Azure AD you should create "Enterprise Application" and assign necessary users/groups to it like in this example.
Also you will need to configure single sign-on (SSO) and ensure that app's "User assignment required" property is enabled. All the steps are described here
Related
I have created an Azure AD app registration for a cross-platform (Xamarin.Forms) mobile application for our employees. The app registration is setup to work as a single-tenant app and in order to function properly, we have specified a number of permissions to Microsoft Graph, such as "openid", "profile", and "User.Read", which have been given admin consent by our Admin. The app uses broker authentication (using ADAL) in order to sign-in users to the app via the Intune Company Portal app already installed and setup on every user's device.
Up until recently, everything worked fine until we needed to add a new Microsoft Graph permission to the app registration, namely "Group.Read.All". So, we added the new permission to our app registration as a delegated permission and had our admin provide the admin consent for all the users.
After giving consent to the new permission, our users could not login to the app since the Intune Company Portal app did not sign-in the users to the app, but instead advised them to setup their device by installing and setting up the Intune Company Portal app on their device (?!).
As I mentioned before, the devices already had Intune Company Portal installed and properly setup on their device for more than 2 years now.
So, we thought of checking the user sign-ins of the user to find out what the problem was and we found a failure event recorded with sign-in error code 530003 (Access has been blocked due to conditional access policies.) where it showed that the policy "Access Policy: Require Device Enrollment for Accessing EOL & Sharepoint from handheld devices" failed with reason "require compliant device" (under column Grant Controls).
As soon as we revoked the newly added permission "Group.Read.All" from the app registration, our users could sign-in to the app successfully.
When we tried adding other permissions like Directory.Read.All and GroupMember.Read.All, we did not have any issues with our sign-in flow via the Intune Company Portal.
Can you please advise what it is so special about the "Group.Read.All" permission that raises the Azure sign-in error code 530003, forcing the Intune Company Portal app to require the users to setup their (already setup) device, before they can sign-in to our app?
I am at my wits' end with this one.
Any ideas?
For me it is not possible to reproduce your issue due to multiple things involved.
Few suggestions that you could try at your end:
Try isolate each component and leverage graph explorer/postman to make an API call and observe behavior.
I didn't get the need to add graph permission, but as per your use case see if there is any other least privileged permission that could get your job done, add that permission and check behavior.
Check if your scenario really demanded adding permission as delegated and if this is really supported? For e.g, below image shows necessary permssion to get the properties and relationships of a group object.
If problem still persists, consider contacting Microsoft support for your specific scenario.
we are using UIPath within our company for RPA. We tried setting up UIpath to send mail on behalf of other users. We followed this guide: https://docs.uipath.com/marketplace/docs/microsoft-office-365-setup
There are 2 odd things to this setup:
We HAVE to make the App Registration a "Public Client" in Azure. To my knowledge, normally this applies to frontend web applications where the app secret cannot be kept hidden. This is a backend process, so I think there is no reason of having to use a public client. Am I right in this statement? What are the downsides of having a public client? Anyone possessing the client_id can impersonate this app registration? (can act as this app registration and ask users for credentials and get a token on behalf of this app?)
I added some api permissions to the App Registration like mail.read, mail.send, etc. It stated that no "Admin consent required", but it didnt work. After I pressed the "admin consent" button it said that it granted those permissions and the configuration seemed to work. What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Some extra clarification about the public credentials:
-I register an application called App-X, which is set to public.
-Normally, without a public client, when I request a token, I need both the client_id and the client_secret. By using the client_secret, microsoft knows that I am indeed really the application App-X who is requesting this token on behalf of the user.
-Without using client_secret, anyone who knows the client_id, can request consent from a user and say "I am App-X and I am asking for permissions", while in fact they are not App-X (just some random someone who finds the client_id). After the user consented, because "he knows App-X and he trusts it", then the malicious user/app can also request a token from microsoft because he only needs a client_id.
1.This is a backend process, so I think there is no reason of having to
use a public client. Am I right in this statement? What are the
downsides of having a public client? Anyone possessing the client_id
can impersonate this app registration? (can act as this app
registration and ask users for credentials and get a token on behalf
of this app?)
It depends on your application type. "Public client" is usually used to configure mobile and desktop client applications. Since UIPath is a mobile application that monitors the RPA environment, for your application registration, you need to choose to use "Public Client" registration.
If you don’t want your application to be used by users of other organizations, you don’t need to register the application as a multi-tenant application when you register your application. If your application needs to be used by multiple organizations, you need to register the application as Multi-tenant application. In this case, in theory, all tenants can use this application. However, you can verify which tenant the logged-in user comes from when logging in, and you can prevent tenants that you do not want to log in from logging in. Please see:here.
2.What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Each application registers permissions it requires. Some permissions can be granted by users, some other only by the administrator.
Let's suppose you have only permissions that can be consented by users. The first time they use the application, they'll be prompted (each user) to consent those permissions to the application. If in the same scenario you click on grant admin consent, it is the equivalent of accepting it for all users on the tenant.
Now let's suppose the application registers permissions that require admin consent, you have no choice but to click that button if you want the application to work and be able to request tokens.
For those permissions that require the administrator’s consent, you You can go to Azure portal>App registrations>API permissions>Admin consent required to view .
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
When registering a native application on the Azure AD 1.0 endpoint, and assigning Graph API permissions, it seems like consented permissions are 'cached' somewhere and can't be managed properly.
Example scenario:
Application registered and permission scopes (incl. ones requiring admin consent) assigned.
Administrator consents to the permission scopes
Simple user can use the app with consented permissions.
Permission scopes change (adding a new one for example)
Same admin doesn't get the consent form anymore
Simple user is stuck with "consent required, have an admin account?"
Another global admin must use the app for the first time to trigger the consent page.
Note that #7 doesn't always work; even if the other admin provides consent, simple users can't get through sometimes.
This is a multi-tenant application, yet when start using it in another tenant, I can not see its consented permissions in the AAD portal under enterprise applications.
Shouldn't permissions that have been consented to be listed in other tenants so that the admin can at least see what has been consented to?
Also, when I register an app on the V1.0 endpoint in my own tenant, I have an option to 'grant permissions' centrally, from the Azure AD portal for my tenant.
This option isn't available if I'm looking at an application that was registered in another tenant.
Am I overlooking something? Any help much appreciated.
When you change permissions, it does not automatically re-consent (for user or admin). You can find a detailed overview of this at Understanding user and admin consent.
You'll first need kick off the Admin Consent workflow. For a multi-tenant app this is done by adding prompt=admin_consent to your OAUTH URL and having an Admin authenticate.
Once that is done you can also force existing users to re-consent as well by adding prompt=consent to your Auth URL.
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.