Consent flows for applications integrated with the Microsoft Information Protection SDK

[Kartik Kanakasabesan]

In this blog we'll cover the different flows to consent for applications that leverage the MIP SDK. The example application we will use throughout the blog will be Adobe Acrobat Reader.

When developing applications with the MIP SDK, the MIP SDK does not come with an authentication library. Rather, the authentication delegate pattern allows a developer to implement their preferred authentication library; ADAL is preferred to get the authentication token or you can use a 3^rd party OAuth2 library.

Consent Flows

There are two key types of consent flows in the context of applications working with AAD. Application consent is not unique to the MIP SDK; it is required for all applications integrating with AAD. The two types of consent flow we are going to explore are:

• User Consent
• Administrator Consent

User Consent Flow

User Consent is a one-time consent for the user within a tenant to use the application only for the user in question. If a second user wants to use the application, then the second user must consent for the application as well. For more details on application consent and scenarios please view the following link: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-types

In this example a user opens Adobe Reader to view a labeled and protected document.Figure 1: Application Authentication Window

Once you supply the email address, the application will attempt single sign on. If this fails or isn’t possible, you will have to provide your AAD credentials. Once you have authenticated the Adobe application asks the user to cache their credentialsFigure 2: Application giving choice of caching the credentials

Select yes, or you continue to provide your password every time you open a new protected document.

Since this is the first time you are opening the document, you will be prompted to consent for the application within your tenant. This is what the user will see:

Figure 3: User consent permission requested

Click Accept and proceed forward. If the user accepts, this consent will be displayed just once, unless the application provider modifies the set of required permissions.

Once the user consent is finalized, the tenant administrator will see following in the Azure Active Directory portal.

Figure 4: Enterprise Application Directory

The tenant administrator sees the user consented application and its application ID. The tenant administrator may decide to grant consent for the entire tenant for an application. This suppresses the consent prompt for all users in the tenant as the administrator has consent on their behalf. Figure 5: Administrator approving consent

Clicking Accept here completes the organizational consent.Figure 6: Administrator Consent acceptance

 Figure 7: After Administrator consent, what capabilities have been accepted

Administrator Consent flow

In some organizations, the administrator may have blocked user consent to applications via the Enterprise applications settings blade in Azure Active Directory.Figure 8: User Consent settings dialog

This restriction prevents a user from consenting to applications that haven’t been explicitly approved. A user will see the error below when trying to provide consent for an unregistered application:Figure 9: Error message showing the need for Administrator consent needed for application to run in the tenant

To avoid this message for end users, a tenant administrator can take one of three actions:

1) Hit the explicit consent URL to trigger the admin consent flow. This specific URL can be used to trigger that flow.

https://login.windows.net/common/oauth2/authorize?response_type=id_token&client_id=cad2910c-3b55-4610-ba7e-dda581063c91&response_mode=form_post&nonce=a4014117-28aa-47ec-abfb-f377be1d3cf5&prompt=admin_consent

There's an example in the Skype SDK docs here. The 404 that is returned at the end is expected as Azure AD attempts to redirect the client to the invalid redirect URI.

2) Install the Adobe Reader DC application, add the Microsoft Information Protection plugin, then attempt to consume a protected document using a global administrator account.

Alternatively Administrators can consent without having the application installed by following these steps: https://docs.microsoft.com/en-us/skype-sdk/trusted-application-api/docs/tenantadminconsent

3) Temporarily disable the restriction, allow a user to consent, grant consent via the Azure Active Directory Portal, then enable the restriction.

You may be thinking: “Wait! There’s a fourth option!” And you’d be right. Some applications may not be published in the gallery. Once the vendor completes the publishing process and admin would be able to publish and consent from the gallery.