Showing webcp flow in webview , Fixes AB#3135912

[somalaya]

Intune's support for web enrollment for Android is scheduled to GA in Q3 CY2025.
For the many customers who set up conditional access, users enter the web enrollment flow by being blocked from accessing a productivity app such as Teams or Outlook.

From that block page, they are pushed out of their productivity app and sent to the default browser app on their Android device where they see a Company Portal website (webCP) page, which guides them to Settings where they can enroll in Intune management.

Problems

The problems with showing webCP in the browser app is:

1. Additional sign in: During enrollment, it adds an additional authentication for the user (2nd auth for iOS and 3rd for Android).
2. Context change: It is a jarring experience, taking the user out of the context of the productivity app and into the browser app, which can be disorienting.

See snapshot below for current experience with WebCP flow enabled

Note, the highlighted green pages indicate the 3 times the user must authenticate during this flow.

The flow:

1. The user signs-in to the productivity app and is blocked by MDM CA.
2. The user must select the “Continue” button on the MDM CA page (which indicates they need to register their device).
3. The user is navigated to WebCP in the browser, where they must sign-in again.
4. The user is shown a page to kick-off WP enrollment directly from the browser. The user must select the button to “Get started”.
5. The user is taken through the Google screens for creating the Work Profile.
6. The user lands
7. The user completes the enrollment flow in the Work Profile version of the Company Portal.

Fix
Showing webcp in webview when user clicks on continue button on CA block page.
So with the fix, the screen shown in red in step 2 in below snapshot is removed

Fixes AB#3135912

Related broker PR : https://github.com/AzureAD/ad-accounts-for-android/pull/3130

[github-actions]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[Copilot]

Pull Request Overview

This PR enables showing the Company Portal (webCP) enrollment and authorization flows inside an in-app WebView rather than redirecting to the external browser.

• Added new OpenTelemetry span names and attributes for webCP flows.
• Introduced a flight flag to toggle webCP-in-webview behavior.
• Replaced the cross-cloud PRT header challenge handler with a generalized ReAttachPrtHeaderHandler and updated URL handling in the WebView client.

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
common4j/src/main/com/microsoft/identity/common/java/opentelemetry/SpanName.java	Added ProcessWebCpRedirects span name
common4j/src/main/com/microsoft/identity/common/java/opentelemetry/AttributeName.java	Added is_webcp_* attributes
common4j/src/main/com/microsoft/identity/common/java/flighting/CommonFlight.java	New flight ENABLE_WEB_CP_IN_WEBVIEW
common/src/main/java/com/microsoft/identity/common/internal/ui/webview/challengehandlers/ReAttachPrtHeaderHandler.kt	Renamed and generalized challenge handler
common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java	Handle webCP enrollment and authorize URLs in WebView
common/src/main/java/com/microsoft/identity/common/adal/internal/AuthenticationConstants.java	Defined WEBCP_ENROLLMENT_URL and WEBCP_AUTHORIZE_REDIRECT_URL
common/src/test/java/com/microsoft/identity/common/internal/ui/webview/challengehandlers/ReAttachPrtHeaderHandlerTest.kt	Updated tests for renamed handler
common/src/test/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClientTest.java	Updated imports, added enrollment test

Comments suppressed due to low confidence (6)

common4j/src/main/com/microsoft/identity/common/java/opentelemetry/AttributeName.java:374

• The Javadoc for is_webcp_enrollment_request is incorrect (it duplicates the authorize description). Please update it to clearly describe the enrollment request.

* Records if the request is a webcp authorize request.

common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java:120

• [nitpick] This constant holds a number of seconds but is named *_MS. Consider renaming to THREAD_SLEEP_FOR_INTENT_LAUNCH_SECONDS for clarity.

private static final int THREAD_SLEEP_FOR_INTENT_LAUNCH_MS = 3;

common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java:90

• The code uses new Handler() in processWebCpEnrollmentUrl but android.os.Handler is not imported. Please add import android.os.Handler;.

// imports include TimeUnit but no Handler

common/src/test/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClientTest.java:226

• [nitpick] The variable name mockCrossCloudChallengeHandler no longer matches its type ReAttachPrtHeaderHandler. Consider renaming the variable to mockReAttachPrtHandler for consistency.

ReAttachPrtHeaderHandler mockCrossCloudChallengeHandler = Mockito.mock(ReAttachPrtHeaderHandler.class);

common/src/test/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClientTest.java:223

• You added an enrollment URL override test, but there's no corresponding test for the new WebCP authorize URL flow. Consider adding a testUrlOverrideHandleWebCPAuthorizeUrl() to cover that branch.

@Test public void testUrlOverrideHandleWebCPEnrollmentUrl() {

common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java:332

• After handling the WebCP enrollment URL, the method does not return immediately, which may cause unintended fall-through. Consider adding an explicit return true; (or appropriate return) here.

processWebCpEnrollmentUrl(view, url);

[github-actions]

✅ Work item link check complete. Description contains link AB#3135912 to an Azure Boards work item.

[mohitc1]

path.contains("/authorize")

startswith?

[mohitc1]

[shahzaibj]

What are we showing on screen while waiting? I hope a spinner is there

[somalaya]

This wait is for not immediately killing the existing webview which would have previous URL loaded and just looks like its buffering.

1. When the google enrollment page is immediately opened before 3 secs, this would not even be visible because it automatically opens up the enrollment intent.
2. When its slower than 3 secs, I don't think we can do much, we will have to kill the webview as we don't want the user to be waiting on the same old URL for a long time.

A similar wait time is present in existing code if you want to get a reference in method processInstallRequest of same class.