News and events Own Your Online External Link Report an incident
News and events Own Your Online External Link
  1. Welcome to CERT NZ
  2. Information and advice
  3. Technical guides
  4. Cloud-based identity providers and authentication

Cloud-based identity providers and authentication

Using single sign-on with a large cloud identity provider allows your users to protect fewer passwords and your IT staff to manage fewer accounts. By nature it needs to allow for multiple different authentication protocols. It’s important those authentication methods are secured.

People today use a lot of cloud-based applications, like software-as-a-service (SaaS), which means they have to protect a lot of passwords. Your organisation may use a central authentication point that links into each of these cloud-based applications so a user only has to remember one set of credentials. For example, you may use Office 365 or Google Cloud Identity as your central authentication, or your identity provider. Your staff can then log into different accounts using those central authentication credentials.

Your organisation might have hybrid systems, or systems that are hosted on-premise and in a cloud network. For example, you may use Active Directory (AD) for managing user accounts on-premise, and this may be synced with Azure AD or you may use AD Federated Service so those same accounts can access Office 365.

There are a lot of benefits to using these types of cloud-based, central identity providers. It reduces the amount of passwords your staff have to remember, and it makes managing user access for each of those systems easier.

Purpose

The intent of this control is to ensure that organisations have secured all authentication methods for any central identity provider they use.

Measuring success

There are different ways to configure the use of a central identity provider. Regardless of the method used, the goals of this control are:

  • secure, up-to-date encryption, protocols and frameworks are used for all connected systems
  • all legacy protocols and frameworks are disabled by the central identity provider
  • multi-factor authentication (MFA) is enforced by the central identity provider for all accounts
  • all protocols and frameworks that do not support MFA are disabled by the central identity provider
  • logging is enabled for all authentication attempts and administrative actions. The logs are securely recorded and stored in a central location.

Key cloud authentication takeaways

  • The choice to use a central identity provider is up to the business. Whatever the decision is, there are ways to make sure that decision is carried out securely. For example, if you opt not to use a central identity provider and instead have users keep track of multiple passwords, you should make sure your staff use a password manager and configure MFA for each of those accounts.
  • As you integrate more business systems with a single identity provider, the risk of account compromise increases, as a single account may give access to a variety of systems. CERT NZ sees many incidents that stem from successful phishing of these accounts, most commonly when MFA is not appropriately configured.
  • Using a central identity provider can help you protect cloud accounts that don’t offer MFA. This is because MFA would be enforced at the identity provider level, not the application level.

Integrating multiple authentication systems is often a complex process. Test each system carefully to ensure it is configured securely and in the best way to support the business needs.

Advice for implementation

Configuring central identity providers