Support authentication against PPE AAD login endpoint

[v-dchandana]

Hi Team,

We are trying to implement accessibility task for PPE and Prod websites for MPN offers. We are able to identify prod website bugs but we are not able to identify the bugs in PPE and every time it is successfully running.

Pipeline link: https://microsoft.visualstudio.com/Universal%20Store/_build/results?buildId=70508803&view=results

We cannot implement this unless PPE will identify the bugs. As a development process it need to identify bugs in PPE first then we can able to proceed to prod.

Can you please prioritize this.

Thanks,
Dasari Chandana.

[dbjorge]

Clarifying and updating title based on support thread from a few weeks ago. Internal folks can find more context by searching for support thread titled "Onboard to Accessibility Insight Shift-Left Solution for PC Membership - Offers [Web]".

The issue here is that the PPE site in question is authenticating against the PPE AAD login endpoint, login.windows-ppe.net, rather than the usual production AAD login endpoint, login.microsoft.com. The service's /packages/crawler/src/authenticator/azure-active-directory-authenticator.ts only currently supports the production login endpoint (in that that's the one you get when doing the initial auth flow against portal.azure.com). The page under test ends up redirecting to a https://login.windows-ppe.net/... URL and scanning that, rather than using the intended auth flow.

I think the preferred path for enabling this would probably be adding a new authType option for AAD-PPE or similar. The other options that come to mind might be to either add a new subparameter for AAD login endpoint (where the user could pass login.windows-ppe.net themselves) or to add an option to infer it based on where the page redirects to, but I'm not a fan of either of those options since I think it makes it too easy for a user to accidentally specify something that might result in the scanner entering credentials into an unexpected place.

This would involve work in both the action and service repos. Note that the service repo currently has two diverged auth paths, for reasons that I'm not super clear on - I think the one that the action is going through lives in /packages/crawler/src/authenticator/ and the one that WCP goes through lives in /packages/scanner-global-library-src/authenticator/. It would be good to re-evaluate whether these paths can be merged as part of implementing this to ensure that WCP and AI4ADO maintain feature parity.

[microsoft-github-policy-service]

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

[v-dchandana]

Hi Team,

Could you please provide any update on above.

Thanks,
Dasari Chandana.

[JGibson2019]

@joestegman425 tagging you here to consider as we do more shift left work