## IAM Simulator

Anders als bei Video-Kursen, wo man anderen bei der Arbeit zuschaut, ist dies ein interaktiver Simulator für die schrittweise IAM-Implementierung. Der Weg führt vom DevOps Engineer zum IAM Lead, während die Herausforderungen wachsen und die Einsätze höher werden.

Die Story beginnt beim Einstieg in ein Startup, das bereits Kunden hat, wachsende HR-Probleme durch Neueinstellungen, Kündigungen und Rollenwechsel, drei verschiedene Login-Systeme und keinen Prozess dahinter. Im Kurs entsteht die komplette IAM-Infrastruktur — von der Krisenbewältigung, wenn der größte Kunde mit Kündigung droht, bis zur Implementierung von User Lifecycle Management und Audit Trails. Echte Keycloak-Server, echte Probleme, echte Lösungen.

## Lerninhalte

Aufbau von production-ready Keycloak mit Multi-Tenant-Architektur, Anbindung an Active Directory für Enterprise-Kunden und Social Provider für einfachen Zugang. Automatisierung des kompletten User-Lifecycle von Provisioning bis Deprovisioning, Implementierung von Audit Trails für Compliance und Monitoring-Setup, das Probleme erkennt, bevor User sich beschweren. Am wichtigsten: Verstehen, wann welches Feature zum Einsatz kommt und warum es fürs Business relevant ist.

## Zielgruppe

- **DevOps Engineers** mit der Aufgabe, Enterprise SSO zu implementieren
- **CTOs und IT-Manager** die IAM-Entscheidungen und Trade-offs verstehen müssen
- **Entwickler** die OAuth2/OIDC in Anwendungen integrieren
- **Startup-Gründer** mit Enterprise-Kunden-Authentifizierungs-Anforderungen

## Voraussetzungen

Keine OAuth2- oder Keycloak-Kenntnisse nötig. Wer versteht, wie Web-Apps funktionieren (Browser sendet Requests an Server), kann direkt loslegen.

# Glückwunsch

IAM Simulator abgeschlossen. Jetzt sollte Folgendes möglich sein:

- Keycloak-Server aufsetzen und konfigurieren
- Realms, User und Rollen erstellen und verwalten
- Anwendungen via OIDC und andere Protokolle integrieren
- Erweiterte Keycloak-Features konfigurieren

## Nächste Schritte

Zeit für Keycloaks fortgeschrittene Features wie Custom Authentication Flows, Themes und Federation-Möglichkeiten.

# Bevor es losgeht

Willkommen bei Enterprise IAM & SSO mit Keycloak. Bevor die Authentication-Challenge startet, die unsere Story einleitet, noch ein paar Dinge, damit der Kurs richtig was bringt.
 
## Kurszugang

Nach Abschluss des Kurses bleibt der Zugang zu allen Materialien bestehen. Wenn also Monate später ähnliche IAM-Herausforderungen im Job auftauchen, einfach zurückkommen und nachschlagen. Alles bleibt verfügbar, wenn es gebraucht wird.

## Kurs-Challenges

**Alles nutzen, was bei Quiz / Lab Challenge hilft:**
- Unklares googeln
- Erfahrene Kollegen nach ihrer Sicht fragen
- Eigene Erfahrung auf die Probleme anwenden
- Stack Overflow, Dokumentation, was auch immer funktioniert

Wie im echten Job - alle verfügbaren Ressourcen nutzen, um die Challenges zu lösen.

**Wichtig:** Einmal abgeschickte Antworten im Simulator können nicht geändert werden. Wie im echten Leben - Entscheidung treffen und mit den Konsequenzen leben. So bleibt das Gelernte besser hängen.

## Erfolgreich durchkommen

Die besten Ergebnisse gibt's bei regelmäßigem Lernen.

Mindestens eine Stunde täglich für den Simulator einplanen. Am besten feste Zeit und fester Ort - vielleicht früh morgens vor der Arbeit, oder abends wenn's ruhiger wird. Regelmäßiges Üben schlägt intensives Pauken jedes Mal.

Das Ganze dauert in diesem Tempo etwa 5-7 Wochen. Nach 2 Wochen sitzt Keycloak-Basis schon ziemlich sicher.

## Über die Story

Alle Ereignisse und Charaktere in unserer Story sind fiktiv, basieren aber auf echten Situationen aus unserer Beratungspraxis. Falls bekannte Muster aus der eigenen Firma auftauchen... vielleicht haben wir ja zusammengearbeitet, oder diese Probleme sind einfach universell. Ob den Kollegen erzählt wird "hey, das ist exakt wie bei uns!" - völlig freie Entscheidung.

## Gut zu wissen

**Bug oder Typo gefunden:** Kurze Mail an support@authpractice.com - wir sind ein kleines Team und freuen uns echt über Hilfe, alles sauber zu halten.

**Lab-Umgebungen:** Jede Lab-Umgebung ist für jeden Studenten isoliert konzipiert. Bei geteilten Umgebungen gibt's Read-Only-Zugriff, damit alle ungestört lernen können. Falls was nicht wie erwartet funktioniert - bitte Bescheid geben!

## Weitersagen

Wir sind eine kleine Beratung, kein großer Bildungskonzern. Wir haben diesen Kurs gebaut, weil wir ständig dieselben IAM-Probleme lösen mussten - dachten uns, so erreichen wir mehr Leute.

Wenn dir das hier weiterhilft, erzähl gerne davon. Ein LinkedIn-Post, ein Tipp an Kollegen die mit Keycloak kämpfen - was sich für dich richtig anfühlt.

Am Ende fragen wir nach deinem ehrlichen Feedback. Egal ob "OAuth2 endlich gerafft" oder "das war noch nichts" - hilft uns alles weiter. Außerdem: Zu wissen, dass da draußen echte Menschen mit unserem Kurs arbeiten? Das motiviert uns richtig.

Danke, dass du dabei bist.

## Auf geht's

So, machen wir dich zur ersten Adresse, wenn Auth richtig laufen soll.

Mögen deine Tokens immer validieren und deine Sessions niemals unerwartet ablaufen.

::: 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: Letzter Interviewschritt - Kurzer technischer Check
timestamp: vor 1 Stunde
priority: normal
cardStyle: contrast
attachments:
  - name: final-interview-questions (1).docx
    size: 1.8MB
    type: document
---
Hi!

Glückwunsch, es ist die letzte Runde - nur noch zwei Kandidaten übrig!

Ich bin Tom, der CTO, und das ist mein Teil des Prozesses.

Woran wir arbeiten: Wir verwandeln mit LLMs Geschäftsdokumente in strukturierte Daten für Unternehmen — Verträge, Krankenakten, Finanzberichte. Anstatt dass Teams manuell Informationen aus tausenden PDFs extrahieren, analysieren und extrahieren wir automatisch das Wichtige. Wir erhöhen die Verarbeitungsgeschwindigkeit um das 100-fache für Banken, Anwaltskanzleien und Gesundheitsunternehmen.

Diese Kunden vertrauen uns ihre vertraulichsten Daten an, deshalb sind Sicherheit und Authentifizierung für uns kritisch.

Und das bringt mich zu dir.

Wir wissen, dass du noch kein Auth-Experte bist - du warst ehrlich darüber. Das gefällt mir tatsächlich an dir. Der letzte "Experte", den wir interviewt haben, konnte den Unterschied zwischen Authentication und Authorization nicht erklären. Du wärst überrascht, wie häufig das vorkommt.

Ich muss nur deinen aktuellen Wissensstand verstehen, um die finale Entscheidung zu treffen.

Dauert etwa 20-30 Minuten. Einige dieser Fragen stammen aus echten Kundenanfragen - Enterprise-Kunden haben interessante Anforderungen.

Viel Erfolg!
 
- Tom
:::

# Authentication vs Authorization

**Maria versucht, auf das System zuzugreifen. Das System prüft zwei Dinge:**

1. "Ist das wirklich Maria?" (überprüft ihr Passwort)
2. "Darf Maria auf die Finanzdaten der Kunden zugreifen?" (prüft ihre Berechtigungen)

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

::: quiz
- radio: "Die erste Prüfung ist:"
  options:
    - correct: Authentication
    - Authorization
- radio: "Die zweite Prüfung ist:"
  options:
    - Authentication
    - correct: Authorization
- success: |
    **Richtig!** Der grundlegende Unterschied zwischen Authentication und Authorization ist klar.
    
    Authentication beweist die Identität ("Wer bist du?"). Authorization bestimmt die Berechtigungen ("Was darfst du?").  
    
    Viele Sicherheitslücken entstehen, wenn Systeme korrekt authentifizieren, aber schlecht autorisieren - ja, es ist Maria, aber Maria aus dem Marketing sollte nicht auf Finanzdatenbanken zugreifen können.
:::

# Der temporäre Fix

**Beim Code Review findest du das in Production:**
``` javascript
// TODO: TEMPORÄR - Nach Demo am Freitag entfernen!!!
const ADMIN_TOKEN = "full_access_everything";
// Nur für die Investoren-Präsentation
```

::: quiz
- radio: "Zwei Jahre später ist dieser Token wahrscheinlich:"
  options:
    - Direkt nach der Demo entfernt wie geplant
    - Ordentlich in den Sicherheitsrichtlinien dokumentiert
    - correct: Immer noch in Produktion und übernimmt kritische Funktionen
    - Deaktiviert, aber niemand erinnert sich warum er existiert
- success: |
    Demo erfolgreich, Funding bekommen, gefeiert... und alle haben den Token vergessen.
    
    Zwei Jahre später übernimmt er wahrscheinlich kritische Funktionen. "Temporärer" Code wird gerne permanent, besonders wenn er funktioniert.
    
    Solche vergessenen Hintertüren verursachen unzählige Sicherheitslücken.
:::

# Was ist Multi-Faktor-Authentifizierung?

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


::: quiz
- radio: "Deine Bank verlangt Passwort + SMS-Code. Das liegt daran:"
  options:
    - Passwörter müssen länger und komplexer sein
    - correct: Selbst wenn das Passwort gestohlen wird, braucht der Angreifer auch dein Handy
    - Es verhindert automatisierte Bot-Angriffe
    - Banken machen gerne alles kompliziert
- success: |
    Das Grundprinzip von MFA - es geht um **verschiedene Arten** von Nachweisen, nicht nur um stärkere Nachweise.
    
    Selbst wenn Hacker dein Passwort durch Phishing, Keylogger oder Datenlecks stehlen, bräuchten sie trotzdem physischen Zugang zu deinem Handy.
    
    Deshalb funktioniert es - es geht nicht darum, Passwörter besser zu machen, sondern einen komplett anderen Authentifizierungsfaktor hinzuzufügen. (Ja, es ist oft auch gesetzlich vorgeschrieben, aber der Sicherheitsvorteil ist das was zählt)
:::

# MFA-Faktoren

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

::: quiz
- multiple: "Welche sind ECHTE MFA-Faktor-Kategorien? (alle zutreffenden auswählen)"
  options:
    - correct: Etwas was du weißt (Passwort, PIN)
    - Etwas komplexes genug (20+ Zeichen Passphrase)
    - correct: Etwas was du hast (Handy, Hardware-Token)
    - correct: Etwas was du bist (Fingerabdruck, Gesichtsscan)
    - Etwas was du monatlich änderst (rotierende Passwörter)

- success: |
    **Richtig!** Viele verwechseln stärkere Sicherheitsmaßnahmen mit zusätzlichen Faktoren.

    "Etwas was du monatlich änderst" und "etwas komplexes genug" sind nur stärkere Versionen von "etwas was du weißt" - sie basieren immer noch auf Wissen.
    
    Echte MFA erfordert verschiedene Faktor-Typen, nicht nur bessere Passwörter.
    
    Moderne Fintech-Apps binden dein Handy während der Einrichtung (etwas was du hast) und fügen Biometrie hinzu (etwas was du bist).
    
    Traditionelle Banken nutzen Passwort (etwas was du weißt) plus SMS-Codes oder TAN-Generatoren (etwas was du hast).
    
    Verschiedene Implementierungen, gleiches Prinzip - Kombination verschiedener Faktor-Typen.
:::

# Der hilfreiche Fehler

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

**Login-System zeigt verschiedene Meldungen:**
1. "Ungültiger Benutzername" 
2. "Ungültiges Passwort"

::: quiz
- radio: "Warum ist das eine Sicherheitslücke?"
  options:
    - Ist es nicht - es ist hilfreich für Benutzer
    - Passwörter sind nicht stark genug
    - correct: Angreifer wissen jetzt, welche Benutzernamen existieren
    - Sollte stattdessen MFA verwenden
- success: |
    **Genau richtig!** Indem das System bestätigt, welche Benutzernamen existieren, gibst du Angreifern die Hälfte des Rätsels.
    
    Sie können sich jetzt auf Passwort-Angriffe für bekannte Accounts konzentrieren. Bessere Praxis: immer _"Ungültiger Benutzername oder Passwort"_ anzeigen, um Informationslecks zu vermeiden.
:::

# Die Sicherheitslogs lesen

``` 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: "Welche Geschichte erzählen diese Logs?"
  options:
    - Normale Morgenroutine mit VPN-Nutzung
    - Sarah hat Zugang mit IT-Kollegen für Troubleshooting geteilt
    - correct: Jemand hat Sarahs Zugangsdaten gestohlen und versucht Spuren zu verwischen
    - Penetrationstest vom Sicherheitsteam
- success: |
    **Genau, das ist passiert.** Klassisches Muster für gestohlene Zugangsdaten: Legitimer Login vom Büro, Logout, sofortiger Login über Tor (Identität verstecken), Datenexport, gescheiterter Versuch die Beweise zu löschen, dann kann die echte Sarah nicht mehr einloggen (Angreifer hat Passwort geändert).
    
    Drei rote Flaggen:
    1. Der TorExitNode - normale Benutzer wechseln nicht plötzlich zu Tor.
    2. Export ALLER Datensätze - selbst CEOs brauchen selten alles auf einmal.
    3. Versuch die Authentication-Logs zu löschen - warum sollte eine CEO ihre eigenen Aktionen verstecken?
    
    Diese Kombination schreit "Angreifer versucht Daten zu stehlen und Spuren zu verwischen." Ohne diese Logs hättest du nie erfahren, was passiert ist.
:::

# Entwicklungsumgebung

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

**Wie sollten Entwicklungsumgebungen auf Daten zugreifen?**

Aktuelles Setup:
- Dev verbindet sich mit Produktionsdatenbank (read-only)
- 15 Leute haben Dev-Zugang  
- "Ist sicher, weil read-only"

::: quiz
- radio: "Deine Sicherheitsbewertung:"
  options:
    - Kein Risiko - okay mit read-only
    - Geringes Risiko - Monitoring für Dev-Queries hinzufügen
    - Mittleres Risiko - starke Passwörter für Devs sicherstellen
    - correct: Kritisches Risiko - Dev sollte Testdaten verwenden
- success: |
    Dev-Umgebungen sind unsicher by Design - schwächere Passwörter, mehr Leute mit Zugang, weniger Monitoring.
    
    Read-only auf Production bedeutet: Jeder kompromittierte Dev-Rechner legt alle Kundendaten offen. Ein infizierter Praktikanten-Laptop wird zum Datenleck. Immer anonymisierte Testdaten in der Entwicklung verwenden.
:::

# Montagmorgen-Updates

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

**Montagmorgen-Posteingang:**
- "Willkommen unserem neuen Entwickler!"
- "Sarah wechselt von Sales zu Finance"
- "Mikes letzter Tag war Freitag"

**Zwei Monate später:**
- Neuer Dev hat GitHub aber wartet noch auf CI/CD-Zugang
- Sarah hat Zugang zu Sales UND Finance Systemen
- Mikes E-Mail/Kalender gesperrt aber hat noch vollen CRM-Zugang mit allen Kundendaten

::: quiz
- radio: "Was ist die Grundursache dieses Chaos?"
  options:
    - IT-Team ist überlastet mit Anfragen
    - correct: Es existiert überhaupt kein IAM-Prozess
    - Fehlende automatisierte Bereitstellungstools
    - Schlechte Kommunikation zwischen Abteilungen
- success: |
    **Genau das ist es!** Es gibt einfach keinen Prozess für User-Lifecycle-Management - nichts für Neueinstellungen, Wechsler oder Ausscheidende.
    
    Dein neuer Entwickler kann Code sehen aber nicht deployen, Sarah sammelt Berechtigungen wie Pokemon-Karten, und Mike kann keine E-Mails mehr checken aber trotzdem noch eure komplette Kundendatenbank exportieren. Studien zeigen: 89% der Ex-Mitarbeiter können noch auf Firmensysteme zugreifen. Sicherheit ist nicht nur Technologie - es sind echte Prozesse (dokumentiert oder nicht, aber am besten dokumentiert).
:::

# Perfekte Sicherheit

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

**Dein Konkurrent prahlt: "Unser System ist unhackbar! Wir verlangen:**
- 30-Zeichen-Passwörter, wöchentlich geändert
- Iris-Scan + Fingerabdruck + Gesichtserkennung  
- Hardware-USB-Sicherheitsschlüssel
- SMS-Bestätigungscode

::: quiz
- multiple: "Was passiert in der Realität? (alle zutreffenden auswählen)"
  options:
    - correct: Klebezettel mit Passwörtern unter jeder Tastatur
    - correct: Teams teilen sich einen Account um den Aufwand zu vermeiden
    - correct: IT verbringt die meiste Zeit mit Passwort-Resets
    - correct: Kunden beschweren sich und wechseln zur Konkurrenz
    - correct: Excel-Datei "passwörter.xlsx" auf dem geteilten Laufwerk
- success: |
    **Alles davon!** Das passiert bei über-engineerter Sicherheit.
    
    Klebezettel überall. Teams teilen sich den "admin123" Account. IT macht nichts außer Resets. Kunden schreiben schlechte Bewertungen. Und die passwörter.xlsx Datei? Heißt wahrscheinlich "NICHT_TEILEN_PASSWÖRTER_2025.xlsx" für extra Ironie. Das sicherste System, das niemand richtig benutzt, ist weniger sicher als ein einfaches System, das ordentlich verwendet wird.
    
    Sicherheit muss MIT der menschlichen Natur arbeiten, nicht dagegen.
:::

# Das unbekannte Akronym

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

**Freitag, 16:47 Uhr. Call mit BigBankCorp (potenzieller 500K€/Jahr Vertrag):**

"Wir brauchen SAML 2.0 SSO Integration mit unserer Okta-Instanz bis Q2. Das ist verpflichtend für alle Anbieter."

Du hast noch nie von SAML gehört.

::: quiz
- radio: "Deine Antwort:"
  options:
    - "Absolut, SAML 2.0 ist unsere Spezialität"
    - "Wir unterstützen keine Enterprise-Authentifizierung"
    - correct: "Ich muss unsere SAML-Roadmap mit dem Team besprechen und melde mich Montag zurück"
    - "Unsere API-Keys sind sicherer als SSO"
- success: |
    **Richtige Antwort!** Du hast Zeit gewonnen ohne zu lügen oder den Deal zu verlieren.
    
    Tech ist voller Akronyme, die du nicht kennst - SAML, SCIM, OIDC, PKCE. Wissenslücken zugeben und gleichzeitig Engagement zeigen ist professionell. Expertise vortäuschen führt zu verpassten Deadlines und verlorenem Vertrauen.
    
    Der reife Ansatz: Recherchieren, Fähigkeiten verstehen, dann mit realistischen Timelines zusagen. (BTW: SAML ist wie Enterprises Single Sign-On machen, und ja, du wirst es für BigBankCorp brauchen.)
:::

# Montags Audit

**Freitag, 15 Uhr. CEO leitet E-Mail weiter:**

> Security-Audit-Team kommt Montag 9 Uhr.  
> Sie werden alles pentesten.  
> Letztes Unternehmen das sie geprüft haben verlor ihren größten Kunden nach dem Report.  
> Repariert was ihr könnt.  
> -Sarah (CEO)

**Dein Security-Scan zeigt:**
- Kein HTTPS auf Admin-Panel
- DEV_MASTER_TOKEN hardcoded in Production 
- Kein Rate Limiting bei Login-Versuchen
- 15 ungenutzte User-Accounts von Ex-Mitarbeitern

::: quiz
- radio: "Du hast 2 Stunden vor dem Wochenende. Priorität?"
  options:
    - Let's Encrypt für HTTPS einrichten
    - correct: DEV_MASTER_TOKEN aus Production entfernen
    - Rate Limiting mit fail2ban implementieren
    - Alle ungenutzten Accounts deaktivieren
- success: |
    **Kritische Schwachstelle zuerst beheben, dann allgemeine Sicherheit verbessern.**
    
    HTTPS ist wichtig, aber der DEV_MASTER_TOKEN ist eine kritische Hintertür mit komplettem Systemzugang.
    
    Das ist wie sich um Fensterschlösser zu sorgen während die Haustür sperrangelweit offen steht. Jeder Junior-Pentester findet hardcoded Tokens in 5 Minuten und übernimmt dein komplettes System.
:::

# Mehr als nur Passwörter

**BigClients IT-Team ruft dich dringend an:**

> Euer Authentifizierungssystem hat unseren CEO während einer Vorstandssitzung in Singapur blockiert!  
> Er hat das korrekte Passwort UND den SMS-Code eingegeben, aber euer System hat gemeldet:
> - Neues Gerät (iPad noch nie gesehen)
> - Ungewöhnlicher Ort (Singapur Hotel-WiFi)
> - Seltsame Zeit (3 Uhr morgens Ortszeit)
> - Verdächtige Aktivität (50 Dateien in 2 Minuten heruntergeladen)
> 
> Er ist wütend. Euer System hat ihn blockiert obwohl seine Zugangsdaten korrekt waren.  
> Sollen wir diese Sicherheitsprüfungen deaktivieren?

::: quiz
- radio: "Was ist der beste Ansatz?"
  options:
    - Alle Standort- und Geräte-Checks entfernen
    - Jedem mit korrektem Passwort + MFA vertrauen
    - correct: Zusätzliche Sicherheitsfragen bei ungewöhnlichem Kontext stellen
    - Alle Logins von neuen Geräten blockieren
- success: |
    Moderne Authentifizierung umfasst Kontext-Checks - nicht nur "ist das Passwort korrekt?" sondern auch "macht dieses Login-Muster Sinn?" Zeit, Ort, Gerät und Verhaltensmuster werden alle Teil der Sicherheitsentscheidung.
    
    Wenn etwas verdächtig aussieht (CEO plötzlich in Singapur um 3 Uhr morgens), sollte das System:
    1. zusätzliche Verifikation über andere Kanäle anfordern,
    2. dies als hochpriorität Sicherheitsereignis loggen, auch wenn Verifikation erfolgreich ist.
    
    Das fängt Angriffe ab, die korrekte Passwörter verpassen würden, wie wenn jemandes Zugangsdaten gestohlen und aus einem anderen Land verwendet werden.
    
    Deshalb rufen Banken bei ungewöhnlichen Transaktionen an anstatt deine Karte zu sperren - und warum sie Aufzeichnungen über jedes ungewöhnliche Muster führen.
:::

Enterprise IAM & SSO mit Keycloak

IAM Simulator

Lerninhalte

Zielgruppe

Voraussetzungen

Kursinhalt

Final Interview

Willkommen

Untersuchung

Alter Freund

OAuth2 und OIDC

From Zero to Hero

Erste Katastrophe

API-Token

Wer hat dieses Token ausgestellt?

Keine Devs mehr in Prod!

Skalierung der Abläufe

Mobile Client (PKCE)

Enterprise Integrations

Von On-Premise zur Cloud

Externes Audit?!

Sicherheits-Upgrade

Basis-Monitoring

Produktionssicherheit

Serie B