November 5, 2021

Are You who You say that You are?

Security blog series By Dwayne Natwick


Identity is the new perimeter

In our previous blog post, The Best Offense is a Good Defense, we explored the Defense in Depth security posture. Since within cloud services, the provider is responsible for the physical controls, identity and access become the first line of defense that a customer has the ability to configure and protect against threats.  This is why statements like, “Identity is the new control plane”, or “Identity is the new perimeter” have become popular when discussing cloud security.   

Even if your company maintains a private datacenter for the primary business applications, there is still a good chance that you are consuming a cloud application that uses your company identity.  For this reason, having the proper controls in place, such as multi-factor authentication (MFA), conditional access policies, and Azure Identity Protection, will help to decrease vulnerabilities and recognize potential threats before a wide-spread attack can take place. 

It starts with multi-factor authentication (MFA)

Passwords are a primary vulnerability and stolen passwords are the primary cause of security breaches. Unfortunately, there is nothing that can completely avoid a user password from being stolen and the majority of security breaches are caused by passwords that have been compromised.

If passwords are so insecure, then why do we continue to use them? The foundation of authentication and authorization has been built on the username and password concept. This means that applications that have been developed for years and years have utilized this concept, so re-writing these applications now is not an option.

How can we protect our users and make sure that a user is who they say that they are when authenticating? Since username and password authentication is not going away anytime soon, additional solutions should be utilized to protect identities and verify that a username and password being entered is from the person that it has been assigned. This can be done utilizing multi-factor authentication, or MFA.

Multi-factor authentication addresses the potential of a password to be compromised by requiring the user requesting access to provide an additional form of identification before they are authenticated and authorized access. There are three forms, or factors, of identification that are used for MFA, and MFA is configured to require any two of these three factors to verify a user’s identity. The three forms are:

Something you know

Something you have

Something you are

Figure 1 shows how this works.


MFA works together with conditional access policies to enforce zero-trust methods into our company. 

What is the Zero-Trust Methodology?

Protecting identities is a high-level of importance in securing a cloud infrastructure. Therefore, we need to make sure that a user that is requesting access to our resources is truly that user and not an attacker that has been able to gain access to that user’s credentials. It is important to understand the core concept that a company should adhere to when securing identity and access. This concept is the zero-trust methodology and the foundation of this methodology is exactly what it states: TRUST NO ONE!

The zero-trust methodology is a process of continuously requiring someone on the network to verify that they are who they say that they are. The concept seems to be straight forward and simple, but if you were to constantly ask users to enter their username and password, they would get frustrated. To avoid this frustration, zero-trust implementation utilizes various signals that alert potential anomalous behavior, leaked credentials, or insecure devices that trigger the need for a user to re-verify their identity. These signals lead to a decision on what is needed to provide access to applications, files, or websites. Figure 2 is a diagram that shows the zero-trust verification workflow. Within Azure AD, this is also how Conditional Access policies work.


Next, we will discuss each of the components of this workflow. 


The signal is the state that the user or device is in that trigger a potential need for a user to re-verify their identity.  This state could be that the user has been identified to be at risk of having a compromised password, that they are at an IP address that has been flagged as vulnerable, or that their device is not compliant with current security patches.  These are only a few examples of the signals that may be reviewed to trigger a decision to invoke the need for more information.  Microsoft utilizes several tools within Azure and Microsoft 365 to identify the vulnerabilities and risks of users and devices that create these signals.  Once a signal has been identified to require a more information to verify a user’s identity, then a decision is made as to what happens next.  


When a signal is triggered, a decision is made on what we are going to require or allow to provide access to the resources requested. There are several options here and this is where a company creates policies on how zero-trust is going to be handled depending on the resource being request access. This could include a user to re-verify that they have not been compromised by requiring multi-factor authentication (MFA) before they are given access. The policies may limit or block access to that application entirely until the user or device changes the status or location that they are requesting access. The least likely policy decision is to allow access if a user or device is seen in a risk status. The allow access decision is a policy generally used in a policy that identifies a user or device being in a trusted location. Once the decision is made within the policy, the policy then enforces the workflow.


The enforcement is the action of the decision based on the user or device signal as defined by the company policy. As stated in the previous section, there are multiple enforcements that could take place. The level of access and enforcement of zero-trust is usually dependent on the application and information being accessed. If the application contains highly sensitive information that the company cannot have exposed, the level of zero-trust enforcement should be at the highest level, by either blocking access, limiting the level of access, or requiring additional verification from the user, such as MFA and/or a password reset. The ability for a company to identify the risks and vulnerabilities of the users and determine a plan for protecting access to their applications is a critical factor to the success of implementing a zero-trust model for identity and access management.

As stated previously, the principles of zero-trust are an important aspect to protecting access to applications within a cloud and hybrid infrastructure. The decreased access and ability to protect physical access and the increased access to applications from various locations across public Internet connections requires a company to do their due diligence in identifying the various scenarios that users may request access to company resources and the numerous devices that they may use to access. Policies that identify the potential vulnerabilities and threats that can make a correct decision on how to enforce zero-trust will protect the company while maintaining a positive user experience.

These zero-trust principles all contribute to how we manage authentication and authorization, and plan for managing the principles of least privilege for user access.

Why is Principle of Least Privilege important?

When designing and scoping the company roles for IAM, the principle of least privilege should always be at the forefront of the discussion. This is the concepts that any user or resource only has access to the applications, resources, and information that they require to perform their specific job duties. Anything above that poses a vulnerability and potential threat to the company that sensitive information could be leaked to those that should not be allowed to view.

The scope of IAM is to manage that any user, group, or resource has been properly assigned roles and access that adheres to this principle. This should be properly documented by job title with role assignments, and the roles should be reviewed regularly with department owners to verify that the assignments are still accurate and valid. You must always be thinking about the principle of least privilege. This is the foundation of Identity and Access Management.

Now that we understand IAM and principle of least privilege, let’s look at how these concepts pertain to authentication and authorization.

What is the difference between Authentication and Authorization?

Authentication and authorization are key components of IAM and how we enforce the principles of least privilege.   Let’s take a closer look at each of these areas.  




Authentication is defined as the verification and validation of who you are.  This is generally accomplished with a username and password.  For additional security verification, we should use multi-factor authentication to make sure that the person entering in the username and password is who they say that they are.  This aligns with the zero-trust methodology.    

Once someone has authenticated to the systems that they are attempting to access, then authorization takes place.  Authorization verifies the permissions for that user and determines what they are allowed to do when accessing the company systems.  The authorization may determine that the person accessing is an administrator that has full access to view and make changes on the system or a user that can only view an application on the system.  Authorization to data on systems could even hide or mask sensitive data from being viewed by users that are not authorized to view.    

To manage authentication and authorization in the modern authentication world of the cloud, you need an identity provider. 

What is the role of Identity Providers for Modern Authentication?

The process of the validation within the authentication process is completed by the identity provider.  The identity provider asks as the source that stores a user’s identity and provides the service of validating that identity when authenticating.  In traditional on-premises data center infrastructures, the identity provider is Windows Active Directory.    

As we have moved to using cloud services in both our business and personal use, we interact with numerous identity providers throughout the day.  Identity provider services are provided by Facebook, Twitter, LinkedIn, Salesforce, Workday, etc.  They are also provided by the various cloud providers, such as Google and Microsoft.  Figure 4 shows how the identity provider provides this authentication to access a session.  


Microsoft’s cloud identity service is provided through Azure Active Directory, or Azure AD.  

What is Azure Active Directory?

Azure AD is a cloud-based identity provider that is used for all Microsoft cloud services, including Microsoft 365 and Microsoft Azure.  Unlike Windows Active Directory that utilizes Kerberos or LDAP for directory services, Azure AD utilizes industry recognized cloud protocols SAML and WS-Federation.  This allows Azure AD to be utilized as an identity provider for other cloud native applications outside those created by Microsoft.  Figure 5 shows how Azure AD can be used for Microsoft and third-party application authentication as the identity provider.  


Microsoft’s cloud identity service is provided through Azure Active Directory, or Azure AD.  

What’s next?

We provided information on how identity is now the first line of a defense in depth security posture and the zero-trust methodology.  We also discussed the concept of authentication and authorization for identity and access management.  We then discussed the role of the identity provider for authentication.

We welcome you to explore additional information regarding protecting identities with Azure Active Directory through Microsoft Learn and live instructor-led training from Opsgility.

In the next post, we will discuss how to protect information from threats through governing the data that is made public.


Dwayne Natwick Cloud Architect Lead

Meet the author

Dwayne is a Microsoft Azure MVP and Cloud Training Architect Lead at Opsgility where I author content and provide live training.  I am 18x certified in multiple Azure and M365 roles, including Microsoft 365 Fundamentals, Microsoft 365 Security Administrator Associate, Azure Solution Architect Expert, Azure Administrator Associate, and Azure Security Engineer Associate.

In addition to creating curriculum, training, and blog writing, I am also a Microsoft Certified Trainer and Regional Lead.

Questions? Ask The Experts!

Contact a Microsoft Cloud Specialist Today For A Free Consultation!

Ops_white (1)

Toll-Free: (833) 221-7764
Support :
Sales :