• Network Security Group
• Azure Private Link
  • Azure Private Endpoint
  • Azure Private Endpoint Use Case
  • Azure Private Link Use Case
• Hybrid Identity
• Managed Identity
  • Using Keys for Service:Service AuthN
  • Using Azure AD for Service:Service AuthN
  • Using Azure AD Managed Identity
    • Key Service Characteristics
    • Managed Identity Endpoint
    • Service Support by Managed Identity
    • Type of Managed Identity
    • When do I use Managed Identities
  • Alternative AuthN services
    • Service Principal
• Encryption
  • In Transit
  • At Rest
  • In-use
  • End to End Encryption
  • Customer Managed Keys
• OAuth 2.0
  • How does it work?
  • How does two system know/trust each other?
  • What does OAuth workflow looks like once a System A is authenticated with System B?
  • OAuth 2.0 Grant Types
  • What does OAuth token looks like
  • Benefits of OAuth 2.0
  • Conclusion
  • OAuth Terminology
• JSON Web Token (JWT)
  • Other Authorization options/strategies
  • Why is Authorization token required
  • How is session ID stored on client side
  • SessionID + Cookie vs Sticky Session vs JWT
  • How is JWT token sent to client from server
  • How does JWT looks like
  • JWT Structure
  • JWT FAQ
  • How to implement JWT
• Authorization
• Authentication
  • HTTP Basic Authentication
    • Cons. of Basic Authentication
  • Form-Based Authentication
    • Cons. of Form-Based Authentication
  • Certificate-Based Authentication
    • Certificate-based Authentication Pros.
    • Token or biometrics vs Certificate-based Authentication
    • What is a digital Certificate
    • Use of Digital Certificate
    • Public Key Infrastructure (PKI)
    • How to implement Certificate-Based Authentication
• Transport Layer Security (TLS)
  • TLS Use Case
  • Difference between HTTPs and TLS
  • Why you should use TLS
  • What does TLS do?
  • One-way Authenticated TLS
    • How TLS handshake works
  • Two-way Authenticated TLS
    • How TLS handshake works
    • Username and Password-Based Mutual Authentication
    • How TLS handshake works
• Terminology

Table of contents generated with markdown-toc

• Private Link allows you to access your PaaS services over a Private Endpoint. This Private endpoint is deployed into your Virtual Network.
• In short, Private Link provides private connectivity from your Virtual Network to Azure PaaS services, whi.

Azure Private Endpoint sometimes also called Private Link, is a network interface for completely connecting privately and securely to Azure PaaS services (i.e. Azure Blob storage, Redis cache, etc.).

Its a cool technology that allows us to use traditionally PaaS services resource as part of Private VNet. And what this allows us to do is to have better security platform on Azure without having to use the Public Internet to access many other traditionally

What is actually actually provides

• The primary use case for a Private Endpoint is allowing on-prem connectivity to Azure services (that leverage a public IP to expose the service) over a private IP. Previously if you wanted to connect to an Azure SQL instance from on-prem you had 2 options, you could connect over the internet or if you had Express Route you could leverage Microsoft peering to connect over your Express Route. Connectivity for Microsoft peering tended to map back to public IPs on your Express Route circuit which meant permitting a single host to connect to something in the cloud was difficult if not impossible.

1. Suppose your business ABC had an application running on a Virtual Machine in your own dedicated Virtual Network.
2. This application is only accessible through a private IP address 10.0.0.4
3. The backend storage for this service is hosted on an Azure Blob Storage. So in this case, we know that the VM has its own private IP address of 10.0.0.4, and the Azure Blob storage does not have a private IP, it uses Public IP.
4. Suppose the original chef on-premise had a Private IP of 10.2.0.4, and wanted a mechanism to access the blob storage from on-premise.
   1. One option is to access the Blob storage from on-premise is through Express Route - Microsoft Peering domain, BUT the blob storage account still had a PUBLIC IP address, and the security team was not happy about it. The organization Rule dictate that they'll not be opening any public IP access on their FIREWALL. How do we solve this?
   2. We can solve this using Azure Private Link!
5. In order to access PaaS service securely, lets understand what is required?
   1. Create Private Endpoint inside your Virtual Network. Its a "NIC" card inside your private IP space, in this case it'll be a private IP 10.0.0.5.
   2. Next we'll create a Private Link Resource. That is our blob storage account.
   3. We then connect our Private Link resource to the Private Endpoint using Private Link.

   Private Endpoint --> Private Link --> Private Link Resource (aka Azure Blob Storage Resource)

   4. This way the traffic intended to the storage account always remain in the Private IP space, and it does not need any Public endpoint what so ever in order to access it from on-premise, or from the Azure Virtual Network.
6. Next concern for Security team is Data Exfiltration (see terminology).
   1. In otherword, can anyone from "ABC" use this Private Endpoint to leak confidential data to other storage accounts?
   2. The answer is "NO", and that's because you'll only tie specific Azure resources (Azure blob storage) to this specific Private Endpoint, thereby protecting data exfiltration.

   ⚠️ Note: here is link to Azure resources that are currently working with Azure Private Link.

Watch the video to understand Private Link

⚠️ Note: Private Link carries traffic privately, which reduces your exposure to threats and helps you meet compliance standards.

Manage Identities is a great feature of Azure AD. Make sure you review the availability status of managed identities for your resource/service and known issues before you begin.

Managed Identity service is built for Resource:Resource communication without having to managed credentials i.e. Service Principals.

Managed Identity is nothing but a wrapper on top of your service principals.

Two Managed identity types:

• System-assigned - It's tied to a Resource. So if resource goes away, this managed identity also goes with it. It's 1:1 relationship between 1 Managed Identity to 1 Resource.
• User-assigned - It's NOT tied to a Resource. It can be used by many resources. It's 1:* relationship between 1 Managed Identity to Many Resources.

Managed Identity is tied to an Azure Resource and is Not User specific.

When Managed Identity service is created, its Read-Only. It has Client_ID & Object_ID.

A common challenge for developers is the management of secrets and credentials to secure communication between different services.

Managed Identity can be used to perform secure authentication to any Cloud service while maintaining NO Credentials in your source code.

On Azure, Managed Identities eliminate the need for developers having to manage credentials by providing an identity for the Azure Resource in Azure AD and using it to obtain Azure AD tokens.

To better understand Managed Identities, let's understand some classical scenarios on how we would perform AuthN in most Azure Services.

1. Two Service communicating with each other; Service A (client) sending key to Service B (server)
2. Service B validating the key; checks permission and authZ this key
3. Returns the result

Fine-graining: permissions

Storing: those in your App code

Pretty simple, but as you can imagine this imposes some challenges (see above Managing Keys) and highest security risks. Because usually those keys are stored in your service configuration files, and while you can move the keys out of your configuration file into an external service like Azure Key Vault which off course you should do, but again that would leave you with a challenge of how you can securely connect to Key Vault without maintaining any keys; any credentials within your source code/configuration file. This brings use to the second case using Azure AD for Service:Service AuthN.

1. Service A sends identity credentials to Azure AD in order to connect to Service B
2. Once those credentials are validated by Azure AD, it returns a Token
3. Service A only then sends this token to Service B 4 & 5. Service B, who will then connect to Azure AD to get Open ID configuration
4. Service B will then verify the Token and its AuthN layer
5. Result is return to Service A

This provide much better security compare to using Keys bcoz Azure AD has bunch of features around security and smart alerting. But we're still left with one more challenge here of storing this identity credentials somewhere; and they're either present within App code, configuration file, or on the service itself. So we'll some how need to avoid management of credentials within our service.

To solve this we can use Azure AD Managed Identity.

• Credentials are moved out of App code/or service
• Identity is created and tied with resource (VM) lifecycle, and as soon as we delete this VM, that identity will also be deleted
• As easy as One click in Portal or single command in powershell to set up with no additional cost incurred
• Manage Identities are Service Principles of special type
• Finally this was known as MSI (Managed Service Identity)

Let's take the previous example of connecting 2 services together using Azure AD Managed Identity this time

This time we'll have an Application (replace Service A) on a Azure VM connecting to a Key Vault (replace Service B) service.

In this case, the application will still continue to grab a token from Azure AD. When you enable Managed Identity, a locally running internal endpoint will be registered (Managed Identity Endpoint).

MI Endpoint is a small web service running on that VM that is only accessible from within that VM. So only your locally running code can access this web service to request token from it`

1. Your application (service) sends a request to this Endpoint to request a token from it with NO Credentials to this endpoint
2. MI Endpoint service will use internally stored credentials on that VM to connect to Azure AD to grab a token from it
3. AD returns the token to MI Endpoint service
4. MI Endpoint will then pass the token to your Application
5. Application makes a request to Key Vault service along with a token 6 & 7. Key Vault service will then validate this token against Azure AD
6. In the case of Key Vault, additional Token verification is done like Access Policy Verification are done
7. Once everything is OK, a Secret or anything you've requested will be returned to Application

As you can imagine we can imagine we've solved the issue as in our Code we've NO Credentials anywhere, because that request our Application send to MI Endpoint has NO credentials in it.

Additionally one thing to note that, when you register a Managed Identity; the name of that identity will be the same as that service/resource in Azure. So in the case of this Azure VM, the name of Managed Identity will be the same as your VM name.

Last but least, the Managed Identity life-cycle is tied to the resource (in this case VM). So if you're going to delete this VM, the identity & service Principal (Object ID) with Azure AD will also be deleted.

When exactly to Use it?

• Virtual Machines
• App Service
• API Management
• Container Instances
• Container Registry Task
• Event Hubs
• Functions
• Service Bus
• K8s
• Logic Apps
• Data Factory
• More...

They are the same in the way they work.

The only difference is that if you enable System-Assigned Managed Identity for an Azure resource, the Managed Identity gets automatically created and assigned to that Azure resource, and will also get deleted when you delete the resource.

User-Assigned Managed Identity is created manually and likewise manually assigned to an Azure resource. The lifecycle of a User-Assigned Managed Identity _**is NOT tied **_to the lifecycle of the Azure resource to which it is assigned.

That means it the Azure resource gets deleted, the User-Assigned Managed Identity will not be deleted from Azure.

There are alternative Authentication services to access Azure resources. Here're some of those:

1. Service Principal

2. Shared Signature

3. Account Key/ Access Key / Master Key

Note: For most of the scenarios, above is the order of precedence. In some cases Service Principal takes precedence, for scenarios like for the same Azure resource we need to give different permission for different users. Because Managed Identity will be tied to resource, can’t control in the way of user specific.

Managed Identity manages the creation & automatic renewal of a service principal on your behalf.

Encryption is a method by which a plaintext or any time of data is encoded. The encoded data can only be decoded by the person who has the decryption key.

The encrypted data is referred to as the cipher text, while unencrypted data is called plain text.

Data can be compromised both in-transit and at-rest and this data requires protection in both cases.

Hence, encryption plays a major role in protecting data, and there are various different approaches to protect this data both in-transit and at-rest.

As mentioned above, one of the most effective data protection methods for both data in-transit and data at rest is data encryption.

In transit data is when it's moving from one system to another system.

System = Application, browsers, web connections, or database

• Data in motion
• Data in flight

For protecting data in transit, organizations often choose to encrypt sensitive data prior to moving and/or use encrypted connections (HTTPS, SSL/TLS, FTPS, etc.) to protect the contents of data in transit.

• Benefits of TLS: TLS provides strong authentication, message privacy, and integrity (enabling detection of message tempering, interception, and forgery), ineroperability, algorithm flexibility, and ease of deployment.

Please see more about Azure encryption overview.

At Rest data is data that is not being accessed and is stored encrypted on a physical/logical medium such as database, cloud or hard drive for later retrieval.

For protecting data at rest, organizations can simply encrypt sensitive files prior to storing them in a database and/or choose to encrypt the storage drive itself.

Data in-use is when it is opened by one or more applications for its treatment or and consumed or accessed by users.

https://www.sealpath.com/protecting-the-three-states-of-data/

E2EE is when NO ONE is able to monitoring the network, or can see the content of your data when sent over a network Not hacker, Not the Government, Not even the Company (e.g. WhatsApp) that is facilitating the message to sender. It's stronger then encryption in-transit.

A good example of this is WhatsApp messaging app, where when you send a message to someone, only the receiver is able to read the encrypted message in a plaintext format. WhatsApp cannot read this message.

Is also known as key management with Azure Key Vault.

TODO: https://stonefly.com/blog/data-encryption-essential-for-data-storage https://protonmail.com/blog/what-is-end-to-end-encryption/

❓: Does OAuth means Authentication or Authorization?

• 🅰️: It is meant for Authorization between Services.

OAuth is nothing but a standard for Authorizing one system using another known service (like Facebook/Google) Authorization Server to provide User details to System A on behalf of user. This is also known as Access delegation.

OAuth is an Open standard for System:System Authorization.

Some people also refer to OAuth as a delegated authorization framework for REST/APIs. It enables apps to obtain limited access (scopes) to a user's data without giving away a user's password.

You must have encountered OAuth for example when you try to register to an e-commerce site, and this e-commerce site gives you an option to use well known social media authorization servers like Facebook, Google etc. to authorize them to share your profile data with this application that you would to register with.

• Consider a scenario

Suppose Alex is a developer who has been told he needs to use OAuth 2.0 to authorize users of his application by using Bank's external authorization server. John application will delegate the responsibility of his user authorization to some other service rather than managing them on his own.

• OAuth 2.0 Roles

First let's understand high-level roles exist within OAuth 2.0, we've...

• User
• Application
• API - within API, there is an authentication server and resource server.

So for example if you wanted to listen to a music on Spotify, you might have chosen to login to Spotify using Facebook/Google account.

Spotify is the Application and Facebook is the API in this case. So for John's case, the application is his application, and API is the Bank's API he would use.

So in the case of John, he'll be like...

"I get it now. When I log into Spotify with my Facebook account, Spotify grabs my username and password from Facebook. So easy, right?" The answer is WRONG ❌ This is the biggest misconception about OAuth 2.0 framework. Passwords are NEVER passed from server to server in an OAuth 2.0 framework.

1. System A will need to Register as a Client with System B (Authorization server like Facebook/Google)
2. Client will be given a unique Client ID and Client Secret which is used when authenticating a system with another Authorization service provider server like Facebook, Google.

• Client ID: a public unique application Id
• Client Secret: a private identifier which is kept secret between Application & API service that is used to authenticate my Application/System when it makes a request for user Authorization Access Token.

1. User asks System A to grab his profile details from System B Authorization Server
2. System A asks System B (Facebook) to access users profile details on their behalf
3. System B goes and asks the User, that System A is asking for permission to access it's profile details
4. User cam either accept/reject granting permission to System A
5. If User grants permission to System A, then System B sends an Authorization Token (limited access)
6. System A saves the token, and uses this token every-time it calls System B when it needs to access user profile

There are Four different types of grant types in OAuth 2.0. The grant type used above is Authorization Code Grant.

1. Authorization Code Grant
2. Implicit Grant
3. Password Grant
4. Client Credential Grant

It has to be a token that contains the following two information:

1. Information about user-allowed permissions
2. There also needs to be something that the services can verify known as Trustable (cannot be tempered)

• ❓ Can you guess what is this token known as that can contain data within it, but it is also secure so that it can be verified and cannot be tempered with?

• 🅰️ Its a token format called JWT.

• Simple integration, which simplifies customer/user experience

Now you understand why OAuth is used for Authorization ✅ and NOT Authentication. ❌ The problem is not Authentication, because the user is already authenticated to both systems. Hence, the problem OAuth is trying to solve is Authorization.❗

Is a very popular way to do Authorization in web applications in today's world.

JWT is nothing but a JSON object. Its a way for a client and server to communicate and share information directly that has some meaning across multiple interactions without the server having to remember information for each client. It is used for Authorization purposes.

It is commonly used for Authorization. The idea behind JWT is to create a standard between two parties to communicate securely. So there is this open standard specification called RFC 7519, which outlines how a JWT should be structured, and how it should be used for exchanging information.

• JSON Web Token

• Session Token (+ cookie) - is generated by the server when you authenticate to a system, and the server generates a session ID, saves the state which can be attached to the follow up call to avoid re-logging into the system. The server then returns the session ID back to the client to be used on subsequent request. The server looks-up the Session ID maintained in the backend.

  ⚠️ Most popular mechanism for authorization.

This is all because of HTTP as it's a stateless transfer protocol. No state is maintained over a request. A user calls a URL, then server responds back with an HTML page.

Token is required when you send a request to a server along with your IDENTITY to tell the server who you are.

Session ID gets saved in a cookie, so that it automatically gets added to the cookie header on subsequent request.

Let's understand why JWT is better than SessionID (+ Cookie) or Sticky Session authorization strategy❓

The biggest problem with Session ID + Cookie authorization mechanism is that it assumes that their is a single monolithic application server. 🤔

Most modern web applications are distributed across the world with a Load Balancer in front of them to share the load.

One way to solve this problem with maintaining a session ID across distributed application architecture is to use Shared Cache (Redis); a typical use case for Redis cache.

Other alternative approach/implementation is to use Sticky Session pattern, where the Load Balancer remembers which server has the user session and it always redirects requests to the same server from that specific user. Yeah but this is NOT scalable in the case of Microservice Architecture, how is this sticky session shared between the different instances?

Let's see how JWT solves this problem❓

Imagine when a client Authenticates, instead of the server saving this use information in a state and return the SessionId as a token, it returns the user information itself as a token.

Now everytime the client makes a subsequent request, the client sends the whole JSON token with the request saying "This is who I'm, this is my ID, and my Name". This time the server isn't Saving anything. Everytime a request comes in, the server goes let's see who this is? This JWT says this user name is "FOO", and they have successfully authenticated, OK boys let him in. This Token here is NOT an ID, it's a JSON Object which has all the information. This TOKEN is known as JSON token.

And off-course the problem of security is handled here by signing the token handed over each time...

when a user authenticates, the server just doesn't send any JSON object, but rather send something in a special signed format. There is a signature here 🔑 . So when the client, sends the subsequent request, the signed JWT token is sent back to the server. 🔐 The server verifies the signature, and it trusts it ONLY if its valid. ❗ all the information the server needs is right there in the token.

This is what JWT is, Its a way for a client and server to communicate and share information directly that has some meaning across multiple interactions without the server having to remember information for each client. So in the context of Session token/ID, and JSON web token...

Think of Session ID as a Reference token to a state, ✅ JWT is a Value token ✅

Just like Session ID can be sent using cookie 🍪 , JWT can be sent using cookie 🍪 too 👍

You want to save that receiving JWT token in your browser local storage and later send it to server on your subsequent request? yes you can do that too.

JWT and Session tokens are just different options for what is exchanged, and how you exchange them is up to you. ❗

One might ask, isn't it like painful to send an extra JSON object with every HTTP requests?

It actually doesn't look like a JSON Object.

In fact, you can take this token and figure out what this looks like in JSON in the next section.

Is nothing but a token with JSON value. It is specifically used for AUTHORIZATION, and NOT for Authentication ⚠️ It only comes into picture when Authentication is completed.

If you look at JWT token sample above, it doesn't look like JSON, but rather looks like a bunch of random characters. However, there're couple of things that you can infer from this toke.

⚠️ Notice, the THREE different colors separated by a DOT are the THREE parts.

• Header: is the header where you'll define algorithm and token type

{
  // it tells how this token is signed, also base64 encoded
  "alg": "HS256", // is the type of algorithm used to verify the Signature defined in the last part
  "typ": "JWT" // type of token...in future we might have a another type of token
}

• BLUE: the main core part known as Payload/data, which you do need to exchange.

{
  // is a data (encoded in base64) that identifies who this user is
  "id": "1234567890", // id of the user 
  "name": "John Doe", // issued to
  "iat": 1516239022 // issued at
}

• Signature: the whole point of signature in not to en/decrypt the JWT. It is there for the Web Server to validate if Header and Payload is correct.

  Here is what the Server does...

  1. On a first request, when somebody is authenticated, it creates the Header and Payload.
  2. then the Server signs this token by adding the last part of the token that is the Signature to associated Header and Payload and that's what gets verified on a subsequent request.

  The signature is created using "alg": "HS256" in the Header section.

HMACSHA256(
  // this is how the signature is calculated 
  //     (header + payload) & sign it your key = signature
  base64UrlEncode(header) + "." + // the base64 Header JSON Object
  base64UrlEncode(payload), // the base64 Payload JSON Object
  your-256-bit-secret // is the consumer secret key which only the Server has. Hence, no one can temper with this token although one might think that Header & Payload is in the open. This is what refers to a **cryptographic** hash.
) 

⚠️ Note: Payload on its own is not sufficient, Header and Signature is what lends the authenticity

Go here to see the THREE parts jwt.io in action.

Let's understand the flow of this token...

1. User login using userID/password

2. Server authenticates this user by identifying who this user is

3. Server generates & signs a JWT token for future authorization purposes, and subsequent interaction

4. Server sends the JWT token back to client

5. when client receives JWT token, it can do one of two things...and pass this token on every subsequent request

   i. save in browser local storage 🏬
   ii. save in a cookie 🍪

6. Client passes this JWT token using HTTP Header { Authorization: Bearer JWT }

7. Server examine the HTTP header, and verifies the token i. by splitting the token into THREE parts described above HEADER.PAYLOAD.SIGNATURE

1. How secure is JWT if its readable by anyone? As mentioned before, you don't want to have any confidential/sensitive (SSID, password, NI#) information in JWT. You just need enough info for the server to know who this person is to establish the principal on the server.
2. What is someone steals my JWT and uses it themselves in a request, they can impersonate as me? Server just verifies if JWT is correct. It doesn't know who sent it. So technically someone can use this token. Hence, its important how you transmitting JWT. Connection between client and server needs to be encrypted (TLS), and it should be used in congestion with OAuth; as it has its own mechanism for Authenticating and Authorizing. To make sure that people don't steal JWT token.
3. How do you disable a JWT? Possibly a disadvantage of JWT. When compared to Session ID based authentication. Now in the cases of someone stole your Session ID, User can log off and it ends the session ⭐, also session can expire. In the case of JWT, there is nothing on the Server to end this token; the whole information is inside the JWT. You can set up expiration for JWT. Another way a server can invalidate the JWT is to maintain a state of Block Listed JWT tokens, and check the incoming token against his list.

click link

Authorization is the process of verifying what you've access to.

Authentication is the process of proving your identity.

There're various type of Authentication, some of which are...

• HTTP Basic Authentication
• Form-Based Authentication
• Certificate-Based Authentication
• Username & Password-Based Authentication

This form of authentication requires that the server request a username and password from the web client and verify that username and password are valid by comparing them against a database of authorized users in the specified or default realm (see Terminology).

When Basic Authentication is declared, the following actions occur:

1. A client requests access to the protect resource.
2. The server returns a dialog box that requests the username and password.
3. The client submits the user name and password to the server.
4. The server authenticates the user in the specified realm and, if successful, returns the requested resource.

Basic AuthN is not secure mechanism as it sends creds (u/p) over the Internet as text that is Base64 encoded. If someone can intercept the transmission, the user name and password information can easily be decoded

However, when use in conjunction with TLS, or security at network level such as IPSEC protocol or VPN strategies, some of these can be alleviated (less severe).

This form of authentication is done through presenting a user with a form (usually a HTML login page) to obtain credentials in order to access a protect resource.

When form-based authentication is declared, the following actions occur:

1. A client requests access to a protected resource.

2. If the client is unauthenticated, the server redirects the client to a login page.

3. The client submits the login form to the server.

4. The server attempts to authenticate the user.

   a. If authentication succeeds, the authenticated user’s principal is checked to ensure it is in a role that is authorized to access the resource. If the user is authorized, the server redirects the client to the resource using the stored URL path.

   b. If authentication fails, the client is forwarded or redirected to an error page.

Form-Based AuthN is not secure mechanism as the content of the user dialog box is sent as plain text, and the target server is not authenticated. If someone can intercept the transmission, the user name and password information can easily be decoded.

However, when use in conjunction with TLS, or security at network level such as IPSEC protocol or VPN strategies, some of these can be alleviated (less severe).

⚠️ NOTE: When creating a form-based login, be sure to maintain sessions using cookies or SSL session information.

It is the use of digital certificate (Public Key Certificate) to identify a user, machine, or device before granting access to a resource, network, application etc.

🥇 Certificate-based authentication is stronger as compared to password based authentication.

Digital certificates can then be reused for user authentication.

In this form of authentication, certificates are stored on the local machine or device. No additional hardware needed unlike biometric or token based authentication. It not only saves cost, but can also elevate management pains around distributing, replacing and revoking tokens.

• One differentiator of Certificate Based Authentication is unlike some solutions that only works for users such as biometrics and one-time passwords, the same solution can be used for all endpoints users, machines, devices authentication and even the growing IoT.
• It is used in combination of Password-based Authentication to provide better security

• Digital Certificate is an electronic "password" (document) that allows a person, organization to exchange data security over a the internet using the Public Key Infrastructure (PKI)
• DC is also known as Public Key Certificate (PKC) or identity certificate.

• Verify whether the user sending the message is who s/he claims to be, and to provide the receiver with the means to encode a reply
• A user wishing to send an encrypted message applies for digital certificate from a Certificate Authority (CA)
• They're used in Public Cryptography functions; they're most commonly used for initializing secure SSL/TLS connections between web browser and web server.

PKI is digital certificate management system for distribution, generation, storage, and verification of certificates.

PKI comprise of the following...

• Certificate Authority (CA): issues and verifies digital certificates
• Registration Authority (RA): acts as the verifier of the CA
• Validation Authority (VA): identity is then checked by the contracting with VA

This form of authentication is implemented using HTTPs; which is implementation of TLS.

Formerly known as Secure Socket Layer (SSL) is a security protocol designed to facilitate privacy and security for communication over an internet.

TLS can be implemented in 2 forms:

• One-way Authenticated TLS: only client authenticate server where client requests server digital certificate (PKC), and verifies it with CA
• Two-way/Mutual Authenticated TLS: both parties exchange digital certificate, and verifies their authenticity with CA

• Primary use case for TLS is encrypting the communication between web applications and servers, such as web browsers loading the website.
• TLS can also be used to encrypt other communications such as email, messaging, and voice over IP (VoIP).

• HTTPs is implementation of TLS on top of HTTP (transfer protocol). 🥇

• TLS encryption can help protect web applications from data breaches and other attacks.

There are three main components to what the TLS protocol accomplishes: Encryption, Authentication, and Integrity.

• Encryption: hides the data being transferred from third parties.
• Authentication: ensures that the parties exchanging information are who they claim to be.
• Integrity: verifies that the data has not been forged or tampered with.

https://www.cloudflare.com/en-gb/learning/ssl/transport-layer-security-tls/ https://www.youtube.com/watch?v=ohn89zOcf4M

Let's understand what is one-way authenticated TLS, and how TLS handshake works.

This form of authenticated TLS is when a Client is Thin-Client or some browser accessing a secure website. This way communication between both parties is secure from one side. See Two-way Authenticated TLS for securing communication from both sides.

• Only Client Authenticates Server based on the certificate provided by the server and verifies whether its google and not someone else
• Client requests a Public Key Certificate (PKC), and Server share its Public Key certificate (PKC) to the Client
• Server doesn't care who is the client e.g. when you hit https://google.com from your browser
• Communication between client and server is encrypted

1. Client sends ClientHello message to initiates SSL/TLS handshake process by proposing SSL options.
2. Server responds with ServerHello message selecting the SSL options.
3. Server sends Certificate message, which contains the server's certificate.

Let's understand what is two-way authenticated TLS, and how TLS handshake works.

This form of authentication through TLS is between Server:Server/Business:Business for secure communication. This way communication between both parties is secure from both sides. Used when there is an integration between two systems.

• This type is also known as mutually-authenticated TLS (mTLS).
• Both Client & Server Authenticate each other, and verifies who's each other
• Certificates exchanged for both parties
  • Client share its Public key certificate (PKC) to the Server
  • Server share its Public key certificate (PKC) to the Client
  • PKC is also known as Digital Certificate
• Used for Business:Business or Server:Server communication

In this form of TLS handshake, the server and the client authenticate one another.

1. A client requests access to a protected resource.
2. The web server presents its certificate to the client.
3. The client verifies the server’s certificate.
4. If successful, the client sends its certificate to the server.
5. The server verifies the client’s credentials.
6. If successful, the server grants access to the protected resource requested by the client.

Detail steps as follows:

In this form of TLS handshake, step 1 - 3 shown in One-way handshake will still happen, but here we introduce step 4 and onward to perform two-way authenticated TLS.

4. Server requests client's certificate in CertificateRequest message, so that the connection can be mutually authenticated.
5. Server concludes its part of the negotiation with ServerHelloDone message. 6.Client responds with Certificate message, which contains the client's certificate.
6. Client sends session key information (encrypted with server's public key) in ClientKeyExchangemessage.
7. Client sends a CertificateVerify message to let the server know it owns the sent certificate.
8. Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
9. Client sends Finished message to let the server check the newly activated options.
10. Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
11. Server sends Finished message to let the client check the newly activated options.

This form of authentication is used in conjunction with one-way authenticated TLS as an alternative to [two-way/mutual authenticated TLS](#two-way authenticated TLS).

In user name- and password-based mutual authentication, the following actions occur:

1. A client requests access to a protected resource.
2. The web server presents its certificate to the client.
3. The client verifies the server’s certificate.
4. If successful, the client sends its user name and password to the server, which verifies the client’s credentials.
5. If the verification is successful, the server grants access to the protected resource requested by the client.

See Azure RBAC

• realm: is a security policy domain defined for a web or application server. A realm contains a collection of users, who may or may not be assigned to a group. A security *realm is a mechanism used for protecting Web application resources. It gives you the ability to protect a resource with a defined security constraint and then define the user roles that can access the protected resource.
• Data Exfiltration: data **exfiltration **is a form of a security breach that occurs when an individual's or company's data is copied, transferred, or retrieved from a computer or server or even a cloud storage service without authorization.
• security principal: