Use tenant-specific authority instead of organizations in certain tests#909
Use tenant-specific authority instead of organizations in certain tests#909Avery-Dunn wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR reduces flakiness in MSAL Python’s end-to-end OBO integration tests by avoiding the multi-tenant /organizations authority during the initial ROPC step, instead using the tenant-specific authority associated with the lab user (user.authority).
Changes:
- Updated
test_acquire_token_oboto useuser.authority(tenant-specific) for the PCA ROPC token acquisition step. - Updated
test_cca_obo_should_bypass_regional_endpoint_therefore_still_workto useuser.authority(tenant-specific) for the PCA ROPC token acquisition step. - Removed an outdated comment referencing a Java test using the
/organizationsauthority.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| WEB_APP_CLIENT = "App-WebAPP-Config" | ||
| B2C_CLIENT = "MSAL-App-B2C-JSON" | ||
| CIAM_CLIENT = "MSAL-App-CIAM-JSON" | ||
| ARLINGTON_CLIENT = "MSAL-App-Arlington-JSON" | ||
| OBO_CLIENT_SECRET = "IdentityDivisionDotNetOBOServiceSecret" |
| "authority": user.authority, | ||
| "client_id": s2s_app.app_id, | ||
| "username": user.upn, | ||
| "password": password, | ||
| "scope": ["api://%s/access_as_user" % web_api_app.app_id], | ||
| "scope": [web_api_app.defaultscopes], |
| "client_id": web_api_app.app_id, | ||
| "client_secret": get_secret(web_api_app.client_secret, vault="msal_team"), | ||
| "scope": ["https://graph.microsoft.com/.default"], | ||
| "client_secret": get_secret( | ||
| AppSecrets.OBO_CLIENT_SECRET, vault="msal_team"), | ||
| "scope": ["User.Read"], |
| "authority": user.authority, | ||
| "client_id": s2s_app.app_id, | ||
| "username": user.upn, | ||
| "password": password, | ||
| "scope": ["api://%s/access_as_user" % web_api_app.app_id], | ||
| "scope": [web_api_app.defaultscopes], |
| "client_id": web_api_app.app_id, | ||
| "client_secret": get_secret(web_api_app.client_secret, vault="msal_team"), | ||
| "scope": ["https://graph.microsoft.com/.default"], | ||
| "client_secret": get_secret( | ||
| AppSecrets.OBO_CLIENT_SECRET, vault="msal_team"), | ||
| "scope": ["User.Read"], |
| """ | ||
| user = get_user_config(UserSecrets.PUBLIC_CLOUD) | ||
| password = get_user_password(user) | ||
| s2s_app = get_app_config(AppSecrets.S2S_CLIENT) |
There was a problem hiding this comment.
Could we add a short comment explaining why s2s_app is used here instead of web_api_app? Something like "S2S client supports ROPC with tenant-specific authority; web_api_app is a resource app" would save the next developer a round-trip to Key Vault to figure out the relationship.
|
@Avery-Dunn Do we still needs these changes to test? |
Two OBO integration tests (
test_acquire_token_oboandtest_cca_obo_should_bypass_regional_endpoint_therefore_still_work) intermittently fail with: ``AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.`These were the only automated ROPC tests using the multi-tenant
/organizationsauthority. With/organizations, AAD must perform home-realm discovery to route the request to the correct tenant, and this additional routing context can cause risk-based Conditional Access policies to intermittently block the sign-in — particularly in CI environments with shared IPs and high sign-in frequency.This PR switches both tests to use the tenant-specific
user.authority, matching the pattern used by every other passing ROPC test. The OBO flow itself is unaffected — only the authority used to obtain the initial user assertion changes.