## IAM Simulator

Unlike video courses where you watch someone else work, this is an interactive simulator where you implement IAM step-by-step. You progress from DevOps engineer to IAM Lead as the challenges grow and the stakes get higher.

The story begins when you join a startup that already has customers, growing HR friction with hires, leavers, and role changes, three different login systems, and no process behind them. During the course, you'll build the entire IAM infrastructure — from fixing the immediate crisis when the biggest customer threatens to leave, to implementing proper user lifecycle management and audit trails. Real Keycloak servers, real problems, real solutions.

## What You'll Learn

You'll build production-ready Keycloak with multi-tenant architecture, connect it to Active Directory for enterprise clients and social providers for easy access. You'll automate the entire user lifecycle from provisioning to deprovisioning, implement audit trails for compliance, and set up monitoring that catches problems before users complain. Most importantly, you'll understand when to use each feature and why it matters to the business.

## Who This Course Is Designed For

- **DevOps engineers** tasked with implementing enterprise SSO
- **CTOs and IT managers** who need to understand IAM decisions and trade-offs
- **Developers** integrating OAuth2/OIDC into applications
- **Startup Founders** facing enterprise customer authentication requirements

## Prerequisites

No OAuth2 or Keycloak knowledge needed. If you understand how web apps work (browser makes requests to server), you're ready.

# Congratulations

You've completed the IAM Simulator. You should now be able to:

- Set up and configure a Keycloak server
- Create and manage realms, users, and roles
- Integrate applications using OIDC and other protocols
- Configure some advanced Keycloak features

## Next Steps

Consider exploring Keycloak's more advanced features like custom authentication flows, themes, and federation capabilities.

# Before We Start

Welcome to Enterprise IAM & SSO with Keycloak. Before diving into the authentication challenge that kicks off our story, let's cover a few things that'll help you get the most from this course.


## Course Access

After finishing the course, you'll still have access to all materials. So when you face similar IAM challenges at work months later, you can always come back and refresh your memory. Everything will be here when you need it.

## Course Challenges

**Use whatever helps you solve the quiz / lab challenge:**
- Google things you don't understand
- Ask experienced colleagues for their perspective  
- Apply your own experience to the problems
- Check Stack Overflow, documentation, whatever works

Just like in real work - use all available resources to solve the challenges.

**Important:** Once you submit an answer in the simulator, you can't change it. Just like real life - you make a decision and live with the consequences. This makes the learning stick better.

## How to Succeed

Best results are achieved if you study regularly.

Consider dedicating at least an hour per day to the simulator. Pick a consistent time and place - maybe early morning before work starts, or evening when things quiet down. Regular practice beats intensive cramming every time.

The whole journey takes about 5-7 weeks at this pace. After 2 weeks, you'll already feel confident with Keycloak basics.

## About the Story

All events and characters in our story are fictional but based on real situations we've seen in our consulting work. If you recognize patterns from your own company... well, maybe we've worked with you, or maybe these problems are just universal. Whether to tell your colleagues "hey, this is exactly like our situation!" is entirely up to you.


## Good to Know

**Found a bug or typo:** Drop us a line at support@authpractice.com - we're a small team and genuinely appreciate the help keeping things polished.

**Lab environments:** Each lab environment is designed to be isolated for every student. When environments are shared, you'll get read-only access so everyone can learn without stepping on each other's toes. If you notice something's not working as expected - please let us know!

## Spread the Word

We're a small consultancy, not some big education company. We built this because we kept fixing the same IAM problems everywhere - figured we'd help more people this way.

If this helps you, we'd love if you shared it. Drop a LinkedIn post, mention it when someone's struggling with Keycloak - whatever feels natural.

At the end, we'll ask for your honest feedback. Whether it's "finally understood OAuth2" or "here's what needs work" - it all helps. Plus, knowing real people are using this stuff? That's what keeps us going.

Thanks for being part of this.

## Let's Begin

Alright, let's turn you into the person everyone calls when they need auth done right.

May your tokens always validate and your sessions never expire unexpectedly.

::: email
sender:
  name: Tom
  avatar: https://images.unsplash.com/photo-1507003211169-0a1dd7228f2d?w=150&h=150&fit=crop&crop=face
  role: CTO
recipients:
  - you
subject: Final Interview step - Quick technical check
timestamp: 1 hour ago
priority: normal
cardStyle: contrast
attachments:
  - name: final-interview-questions (1).docx
    size: 1.8MB
    type: document
---
Hi!

Congrats, you've made it to the final round - it's down to you and one other candidate!

I'm Tom, the CTO, and this is my part of the process.

What we're building: We transform business documents into structured data for enterprises using LLMs — contracts, medical records, financial reports. Instead of having teams manually extract information from thousands of PDFs, we automatically parse and extract what matters. We're increasing processing speed by 100x for banks, law firms, and healthcare companies.

These clients trust us with their most confidential data, which is why security and authentication are critical for us. 

And that brings me to you.

We know you're not an auth expert yet - you were honest about it. That's actually what I like about you. The last "expert" we interviewed couldn't explain the difference between authentication and authorization. You'd be surprised how common that is.

I just need to understand your current level to make the final decision.

Should take 20-30 minutes. Some of these questions came from real customer requests - enterprise clients have interesting requirements.

Good luck!

- Tom
:::

# Authentication vs Authorization

**Maria tries to access the system. The system checks two things:**

1. "Is this really Maria?" (verifies her password)
2. "Can Maria read customer's financial data?" (checks her permissions)

![Authentication vs Authorization {width=25em height=25em text-align=right}](login-maria.svg)

::: quiz
- radio: "First check is:"
  options:
    - correct: Authentication
    - Authorization
- radio: "Second check is:"
  options:
    - Authentication
    - correct: Authorization
- success: |
    **Right!** You understand the fundamental difference between authentication and authorization.
    
    Authentication proves identity ("Who are you?"). Authorization determines permissions ("What can you do?").  
    Many breaches occur when systems authenticate correctly but authorize poorly - yes it's Maria, but Maria from Marketing shouldn't access financial databases.
:::

# The Temporary Solution

**During code review, you find this in your production codebase:**
``` javascript
// TODO: TEMPORARY - Remove after Friday's demo!!!
const ADMIN_TOKEN = "full_access_everything";
// Just for the investor presentation
```

::: quiz
- radio: "Two years later, this token is likely:"
  options:
    - Removed right after demo as planned
    - Properly documented in security policies
    - correct: Still in production, doing critical stuff
    - Disabled but nobody remembers why it exists
- success: |
    Demo succeeded, funding arrived, champagne popped... and everyone forgot about the token.
    
    Two years later, it's probably handling critical functions. "Temporary" code has a way of becoming permanent, especially when it works.
    
    These forgotten backdoors cause countless breaches.
:::

# What is Multi-Factor Authentication?

![MFA Factors {width=25em height=25em text-align=right}](enter-otp.svg)


::: quiz
- radio: "Your bank requires password + SMS code. This is because:"
  options:
    - Passwords need to be longer and more complex
    - correct: Even if password is stolen, attacker needs your phone too
    - It prevents automated bot attacks
    - Banks love making things complicated
- success: |
    The core principle of MFA - is about requiring **different types** of proof, not just stronger proof. 
    
    Even if hackers steal your password through phishing, keyloggers, or data breaches, they'd still need physical access to your phone.  
    
    That's why it works - it's not about making passwords better, it's about adding a completely different authentication factor. (Yes, it's often legally required too, but the security benefit is what matters)
:::

# MFA Factors

![MFA Factors {width=25em height=25em text-align=right}](mfa-factors.svg)

::: quiz
- multiple: "Which are REAL MFA factor categories? (select all that apply)"
  options:
    - correct: Something you know (password, PIN)
    - Something complex enough (20+ character passphrase)
    - correct: Something you have (phone, hardware token)
    - correct: Something you are (fingerprint, face scan)
    - Something you change monthly (rotating passwords)

- success: |
    **Correct!** Many people confuse stronger security measures with additional factors.

    "Something you change monthly" and "something complex enough" are just stronger versions of "something you know" - they're still knowledge-based.
    
    True MFA requires different factor types, not just better passwords.  
    
    Modern fintech apps bind your phone during setup (something you have) and add biometrics (something you are). 
    
    Traditional banks use password (something you know) plus SMS codes or TAN generators (something you have).
    
    Different implementations, same principle - combining different factor types.
:::

# The Helpful Error

![Login error messages {width=25em height=25em text-align=right}](login-tom.svg)

**Login system shows different messages:**
1. "Invalid username" 
2. "Invalid password"

::: quiz
- radio: "Why is this a security vulnerability?"
  options:
    - It's not - it's helpful for users
    - Passwords aren't strong enough
    - correct: Attackers now know which usernames exist
    - Should use MFA instead
- success: |
    **Exactly right!** By confirming which usernames exist, you've given attackers half the puzzle.
    
    They can now focus on password attacks for known accounts. Better practice: always show _"Invalid username or password"_ to avoid information leakage.
:::

# Reading the Security Logs

``` log
2024-12-02 09:00:00 LOGIN  "user=sarah@ceo" IP=10.0.1.1
2024-12-02 09:00:15 ACCESS resource=financial_reports "user=sarah@ceo"
2024-12-02 09:00:45 LOGOUT "user=sarah@ceo"
2024-12-02 09:01:00 LOGIN  "user=sarah@ceo" IP=185.220.101.45 (TorExitNode)
2024-12-02 09:01:01 ACCESS resource=customer_database "user=sarah@ceo"
2024-12-02 09:01:02 EXPORT records=ALL "user=sarah@ceo"
2024-12-02 09:01:03 DELETE logs=authentication "user=sarah@ceo"
2024-12-02 09:01:04 ERROR  Cannot delete logs - insufficient permissions
2024-12-02 09:01:05 LOGOUT "user=sarah@ceo"
2024-12-02 09:15:00 LOGIN  "user=sarah@ceo" IP=10.0.1.1
2024-12-02 09:15:01 TICKET "Help! I can't login!" "user=sarah@ceo" 
```


::: quiz
- radio: "What story do these logs tell?"
  options:
    - Normal morning routine with VPN usage
    - Sarah shared access with IT colleague for troubleshooting
    - correct: Someone stole Sarah's credentials and tried covering tracks
    - Penetration test by security team
- success: |
    **Yep, that's what happened.** Classic credential theft pattern: legitimate login from office, logout, immediate login from Tor (hiding identity), data export, failed attempt to delete evidence, then real Sarah can't login (attacker changed password).
    
    Three red flags here:
    1. The TorExitNode - legitimate users don't suddenly switch to Tor.
    2. Exporting ALL records - even CEOs rarely need everything at once.
    3. Attempting to delete authentication logs - why would a CEO try to hide their own actions?
    
    That combination screams "attacker trying to steal data and cover tracks." Without these logs, you'd never know what happened.
:::

# Development Environment

![Development Environment {width=25em height=25em text-align=right}](dev.svg)

**How should development environments access data?**

Current setup:
- Dev connects to production database (read-only)
- 15 people have dev access  
- "It's safe because it's read-only"

::: quiz
- radio: "Your security assessment:"
  options:
    - No risk - fine with read-only
    - Low risk - add monitoring for dev queries
    - Medium risk - ensure devs use strong passwords
    - correct: Critical risk - dev should use fake data
- success: |
    Dev environments are insecure by design - weaker passwords, more people with access, less monitoring.
    
    Read-only to production means any compromised dev machine exposes all customer data. One infected intern laptop becomes a data breach. Always use sanitized, fake data in development.
:::

# Monday Morning Updates

![Team {width=35em height=25em text-align=right}](team.svg)

**Monday morning inbox:**
- "Welcome our new developer!"
- "Sarah moved from Sales to Finance"
- "Mike's last day was Friday"

**Two months later:**
- New dev has GitHub but still waiting for CI/CD access
- Sarah has access to both Sales AND Finance systems
- Mike's email/calendar revoked but still has full CRM access with all customer data

::: quiz
- radio: "What's the root cause of this mess?"
  options:
    - IT team is overwhelmed with requests
    - correct: No IAM process exists at all
    - Missing automated provisioning tools
    - Poor communication between departments
- success: |
    **Yep, that's it!** There's simply no process for managing user lifecycle - nothing for joiners, movers, or leavers. 
    
    Your new developer can see code but can't deploy, Sarah is accumulating permissions like Pokemon cards, and Mike can't check email but can still export your entire customer database. Studies show 89% of ex-employees can still access corporate systems. Security isn't just technology - it's having actual processes (documented or not, but preferably documented).
:::

# Perfect Security

![Perfect Security System {width=25em height=25em text-align=right}](perfect-security.svg)

**Your competitor brags: "Our system is unhackable! We require:**
- 30-character passwords, changed weekly
- Iris scan + fingerprint + facial recognition  
- Hardware USB security key
- SMS verification code

::: quiz
- multiple: "What's the real-world outcome? (select all that apply)"
  options:
    - correct: Sticky notes with passwords under every keyboard
    - correct: Teams share one account to avoid the hassle
    - correct: IT spends most time on password resets
    - correct: Customers complain and switch to competitors
    - correct: Excel file "passwords.xlsx" on shared drive
- success: |
    **All of them!** That's what happens with over-engineered security.
    
    Sticky notes everywhere. Teams sharing "admin123" account. IT doing nothing but resets. Customers leaving angry reviews. And that passwords.xlsx file? It's probably called "DO_NOT_SHARE_PASSWORDS_2025.xlsx" for irony. The most secure system that nobody uses correctly is less secure than a simpler system used properly.
    
    Security must work WITH human nature, not against it.
:::

# The Unknown Acronym

![IAM SAML 2.0 SSO OIDC OAUTH ASAP {width=35em height=25em text-align=right}](video-meeting.svg)

**Friday, 4:47 PM. Call with BigBankCorp (potential €500K/year contract):**

"We need SAML 2.0 SSO integration with our Okta instance by Q2. This is mandatory for all vendors."

You've never heard of SAML.

::: quiz
- radio: "Your response:"
  options:
    - "Absolutely, SAML 2.0 is our specialty"
    - "We don't support enterprise authentication"
    - correct: "I'll need to review our SAML roadmap with the team and get back to you Monday"
    - "Our API keys are more secure than SSO"
- success: |
    **Right response!** You bought time without lying or losing the deal.
    
    Tech is full of acronyms you won't know - SAML, SCIM, OIDC, PKCE. Admitting knowledge gaps while showing commitment to deliver is professional. Faking expertise leads to blown deadlines and lost trust. 
    
    The mature approach: research, understand capabilities, then commit with realistic timelines. (BTW: SAML is how enterprises do single sign-on, and yes, you'll need it for BigBankCorp.)
:::

# Monday's Audit

**Friday, 3 PM. CEO forwards email:**

> Security audit team arrives Monday 9 AM.  
> They'll pentest everything.  
> Last company they audited lost their biggest client after the report.  
> Fix whatever you can.  
> -Sahra (CEO)

**Your security scan reveals:**
- No HTTPS on admin panel
- DEV_MASTER_TOKEN hardcoded in production 
- No rate limiting on login attempts
- 15 unused user accounts from ex-employees

::: quiz
- radio: "You have 2 hours before weekend. Priority fix?"
  options:
    - Setup Let's Encrypt for HTTPS
    - correct: Remove DEV_MASTER_TOKEN from production
    - Implement rate limiting with fail2ban
    - Disable all unused accounts
- success: |
    **Fix the critical vulnerability first, then improve overall security.**
    
    While HTTPS is important, the DEV_MASTER_TOKEN is a critical backdoor giving complete system access. 
    
    This is like worrying about window locks while your front door is wide open. Any junior pentester will find hardcoded tokens in 5 minutes and own your entire system. 
:::

# Beyond Passwords

**BigClient's IT team calls you urgently:**

> Your authentication system blocked our CEO during a board meeting in Singapore!  
> He entered the correct password AND SMS code, but your system flagged:
> - New device (iPad never seen before)
> - Unusual location (Singapore hotel WiFi)
> - Odd timing (3 AM local time)
> - Suspicious activity (downloaded 50 files in 2 minutes)
> 
> He's furious. Your system blocked him even though his credentials were correct.  
> Should we disable these security checks?

::: quiz
- radio: "What's the best approach?"
  options:
    - Remove all location and device checks
    - Trust anyone with correct password + MFA
    - correct: Ask extra security questions when context is unusual
    - Block all logins from new devices
- success: |
    Modern authentication includes context checks - not just "is the password correct?" but also "does this login pattern make sense?" Time, location, device, and behavior patterns all become part of the security decision.
    
    When something looks suspicious (CEO suddenly in Singapore at 3 AM), the system should:
    1. ask for extra verification through different channels,
    2. log this as high-priority security event for review, even if verification passes. 
    
    This catches attacks that correct passwords would miss, like when someone's credentials are stolen and used from another country. 
    
    That's why banks call you about unusual transactions instead of declining your card - and why they keep records of every unusual pattern.
:::

Keycloak Training & IAM Course: IAM Simulator

IAM Simulator

What You'll Learn

Who This Course Is Designed For

Prerequisites

Course Content

Final Interview

Wellcome

Investigation

Old Friend

OAuth2 and OIDC

From Zero to Hero

First Disaster

API Tokens

Who Issued This Token?

No More Devs in Prod!

Scaling Operations

Mobile Client (PKCE)

Enterprise Integrations

From Appliance to Cloud

External Audit?!

Security Upgrade

Basic Monitoring

Production Security

Series B