Authentication and authorization

Accessing resources is based on a two-stage concept that consists of firstly authenticating and then authorizing; in a nutshell, identifying who you are and determining what you can do.

Authentication, also referred to as AuthN, is the process of establishing the identity of a person (or service) and proving they are who they say they are. This can be done by validating provided access credentials information against stored or known identifying information.

Authorization, also referred to as AuthZ, is the process of establishing what level of access the authenticated person (or service) has to the resource; that is, what they can access and what actions they may perform:

Figure 8.3 – Authentication and authorization

In this section, we looked at the concepts of authentication and authorization. The following section looks at SSO.

Single sign-on

SSO means only needing one set of credentials that you enter once to access all resources enabled to use SSO in your organization; you are not prompted to sign in again.

In addition, user provisioning to apps is accelerated with just-in-time access for new hires and temporary staff and allows a governed leavers process when users no longer need access to an app.

You configure Azure AD as the trusted IDP for each app you wish to enable SSO through a centralized portal. These apps can be cloud apps, public cloud provider platforms, as well as on-premises apps. You can enforce secure access with identity protection through MFA and Conditional Access, as well as risk-based access policies.

In this section, we looked at SSO. The following section looks at MFA and Conditional Access.

MFA and Conditional Access

MFA (which includes Two-Factor Authentication (2FA) provides an additional layer of security for identifying a user by requiring the user to submit two or more elements for authentication. MFA is based on the following principles:

• Knowledge: Something that only the user knows, such as a password or pin.
• Possession: Something that only the user has, such as a code sent to a phone, a token, or a key.
• Inherent: Something that only the user is, such as biometrics.

Conditional Access works alongside MFA to provide more granular levels of access control; information is collected from the sign-in process (signals), and then decisions are made upon that information to determine whether access to the requested resource will be granted or denied and whether the user will require additional factors of authentication or require taking other action, such as resetting their password. This is visualized in the following diagram:

Figure 8.4 – Conditional Access

The user signal information could be the app trying to get access, the device or location being accessed from, or the security updates status. This could mean that if the user is trying to access the resource from a location that is unknown, a non-managed device/personal device, or a device that doesn’t have the latest security updates, then they will be required to authenticate with a second factor of authentication or even be denied access to the resource.

Conditional Access is a licensed function that requires an Azure Premium P1 or P2 license; this functionality is also included in the Microsoft 365 Business Premium license.

In this section, we looked at MFA and Conditional Access. The following section looks at hands-on exercises to further build on your skills learned in this chapter.

Exercise 1 – Create an Azure key vault

This section will look at installing Azure Key Vault and then storing a secret, which will be a password in this exercise.

In the following sub-sections, you can see the procedure to complete the exercise, segregated into tasks for a better understanding.

Task: Access the Azure portal

1. Log in to the Azure portal at https://portal.azure.com. You can alternatively use the Azure desktop app, found at https://portal.azure.com/App/Download.

Task: Create an Azure key vault

2. In the search bar, type in key vaults; click key vaults from the results list.
3. From the Key vaults blade, click the + Create button on the top toolbar.
4. From the Basics tab, set project details settings as required for the subscription and the resource group.
5. Set Instance details settings, as follows:

• • Key vault name—Enter a name.
  • Region—Set as required.
  • Pricing tier—Leave set to Standard.

6. Set Recovery options settings, as follows:

• • Days to retain deleted vaults—Leave set to 90 days.
  • Purge protection—Leave set to Disabled.

7. Click Next: Access policy; leave at default settings.
8. Click Next: Networking; leave at default settings.
9. Click Review + create.
10. On the Review + create tab, review your settings; you may go back to the previous tabs and make any edits if required. Once you have confirmed your settings are as required, you can click Create.
11. When the deployment is complete, you will receive a notification that the deployment succeeded.
12. Click Go to resource from the Deployment blade; alternatively, navigate to the Azure Key Vault instance.

Task: Add a secret to the key vault

13. From the Key Vault blade of the instance created, click Secrets under Settings.
14. Click + Generate/Import.
15. From the Create a secret blade, set the following:

• Upload options—Leave set to Manual.
• Name—Enter a name for this secret.
• Value—Enter the secret you wish to store (that is, a password).
• Content type—Set as required.
• Set activation date—Set as required.
• Set expiration date—Set as required.
• Enabled—Leave as Yes.

16. Click Create.
17. You will receive a notification that the secret was successfully created.
18. You will now see the secret listed in secrets under Settings for the key vault instance.

In this exercise, we successfully created an Azure key vault and created a secret. In the following exercise, we will look at securing network access using an NSG.