Information technology tools and resources at the UW
Azure AD Applications
Azure AD applications are an identity which allows software to take advantage of Azure AD capabilities.
|Topics on this Page:||Related pages you might be interested in:|
What you Might Need to Know as a User of an Azure AD Application
As a user of Azure AD, you might need an Azure AD application. These will typically be one of three types of scenarios:
- You would like to use 3rd party software via Azure AD
- You are a developer writing software and want to integrate via Azure AD
- You would like to leverage an Azure AD capability for your existing software
Using 3rd party software via Azure AD
You’ve found a 3rd party software that needs to be integrated with the UW’s identity system and possibly also integrated with other Azure AD applications. This may be a web application, a phone “native” app, or even an Office add-in which also has an installable download.
There are usually two steps:
Adding software as an Azure AD application
The details about how a user might self-provision an Azure AD application identity happen to differ greatly depending on the application (just as it does for integration with any other identity solution), and it isn’t always obvious to users when Azure AD is involved.
- Microsoft has a gallery/catalog of more than 3000 “pre-integrated” SaaS applications, where they’ve already done the hard work to connect whatever authentication that software uses to Azure AD authentication. This means the UW identity integration cost is minimal. In some cases, the Azure AD integration even handles user provisioning in the 3rd party web application’s custom user system, meaning you don’t have to do that work separately. Many of the 3rd party applications in that gallery require you to separately establish a customer relationship with the vendor and in such cases you many need to restrict user assignment of the applications to those you are willing to pay for. There are some additional costs associated with restricting assignment, so you are encouraged to first talk with UW-IT about that kind of scenario.
- Other vendors may not be in Microsoft’s gallery/catalog, but do enable you to create the necessary Azure AD application identity to enable UW use by clicking to enable/install them. The software which uses that identity may be on your local computer or on a web site. One innocuous example of this is an Office Add-on called FindTime. Not all of these kinds of ‘click to enable’ Azure AD application identities are located in the Office Store.NOTE: If you try to enable FindTime before we’ve changed our AAD settings to allow user self-provisioning of AAD apps, you will eventually be told you don’t have permissions to do so. After we make that change, you should be able to enable FindTime without issue.
Some Azure AD applications require an admin to grant permissions before they can be created.
If you choose to add or consent to an Azure AD application provided by a third party, there is a risk that UW confidential data may intentionally or unintentionally be accessed, collected, or used by the third party. UW organizations are responsible for evaluating the risk and implementing controls for their unique technical deployments.
If you’ve evaluated the risk and decided to use a third party application, then it should meet the UW data security and privacy goals for contracting with vendors. This may include the need for a Data Security and Privacy Agreement or a Business Associate Agreement. Additional responsibilities may be required by UW Medicine for use of Azure AD applications with protected health information. If you’d like help analyzing third party applications or adding an Azure AD application, please contact UW-IT at firstname.lastname@example.org.
Consenting to the permissions an Azure AD application requires
When a user tries to access an Azure AD application identity that requires permissions to other Azure AD applications, a user consent prompt is presented. This prompt is provided by Microsoft, not the 3rd party.
The prompt contains a list of the permissions requested by the application, and the user can accept or decline. Acceptance results in permissions granted and recorded for that user. Declining blocks access to the Azure AD application.
Users working with confidential data are strongly encouraged to take care about consenting to permissions when the application you are granting access to lacks proper controls.
If you aren’t sure, you should ask for help by contacting UW-IT at email@example.com.
Some example screen shots of this experience:
Developer integration via Azure AD
You are a developer writing software. You either need to leverage the API of an Azure AD application or you need to authenticate users and would like to use the modern protocols that Azure AD supports.
Microsoft’s Integrating applications with Azure Active Directory is a good introductory resource for developers seeking to integrate using an Azure AD identity. Developers seeking to leverage Microsoft Graph or Office 365 APIs may find this TechNet article useful. There is now also a preview Azure AD PowerShell module which allows creation and manipulation of Azure AD applications.
Augment your existing software with Azure AD capabilities
You have some existing software which you’d like to benefit from one of the capabilities that Azure AD provides. The most likely capabilities you might want to leverage are: Azure AD Conditional Access, Azure MFA, Azure AD logging and security reporting, single sign-on for a scenario that allows an existing Integrated Windows Authentication web app (this capability is called Azure AD Application Proxy), or simply having your application listed in a user-focused application portal which has single sign-on like benefits.
Azure AD application which require admin approval
Some Azure AD applications require permissions which other applications have defined to require an Azure AD tenant admin to explicitly approve. These applications can not be added by a user by themselves.
Additionally, there may be additional permissions which the UW decides are risky, even if vendors don’t identify them. When we detect an Azure AD application which has those risky permissions, we will disable that Azure AD application and it will go through a risk evaluation & acceptance process like the one required for Azure AD applications that require a Azure AD tenant admin to explicitly approve them.
If you think you have such an Azure AD application, you can use the request form for that.
If you’d like to read more about what UW considers risky Azure AD permissions and how you might request a change to what we consider risky, please see our Risky Azure AD application permissions page.
Microsoft endorsed Azure AD applications
In addition to these scenarios, there is another type of Azure AD application, which is mostly commonly called a “first person” application. These are Azure AD applications that Microsoft provides, like Exchange Online. These Azure AD applications sometimes don’t follow the guidelines noted above, and there may be extra limitations or per user licensing required.
‘Modern Authentication with Azure Active Directory for Web Applications‘ by Vittorio Bertocci