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.
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 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.
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 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:
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.
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.
Clicking Accept here completes the organizational consent.
In some organizations, the administrator may have blocked user consent to applications via the Enterprise applications settings blade in Azure Active Directory.
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:
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.