[Feature Request] Improve sovereign cloud support for the new clouds (fr, de, sg)

[bgavrilMS]

MSAL client type

Confidential, Public

Problem statement

MSAL must keep all HTTP requests in the same cloud for the publicly known clouds. However, today MSAL will perform instance discovery, which in some cases goes to the global cloud, i.e. login.microsoftonline.com

The proposed solution is for MSAL to keep a list of known clouds. If the authority host matches a known host, then instance discovery should occur on that host.

Below is list of known cloud hosts. This is partially available here

"Public"
"login.microsoftonline.com" <-- use this for instance discovery
"login.windows.net",
"login.microsoft.com",
"sts.windows.net"

"PPE"
"login.windows-ppe.net",

"Fairfax",
"login.microsoftonline.us",

"Mooncake",
"login.partner.microsoftonline.cn" <-- use this for instance discovery
"login.chinacloudapi.cn"

"Bleu",
"login.sovcloud-identity.fr",

"Delos",
"login.sovcloud-identity.de",

"GovSG",
"login.sovcloud-identity.sg",

Notes:

• MSAL.NET already does for most clouds, it just needs to be updated for Bleu, Delos and GovSG - see https://github.com/AzureAD/microsoft-authentication-library-for-
  dotnet/blob/main/src/client/Microsoft.Identity.Client/Instance/Discovery/KnownMetadataProvider.cs#L47

• Instance discovery should continue to be performed for discovery of aliases

Acceptance tests

1. Authority: "login.microsoftonline.com/tid". Instance discovery expected on: login.microsoftonline.com
2. Authority: "login.microsoft.com/tid". Instance discovery expected on: login.microsoftonline.com
3. Authority: "login.partner.microsoftonline.cn/tid". Instance discovery expected on: login.partner.microsoftonline.cn
4. Authority: any of the list above. Instance discovery not expected on login.microsoftonline.com
5. Authority not on the list above. Instance discovery expected on login.microsoftonline.com

Original issue:

AzureAD/microsoft-authentication-library-for-dotnet#5630