Alteryx Designer Desktop Knowledge Base
Definitive answers from Designer Desktop experts.Understanding Azure Applications, for Alteryx
Understanding Azure Applications, for Alteryx
Alteryx + Microsoft delivers a unique combination of technologies that enable those who work with data to gain deeper insights and deliver faster decisions. With Alteryx, data professionals amplify the value they receive from of a broad range of Microsoft products, including Power BI, Sharepoint, and OneDrive.
Alteryx Designer integrates with Azure Active Directory in order to securely retrieve your data from various Microsoft technologies; Azure manages access and identity, and Alteryx plugs into this to securely pull your data.
This article will cover the technical details of how this is achieved through the use of Azure applications and service principals.
Table of Contents
- Understanding Applications and Service Principals
- How Service Principals (Enterprise Applications) are created
- Understanding the Alteryx Analytics Connector
- Properties of the Service Principal
- Required Permissions
- How do Delegated permissions work?
- Understanding Admin Consent
Understanding Applications and Service Principals
A third-party service that wishes to access your Azure resources does this via an application. Applications are used by Azure to delegate identity and access management functions. When you register an application with Azure Active Directory, you create an identity configuration for your application that allows it to integrate with Azure Active Directory.
At a high level, the third-party (such as Alteryx Designer) talks to the application. Then, the application handles the authorization and access to your Azure resources. An example of an Azure application is shown below:
image.jpegApplications are created when:
- An admin manually creates them in the Azure portal
- A user or admin approves an application via the Consent Prompt (shown above)
The first path is manual and requires that an admin knows all of the permissions that the third-party source needs. This is possible to do, but requires multiple steps to achieve and can be slightly different for each third-party application. It could be preferred if your tenant has specific restrictions on the types of applications that can be created.
The second path is simpler. The third-party developer can create an application with all the necessary configuration details and permissions. This is referred to as an application object, and it lives in their tenant (known as the “home” tenant). When you register an application, both an application object and a corresponding service principal object are created for that tenant. This is shown in the image below.
image.jpegThis type of application object is a multi-tenant application. It is referred to as “multi-tenant” because the application can be used in multiple customer environments (aka tenants).
Think of this application object as a template to create one (or more) service principals. The next section will explain exactly how the service principal is created in the customer tenant, but let’s cover a few more points on service principals before moving forward.
A service principal object is created in every tenant where the application is used. This image shows the service principal objects that are created based on the application object and live in their respective tenants.
This is how Microsoft explains the relationship between an application object and the service principal(s):
The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant. The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects.
This service principal defines things like:
- Which can use the app
- What resources the app can access
- The apps' visibility in MyApps
Users and admins in the customer’s tenant control the service principal that is registered. This ensures that the application has the necessary permissions that the third-party requires while also giving the customer’s Azure admin the ability to manage things like:
- Which users/groups can access the app
- The visibility of the app in MyApps
This is covered in more detail in the section Properties of the Service Principal.
To summarize, creating an application in Azure substantiates:
- an object that contains the developer-owned configurations (corresponding to the application object in the App Registration), and
- an object where the application’s instance in a tenant is managed (the Service Principal object in the Enterprise Applications blade).
In some documentation online, you will see the terms Service Principals and Enterprise Applications used interchangeably. The remainder of this article will focus on the object that is created in the customer’s tenant and is owned and controlled by the customer; we will call this the Service Principal.
How Service Principals (Enterprise Applications) are created
Let’s look at how this works, using Alteryx’s application (application object) as an example.
image.jpeg
Step 1
Alteryx created a multi-tenant application that lives in the Alteryx tenant. This application is configured with the settings that Designer needs in order to connect to the Azure resources; this includes things like the Redirect URL, the logo, certain permissions, etc.
Step 2
A user from Company A drags a Sharepoint tool onto the canvas in Designer and selects “Sign in with Internet browser” in the configuration window. This opens the user consent prompt in their browser.
image.jpegThe permissions our application requires are shown in this consent prompt. By default in Azure, all users are allowed to consent to applications for permissions that don't require administrator consent. See Microsoft’s documentation for more details: How and why apps are added to Azure AD - Microsoft Entra | Microsoft Learn.
Depending on the settings configured in Company A’s tenant OR the permissions requested, an admin may be required to consent. This will be discussed in more detail later in the section Understanding Admin Consent.
Step 3
Once that is accepted and the user or admin logs in, a service principal is created in Company A’s tenant.
Once this is complete, by default, all users in Company’s A tenant will be able to access this application from Designer. A service principal that points back to our application has been created. The name of this service principal is the same as our application - “Alteryx Analytics Connector”.
Understanding the Alteryx Analytics Connector
For this section, we will assume that consent was granted and the service principal was created in the customer’s tenant.
Our application is called the Alteryx Analytics Connector. If you have access to the Azure portal, you can find your service principal by following these steps:
- Log into portal.azure.com
- Search for "Enterprise Applications"
- On the "All applications" page, search in the search box for "Alteryx Analytics Connector" (see image below)
Alternatively, you can search using the Application ID: d6a8f12f-84ed-45f6-90a3-b04c43f8ca09.
This application ID is a reference to the application object in Alteryx's tenant, which is why the ID is the same for all the respective service principals. Notice the Object ID is greyed out - this is because this is the unique Object ID for the service principal (so I’ll keep this private).
If you cannot find this Application ID, remember that the service principal cannot be created in your tenant if a user or admin has not first consented to the application! The user may not have provided consent, or an admin consent may be required.
Properties of the Service Principal
Once you are on the service principal’s page, you can view the Properties of the service principal in your tenant.
As the application object is created and managed in the home tenant (Alteryx’s tenant) only some of the properties are configurable in the customer’s tenant. Some things, like the Name of the application, cannot be changed.
image.pngEditable properties
| Property Name | Description from Microsoft | Link |
|---|---|---|
| Enabled for users to sign-in? |
| Properties of an enterprise application - Microsoft Entra | Microsoft Learn |
| Assignment required? |
| Properties of an enterprise application - Microsoft Entra | Microsoft Learn |
| Visible to users? |
| Properties of an enterprise application - Microsoft Entra | Microsoft Learn |
| Notes | You can use this field to add any information that is relevant for the management of the application. The field is a free text field with a maximum size of 1024 characters. | Properties of an enterprise application - Microsoft Entra | Microsoft Learn |
Required Permissions
The permissions required will be listed in the consent prompt when the first user (or an admin) connects. After the service principal is registered in your tenant, any users with portal access can review these permissions from the Enterprise Applications page > Security “Permissions” tab on the left.
image.jpegNOTE: The image above does not show all the permissions required for this app. Refer to the tool's documentation for an accurate list for the tool you are using.
One common question is, “Does this mean that all users will be able to access this data across the entire tenant?”.
For example, the application requests the permission
Files.Read.All - does that mean that any user who accesses this application will be able to read all files in the tenant?This is where the concept of delegated permissions comes in.
How do Delegated permissions work?
Even if an app is approved (including via admin consent), this means that any user will be able to sign in, but the application can only access the data for that user. Learn more about delegated permissions here: Microsoft identity platform delegated access scenario - Microsoft Entra | Microsoft Learn
All the permissions requested by the Alteryx Analytics Connector application are delegated permissions.
If this is still not secure enough according to your administrator, and they wish only to allow specific users to access the application at all, they can change the property “Assignment required?”. See the Editable Properties section for more information.
Understanding Admin Consent
You can grant tenant-wide admin consent by configuring the service principal, if the application has already been provisioned in your tenant. As we learned, the application could be provisioned in your tenant if at least one user has already consented to the application. This is completely dependent on the configuration of your tenant.
image.jpeg
However, some access requests can only be approved by an admin. Additionally, your tenant could be configured to block users from being able to consent to applications, meaning that only admins can consent to new applications.
In this case, the consent prompt will show this:
Since a non-admin user cannot proceed further past this prompt, the service principal is not created in the tenant because consent cannot be granted. This means your admin will not be able to find it in your tenant.
So how does a non-admin user proceed? Unfortunately, this may not be straightforward. Azure acknowledges this in their documentation:
The above example dialog shows the default (out of the box) experience for permissions that require admin consent. Most users don't know what to do in this scenario. They don't know who their admin is, they don't know who to go to for approval. This uncertainty can limit the user's ability to achieve desired results.
Additionally, there is no way for us (Alteryx) to know if admin consent is required in your tenant for any given application:
you never know which permissions will require admin consent and which allow a regular user to grant consent because tenant admins can configure their tenant with Do not allow user consent (all permissions require admin consent)
Here are a couple of different experiences to highlight this point:
- Tenant A has configured “Do not allow user consent”. This means that all non-admin users will receive the “Need admin approval” prompt when they access a new application.
- Tenant B has configured “Users can consent to all applications”. This option allows all users to consent to any permissions that don't require admin consent, for any application. However, if the application requests a permission that only admins can consent to, the users will still be presented with the “Need admin approval” prompt.
See Microsoft’s documentation for full details: Overview of user and admin consent - Microsoft Entra | Microsoft Learn
Microsoft’s answer to this is the “admin consent workflow”. This can be enabled in your tenant by an admin. See Requesting permissions that require administrative consent | Microsoft Learn.
This turns the unfriendly prompt above into a more friendly window that allows users to provide a justification that is sent directly to the admin.
Without this configured, it is up to the user to locate their Azure admin and ask for approval. Typically, we suggest you reach out to your helpdesk or IT contact to identify your admin.
Additional Resources
- Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn
- Manage consent to applications and evaluate consent requests - Microsoft Entra | Microsoft Learn
- Apps & service principals in Azure AD - Microsoft Entra | Microsoft Learn
- How and why apps are added to Azure AD - Microsoft Entra | Microsoft Learn
- Properties of an enterprise application - Microsoft Entra | Microsoft Learn
