Azure AD App Registration settings for UIPath - azure-active-directory

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 .

Related

Grant Admin Consent programmatically on newly created app registration

TL;DR
To grant admin consent to a newly created single-tenant app I need to know its Service Principal Id. Is there a way of getting the Service Principal Id of a newly created app registration when it is not listed in the results from a call to the MS Graph API ServicePrincipals endpoint?
I am using the Microsoft Graph Beta SDK to add functionality that enables users of our application to create and maintain SDS Sync Profiles.
I have a multi-tenant app registration which, given user consent, enables me to create a single-tenant app registration in the user's tenant using the graphClient.Applications.Request().AddAsync({application}) method. The process I have works fine and the single-tenant app registration is created with the necessary permissions but these require admin consent. Currently I am sending users to the adminconsent endpoint: (https://login.microsoftonline.com/{tenantId}/adminconsent) where the user can grant the necessary permissions. This is also working fine but it requires the user to log in again, having already logged in once to grant consent to the multi-tenant app. This is clearly not great from a UX point of view so I would like to avoid the necessity of the user having to log in again if possible.
I came across this post: https://winsmarts.com/how-to-grant-admin-consent-to-an-api-programmatically-e32f4a100e9d which explains how to grant the admin consent programmatically . This involves creating an oAuth2PermissionGrant object with the scopes listed that admin consent is required for.
The issue I have is that in order to add the oAuth2PermissionGrant I need to know the Service Principal Id of the single-tenant app registration just created. However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
Once I grant admin consent to the permissions on the single-tenant app registration, either manually in Azure AD or via the adminconsent endpoint, the single-tenant app registration shows in the results from the call to ServicePrincipals endpoint.
Additionally, if I haven't granted admin consent, and just make a call to any Graph endpoint, and, when (having logged in again) the grant permissions page is shown, I don't tick the "consent for my organization" box, the permissions remain (as expected) in "require admin consent" status, however the single-tenant app registration now shows amongst the Service Principals list.
Sorry for the long question but any advice would be most appreciated.
Thanks
David.
However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
That's because a service principal is not created automatically when you create an application through the APIs or with PowerShell. Azure Portal creates it for you at the same time when using it for convenience, but the raw APIs don't do that. You need to create the service principal, the only mandatory parameter is the appId (your app id/client id) if I recall correctly. Here is the documentation page for that: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-serviceprincipals?view=graph-rest-1.0&tabs=http
Once the service principal has been created, you should be able to create the oauth2PermissionGrant objects that grant the permissions you want for all users in your directory.

Is it possible to check whether Azure Active Directory user is allowed to authorize my application?

Our application allows users to authenticate via Azure Active Directory using OpenID Connect.
However, some organizations do not allow users to approve applications, and require administrators to approve the application first.
Right now, this means that if a user wants to connect using their work account, we have to first send them to Azure, where they then enter their password, and then are told that our application requires administrator approval. Not a great experience.
Ideally, I would like to give only users whose tenants allow them to approve new applications (or those that already have) the option of logging in via AAD. Is this possible to do through an API call?
Microsoft does not provide such an API for this purpose.
As a workaround, you can quickly check it using auth code flow: Request an authorization code.
Enter their password is necessary. Sign in to this url with customer's credential:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Then they can see if they need admin consent or not.
The essence is the same as the steps you described. But it can save a lot of time.

Adding new static scopes to existing Azure AD app registration

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

Prevent logins to unauthorized AAD tenant?

Is there a way to prevent users from logging into their own AAD tenants? For example, allow login to contoso.onmicrosoft.com but not fabrikam.onmicrosoft.com.
My customer has a highly-controlled Azure environment where they are running some servers and PaaS/SaaS applications. Users connect to those servers are use a variety of Azure services and some SaaS (primary concern is PowerBI). They’re concerned that a user could login with a non-company account (wahid#hotmail.com) and then upload sensitive data their own PowerBI workspace.
You cannot prevent a user who has already been in the tenant to login to that AAD tenant, except deleting the user from that tenant.
If one account was created/invited to one tenant, the user just can login to that tenant.
For the scenario you described, I suggest you could revoke the Product license for those users. If you don't assign product license to the user, the user cannot use that App or cannot see that app in My Apps panel. For other SaaS/PaaS app(Web App), you may use user assignment to allow specific users to access the App.
For others: Daniel answered this for me. Short answer, this isn't easy, you would need to inspect the response body for the tenant ID (or name) and then block it. This would also lead to a poor user experience but that's all we can do today.
Yes, you have a few options.
Option 1: Single tenant apps
If you have the ability to create apps in the tenant you want to accept users from, you can mark your app as available to only this tenant (the field is called availableToOtherTenants). This will notify the token service to only authorize access from users in the tenant the app was created in.
Option 2: Multi-tenant app w/ token validation
The other option is to mark your app as multi-tenant (same field as above, just set to true) and implement logic in your app to validate the user's tenant from which the token was issued.
In this scenario, you will need to have some kind of web service that can safely validate access tokens (.NET code sample on this). To check the tenant the user's account belongs to, you'll need to validate the iss field. It'll look something like this,
"iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/"
in which the GUID represents the tenant ID. This allows your web API to have an allow or deny list based off tenant IDs.
More help
Here's an excellent blog post on token validation.
Azure AD Developer Docs
.NET Web API Code Sample

Azure AD V1 endpoint registered native app: Graph API consent given but user can't get through

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.

Resources