OMA
Office of Modern Architecture

Enterprise Architecture (EA) Mandates

Introducing three mandates that expand and support three of our Enterprise Architecture (EA) Principles. Here, you’ll find explicit guidance on what’s most important for modern solutions and links to information and resources you can use to begin implementing them today.
About the MandatesAPI/ServicesAuthenticationModern Platform

Authentication

What does it mean?

Effective July 1, 2018, all new applications and major upgrades to existing applications must implement modern authentication.

End-user authentication via Single Sign-On (SSO):

  • Custom developed applications must use OpenID Connect (OIDC).
  • For SaaS or purchased software, OIDC is preferred, but SAML 2.0 is acceptable (and most common).
  • Under no circumstances is Integrated Windows Authentication (NTLM, Kerberos) to be used for end-user SSO for new applications or major upgrades to existing applications.

Additional Clarifications

  • Basic Authentication (username/password) may be used for break-glass administrative scenarios where the password is securely stored in a secrets management platform such as ITPA, but under no circumstances should Basic Authentication be used for end-user sign-in
  • The mandate is meant to cover initial/perimeter application authentication. How user context is propagated to downstream systems is not a consideration of the mandate.

Additional guidance (not mandated) for authenticating Service-to-Service integrations is described below.

Service-to-Service integrations (in order of preference):

  • TLS Mutual Authentication (2-Way SSL)
  • OAuth 2.0 Client Credentials Grant (certificate)
  • OAuth 2.0 Client Credentials Grant (secret)

--- BELOW SHOULD BE AVOIDED FOR HIGH RISK APPLICATIONS ---

  • (non-OAuth) Client_ID / Secret
  • Username / Password
  • API Key

Additional Clarifications

  • For service-to-service integration, the most secure (but most cumbersome) method of authentication is TLS Mutual Authentication (2-way SSL).
  • The next acceptable method would be OAuth 2.0 Client Credentials Grant with certificate or secret.
  • The least secure and least acceptable methods would be (non-OAuth) client_id/secret, username/password, or API keys.
  • API Keys should be avoided as the sole method for API authentication as they are publicly accessible by clients and provide very weak controls/assurance.

Why is Authentication important?

To enable SSO access to the Cloud (IaaS, PaaS, SaaS), we need to use SSO protocols and tokens that can work across security domains. The general term for cross-security domain SSO is “identity federation.” Identity federation is achieved via a technical trust relationship, based on public key cryptography, between the identity provider and the service provider(s).

The bottom line is that the Windows-based SSO protocols we use for our internal security domain are not used nor understood by the cloud. As a consequence, applications that use those SSO protocols are not Cloud-ready. To address this, all applications (whether on-prem or in the Cloud) must use modern cross-domain SSO protocols to ensure that the authentication for the application is Cloud-ready. If we don’t do this, we will continue to build “technical debt” that must eventually be dealt with as we migrate applications and services to the Cloud.

Other benefits to using modern single sign-on authentication:

  • It provides a distinct policy enforcement point
  • Application developers don’t have to develop a separate authentication flow with each identity provider

What technologies can I leverage to meet this requirement?

  • Azure Active Directory (AAD) should be used for modern authentication with the OAuth 2.0, OIDC and SAML 2.0 protocols.
  • System for Cross-Domain Identity Mangement (SCIM) should be used for automated provisioning of accounts in SaaS platforms where possible.
  • Depending on the use case, Azure AD B2C or Ping Federate may be used to provide authentication services to eBusiness DMZ or public-facing applications.

What resources are available to help me learn more?

The following resources are available to start learning about building modern authentication protocols into a solution.

Still need help? Get answers on HiveMind

Who can I talk to for support?

The Public Cloud Team supports and operates Azure AD and ADFS while the Gateway / Authentication Team is responsible for consulting on modern authentication using Azure AD and ADFS. To request a consult, send an email to the Modern Auth Consulting shared mailbox.