Consent flows for applications integrated with the Microsoft Information Protection SDK

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 3rd 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.Auth Window.pngFigure 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 credentialsrememberpwd.pngFigure 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:


user consent permission requested.pngFigure 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.


Enterprise Applicatio directory.pngFigure 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. Admin consent.pngFigure 5: Administrator approving consent


 


Clicking Accept here completes the organizational consent.Admin permission acceptance.pngFigure 6: Administrator Consent acceptance


 Approved Consent.pngFigure 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.admin consent dialog.pngFigure 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:admin consent error message.pngFigure 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.


 


 


 


 


 


 


 


 


 


 


 


 


 


 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.