Chapter 19: Identity, Authentication, Authorization, Zero Trust

19.1 Why.

Welcome to Chapter 19.

I am Ravindra Bagale.

Raju had no engineering degree. He had a sticky note with one password and a smile that said the note was temporary. Guru-ji turned the note over. The back was blank. "A password on paper is a person you cannot fire," he said. "Identity is the name. Authentication is the proof. Authorization is the room you may enter. Zero Trust is the refusal to skip any of the three because the visitor looks familiar."

Raju thought of Chapter 18, where the cloud role expired and the long-lived key did not. "We already split humans and workloads."

"You split them in one account," Guru-ji said. "The city still hires, transfers, and forgets people. A joiner arrives at Swiggy and needs the kitchen of one service, not the keys to every restaurant. A mover at Paytm changes team and keeps yesterday's payment role because nobody asked. A leaver at Infosys walks out and the client VPN still greets the old laptop. WhatsApp-shaped sessions that never expire, Zomato-shaped shared admin groups, Netflix-shaped break-glass passwords written where the whole on-call can read them, BHIM UPI-shaped tokens accepted by the wrong audience, Amazon-shaped consoles opened from a device you have never seen, PayFast-shaped reviews that happen once a year in a spreadsheet nobody opens. Those are identity failures. The cloud policy in Chapter 18 cannot see them if the directory itself is a junk drawer."

Suppose the test system is "not production," so it has no second factor. Suppose the session lasts a week because re-login is annoying. Suppose the group called Developers can approve payments because that was faster in the first month. Zero Trust answers each suppose with a question: who is this, on what device, for which resource, for how long, and what evidence will remain when they are gone?

19.2 What.

Users, groups, roles, and service principals. A user is a person. A group is a job they share. A role is a bundle of permissions aimed at a task, not at a personality. A service principal, a service account, or a workload identity is a program. Chapter 18 taught the cloud version of that split. This chapter is the directory that feeds it. Name people. Do not share one login called admin or team. If two people must do the same job, they share a role, not a password. Groups change when jobs change. Roles stay boring and small. A service principal never uses a human's MFA prompt. It uses federation and a short life, which you already practiced. If a human and a script share an account, your incident timeline will lie.

Authentication is proof. Authorization is permission. Logging in does not mean you may refund a Paytm-shaped payment or read every Swiggy order. Authentication answers "is this the principal we enrolled?" Authorization answers "may this principal do this action on this object now?" Mix them and you get a door that opens the whole building. Keep the login page strict and the permission check stricter. Every sensitive action checks the object, not only the fact of a session. "They are signed in" is not a reason.

RBAC, ABAC, and ReBAC. Role-based access control gives permissions to roles, then roles to people. It is the default you can explain to an auditor. It fails when roles become "Super Developer" and collect every right anyone once needed. Attribute-based access control adds facts: department, environment, time of day, device health, data tag. A refund role might work only when the environment is production, the ticket id is present, and the amount is under a limit your policy names. Relationship-based access control asks about the graph: is this person the owner of this order, the manager of that owner, or a stranger? A delivery partner should see the order they are carrying, not the city's orders. Pick RBAC for the stable jobs. Add ABAC where context matters. Use ReBAC where the data itself has owners. Write the rule in a policy file you review. Do not hide it in a hundred if statements nobody tests.

SSO, SAML, OIDC, and OAuth. Single sign-on means one identity provider, many applications. People enroll once. Applications trust the provider. SAML is an older XML-shaped federation still common in enterprises. OpenID Connect is an identity layer on OAuth 2, and it is the flow you will meet in modern web and mobile sign-in. OAuth 2 is delegation: a user or a workload allows an application to act with a limited token. It is not "log in with a password you hand to the app." The application should receive a code, then a token, and the token should name an issuer and an audience. Infosys-shaped client work often means you must connect to the client's identity provider. Do that with federation. Do not copy their users into a second password database you will forget to disable.

A teaching sketch of what you verify, on a lab token you minted yourself:

issuer matches the lab identity provider
audience matches this one API
expiry is still in the future
subject is a known principal
signature uses the algorithm you pinned
scopes or roles are the small set this route needs

If any line fails, the request fails. You do not "fix" a bad audience by accepting every audience.

Token habits that are not folklore. Prefer short expiries and refresh that can be revoked. Store refresh tokens as carefully as Chapter 10 stored secrets. Pin the algorithm and the issuer. Reject none and any algorithm you did not choose. Do not leave "ignore expiry" on outside a lab minute. Rotate signing keys. A leaked signing key is a factory of identities. This chapter will not show how to forge a token. Reject anything you did not sign and anything that names the wrong room.

MFA, phishing-resistant MFA, and passkeys. A second factor is a second proof: something you have, something you are, or a device key, not a second password written beside the first. Push notifications that only ask "approve?" train people to tap yes. That fatigue is a known failure mode. Prefer phishing-resistant factors: a hardware key, or a passkey bound to the real site, so a lookalike page cannot replay the proof. SMS is better than nothing and weaker than a device-bound key. Apply MFA to administrators, to remote access, to email, to the identity provider itself, and to the test tenant you think does not matter. Chapter 8's SSH door and this chapter's console door are the same idea. A legacy system that cannot do modern MFA does not get a permanent exception. It gets a plan, a deadline, and a smaller network until the plan lands.

Privileged access, JIT, and JEA. Standing privilege means the power is always on. Just-in-time means it appears for a window, with a reason, and then disappears. Just-enough means the window contains one task. A Paytm-shaped on-call engineer may read payment logs at night and still must not hold a permanent role that can create users. Request, approve, use, expire, review. The password does not live in a channel. If you record the most sensitive console, say what is recorded, who may watch, and how long it lives.

Conditional access and device posture. A managed laptop is not a cafe browser. Require a compliant device for the admin console, allow ordinary mail with MFA, and block a legacy protocol that cannot do either. Device posture is a signal. Collect only what the decision needs, and tell the engineer why they were stopped: enroll the device, use the bastion, or wait for the ticket.

Zero Trust principles. Never trust by network location alone. Always verify explicitly. Assume a breach, so a stolen session still hits least privilege and a short life. These are not a product you buy in one box. They are a way of drawing Chapter 9's segments and Chapter 18's roles on the same page. A laptop on the office Wi-Fi is not inside. A pod in the cluster is not trusted because it is "our" namespace. A partner at Amazon-shaped integration work is not trusted because the contract is signed. Each request carries identity, device, and context. The default is deny. The allow is specific, logged, and reversible.

Policy evaluation, deny-by-default, and permission boundaries. When several policies speak, learn which one wins. A deny should beat an allow. A boundary should stop a team admin from granting themselves the world, which Chapter 18 named for the cloud and which your application roles need too. Evaluate in a lab: a user with the refund role and a missing ticket attribute should fail. A user with the role, the ticket, and a stolen session from an unmanaged device should fail if that is your rule. Write the failed case next to the successful case. Green tests that only show the happy path are how wide roles survive review.

Break-glass. Emergency access is real. The building will burn in a small way and the identity provider may be the thing that is down. Break-glass accounts are few, long-password or hardware-key protected, stored apart from the directory they rescue, alarmed on every use, and drilled. They are not a shared password in a chat. After use, you rotate the secret and you write what was done. If break-glass can create more break-glass without a trace, you do not have an emergency door. You have a second, quieter front door.

Joiner, mover, leaver. Hire, transfer, exit. Automate the three. A joiner gets the birthright role for their job and nothing romantic. A mover loses the old team and gains the new one on the same day the human resources record changes. A leaver loses sessions, tokens, keys, laptop trust, and vendor accounts, not only the mail badge. Contractors and Infosys-shaped project staff are leavers on the contract end date even if everyone likes them. Orphan accounts are the Midnight Blizzard shape: a test identity nobody thought was in scope. Inventory monthly. Disable what you cannot explain.

Access reviews. A review asks a specific question: does this person still refund, yes or no. A thousand-row "certify all" click is not a review. Privileged roles quarterly, guests and contractors monthly, service principals when the owner changes. Record the decision. Side-channel group adds that never hit the directory log do not count.

Sessions and federation, from the human side. A session is a borrowed name with a clock. Idle timeout, absolute timeout, and revocation on the leaver path matter more than a long-lived cookie. Bind admin sessions to the device. Teach the application to honor the identity provider's revocation list. Chapter 18 replaced a CI key with OIDC. This chapter replaces a copied client password with SSO. The pattern is the same. A trusted issuer speaks. Your system checks the speech. The credential dies. Guest users from a partner live in their directory and visit yours. When the partner disables them, your door should notice. Do not shadow-copy partners into local accounts "so the project does not depend on their IdP." That copy will outlive the project.

A lab role card. This is paper, for a system you own.

Role: lab-refund-reader
Who: one named lab user, not a shared account
Proof: SSO plus a second factor
Allow: read one order by id in the lab app
Deny: list all orders, change roles, read the secret store
Clock: session 60 minutes, role review in 30 days
Evidence: one log line with subject, action, object, decision

If you cannot fill those six lines, you are not ready to add the role.

19.3 How.

1. Write "own lab only" at the top of the identity page.
2. Draw three boxes: people, workloads, and partners. Put every lab account into one box.
3. Delete or disable shared logins. Give each person a named user.
4. Create roles for tasks, not a single admin role for the whole lab.
5. Put human sign-in behind one identity provider.
6. Turn on MFA for every human, including the test tenant and the break-glass drill account.
7. Prefer a phishing-resistant factor for the admin role. Record why if the lab tool cannot do it yet.
8. Set idle and absolute session lifetimes. Make the admin lifetime shorter than the ordinary one.
9. Add a deny-by-default rule: no role means no route.
10. Implement one ABAC-style check, such as "refund read only when a ticket id attribute is present."
11. Prove the check fails when the attribute is missing.
12. Create a joiner script or checklist that grants only the birthright role.
13. Create a mover path that removes the old role when the team attribute changes.
14. Create a leaver path that disables the user, revokes sessions, and lists leftover keys.
15. Run the leaver path on a lab user and confirm a stolen cookie or old token no longer works.
16. Add a just-in-time request for the privileged role with a reason field and an expiry.
17. Alarm when that role is used.
18. Store one break-glass account outside the daily group, alarm it, and drill it once.
19. Review the privileged list and remove one person who does not need it.
20. Confirm workload access still uses Chapter 18 federation, not a human password.
21. Log subject, action, object, and allow-or-deny for one sensitive route.
22. Pin token checks: issuer, audience, expiry, and algorithm. Reject a token you alter in the lab.
23. Write the conditional rule in one sentence, even if the lab device check is only a header you set yourself.
24. Put the role definitions in a file you can diff, not only in a console you click.
25. Stop. Do not phish, spray, or "test login" against any real company. Your lab directory is the only door.

19.4 A real public incident.

Name. Midnight Blizzard compromise of Microsoft corporate email.

Date. Microsoft said the activity began in late November 2023. Microsoft said its security team detected the nation-state attack on 12 January 2024 and published the first public account on 19 January 2024. On 25 January 2024 Microsoft stated that the compromised legacy test account did not have multifactor authentication.

Source. Microsoft Security Response Center, "Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard," 19 January 2024, and Microsoft Threat Intelligence, "Midnight Blizzard: Guidance for responders on nation-state attack," 25 January 2024. This chapter uses those public accounts for what failed. It does not repeat intrusion steps.

What happened. Microsoft identified the actor as Midnight Blizzard, also known as Nobelium. Microsoft said the actor used a password spray to compromise a legacy non-production test tenant account and then used that account's permissions to access a very small percentage of Microsoft corporate email accounts, including members of senior leadership and employees in cybersecurity, legal, and other functions, and exfiltrated some emails and attached documents. Microsoft said the investigation indicated the actor was initially targeting information related to Midnight Blizzard itself. The 25 January post said the legacy test account did not have MFA, and that a similar tenant deployed under current policy would have had MFA and active protections. A non-production identity with real permissions was enough. The network location and the word "test" were not a control.

How to stop.

1. Disable the compromised account and revoke its sessions and tokens.
2. Hunt for other legacy and test identities that can reach production mail or directories.
3. Require MFA on every remaining human account, including non-production tenants that can touch corporate data.
4. Preserve directory and mail audit logs for the response and for law enforcement.
5. Notify the people whose mail was read, and reset any secret that mail could have exposed.

How to prevent it again.

1. Inventory every tenant and every account. "Legacy" is not an exemption.
2. Phishing-resistant MFA for admins, and MFA for everyone else, including tests.
3. Least privilege on test accounts so a foothold cannot read leadership mail.
4. Conditional access and short sessions, with alerts on password-spray shaped failures and on new privileged grants.
5. Joiner-mover-leaver automation and access reviews that include service and test principals.
6. Practice the lab leaver and the lab MFA gap on systems you own. Do not spray passwords at Microsoft or at anyone else.

This is for learning only, and only inside a system you are allowed to test.

19.5 A simple picture.

A request is not trusted because it came from the office. It passes a person or a workload, a second proof, a short session, and a deny-by-default decision. The log keeps the four words: who, what, which object, allow or deny.

19.6 A short animation.

A session that never ends is a spare key. A session that fades forces a new proof. Prefer the fade for admin work.

19.7 Conclusion.

Raju tore up the sticky note. The lab user had a name, a second factor, and a role that died when the ten minutes died. Guru-ji tapped the next blank page. "Identity without an API is a lobby with no rooms. In Chapter 20 we put this proof on the wire between services: tokens, object checks, gateways, and the shadow route nobody inventoried."

• Authentication proves the principal. Authorization decides the object.
• RBAC, ABAC, and ReBAC are ways to say the decision. Deny is the default.
• MFA, short sessions, and joiner-mover-leaver close the human door Chapter 18 opened for workloads.
• Zero Trust refuses to trust a network, a test label, or a familiar face.
• Midnight Blizzard, disclosed 19 January 2024, is the legacy test account without MFA.
• Own lab only.

END OF CHAPTER 19 MASTER CLASS