Sovereign clouds continued… 

This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on sovereign clouds. This article talks about Azure AD authentication in National clouds.  

National clouds are physically isolated instances of Azure. The difference between Commercial, GCC and GCC High Microsoft 365 environments is important to correctly align the compliance needs of the businesses. Commercial Microsoft 365 is the standard Microsoft 365 cloud used by Enterprise, Academia and even home Office 365 tenants. It has the most features and tools, global availability, and lowest prices. Since it’s the default choice between the clouds, everyone qualifies and there are no validations. Some security and compliance requirements can be met here using tools like Enterprise Mobility and Security, Intune, Compliance Center, Cloud App Security, Azure Information Protection, and the Advanced Threat Protection tools. Some compliance frameworks can also reside in the commercial cloud, and these include HIPAA, NIST 800-53, PCI-CSS, GDPR, CCPA etc. but not government or defense compliance because the cloud shares a global infrastructure and workforce. Even some FedRAMP government compliance can be met in the commercial cloud, but it will be heavily augmented with existing tools and will require finding and patching gaps. 

Each cloud instance is separate from the others and has its own environment and endpoints. Cloud specific endpoints include OAuth 2.0 endpoints, OpenID Connect token request endpoints and URLs for app management and deployment which means an entire identity framework is local to the cloud instance. There’s even a separate Azure portal for each national cloud instance.

Applications can continue to use modern authentication in Azure Government cloud but not GCC High. The identity authority can be Azure AD Public and Azure AD Government.  

Applications can integrate with the Microsoft identity platform in a national cloud but they are required to register their application separately in each Azure portal that’s specific to the environment.

The workflow for authentication is claims based. A claims challenge is the response sent from an API indicating that an access token sent by a client application has insufficient claims. It could be due to one of many reasons such as conditional access policies not met for the API or the access token has been revoked. A claims request is made by the client application to request the user back to the identity provider to retrieve a new token with claims that will satisfy the additional requirements that were not met. Applications must declare the client capabilities in their calls to the service. Then they can use enhanced security features and must be able to handle claim challenges. This is usually presented via a www-authenticate header returned by the service API.

The MSAL library provides the following sample to communicate the client capabilities:

_clientApp = PublicClientApplicationBuilder.Create(App.ClientId)

 .WithDefaultRedirectUri()

 .WithAuthority(authority)

 .WithClientCapabilities(new [] {"cp1"})

 .Build();

 An API implementer can receive information about whether client applications can handle claim challenges using the xms_cc optional claim in the application manifest.