Wie die direkte Keycloak-Anbindung im HEINZELMANN Service.Desk webnative Authentifizierung, Single Sign-On und Multi-Faktor-Authentifizierung ermöglicht.
Keycloak schafft eine moderne Authentifizierungsschicht für den HEINZELMANN Service.Desk. Identitäten können zentral eingebunden, webnative Protokolle genutzt und Zugriffe über Applikationsgrenzen hinweg konsistent abgesichert werden – ohne das vorhandene Active Directory zwangsläufig abzulösen.
Kapitel 1
Hybride IT, browserbasierte Anwendungen und externe Nutzergruppen verändern die Anforderungen an Identity & Access Management. Klassische Domänenstrukturen bleiben wichtig, reichen als alleinige Integrationsschicht für eine vernetzte Service-Organisation jedoch häufig nicht mehr aus.
Die strategische Aufgabe lautet deshalb nicht „Active Directory oder Keycloak?“, sondern: Welche Identitätsquelle ist führend – und welche Schicht stellt sichere, standardisierte Zugriffe für moderne Anwendungen bereit? Keycloak übernimmt dabei die Rolle eines zentralen Identity Providers und Identity Brokers. Bestehende Verzeichnisse können angebunden werden, während Anwendungen über OpenID Connect (OIDC) oder SAML auf konsistente Authentifizierungsprozesse zugreifen.
Webnative Protokolle reduzieren die Abhängigkeit von rein domänengebundenen Anmeldeszenarien und erleichtern hybride Betriebsmodelle.
Keycloak bündelt Authentifizierungswege, gibt signierte Tokens aus und stellt Anwendungen einheitliche Identitätsinformationen zur Verfügung.
Keycloak lässt sich als zentraler Identity Provider direkt an den HEINZELMANN Service.Desk anbinden.
Ein moderner PHP-/Laravel-Stack bildet die Grundlage für sichere Schnittstellen, Automatisierung und kontrollierbare KI-Szenarien.
Keycloak ist kein pauschaler 1:1-Ersatz für sämtliche Active-Directory-Funktionen wie Geräte-, Gruppenrichtlinien- oder Windows-Domänenverwaltung. Seine Stärke liegt in der zentralen Authentifizierung, Föderation und Absicherung moderner Anwendungen. In vielen Architekturen arbeiten AD beziehungsweise LDAP und Keycloak deshalb zusammen.
Kapitel 2
Ein lokales Active Directory ist für interne Windows-Domänen und Kerberos-basierte Prozesse optimiert. Keycloak ergänzt diese Welt um browserfähige Standards, Identity Brokering und tokenbasierte Zugriffe für Web-Anwendungen.
| Kriterium | Active Directory | Keycloak IAM |
|---|---|---|
| Primäre Aufgabe | Verzeichnis-, Domänen- und Geräteverwaltung | Identity Provider, SSO und Identity Brokering |
| Architekturfokus | Domänenzentriert und typischerweise on-premises | Web-, Cloud- und Hybrid-Szenarien |
| Protokolle | Vor allem LDAP und Kerberos | OpenID Connect, OAuth 2.0 und SAML 2.0 |
| Web-Interoperabilität | Für moderne Web-Apps häufig zusätzliche Föderation oder Proxies | Native Anbindung standardkonformer Web-Anwendungen |
| Authentifizierungsmodell | Domänen- und sitzungsbezogene Anmeldung | Weiterleitung zum IdP und signierte Tokens |
| Sicherheitsbeitrag | Stark in der internen Windows- und Gerätewelt | MFA, zentrale Flows und Baustein für Zero-Trust-Architekturen |
| Betriebsmodell | Proprietäre Microsoft-Plattform | Open Source, selbst betreibbar und anpassbar |
Identitäten müssen nicht zwingend in Keycloak neu aufgebaut werden. Der Identity Provider kann vorhandene Verzeichnisdienste oder weitere Identitätsquellen anbinden und den angeschlossenen Anwendungen eine konsistente Authentifizierungsschicht bereitstellen.
Tokenbasierte Authentifizierung allein erzeugt noch keine Zero-Trust-Architektur. Sie liefert jedoch einen wichtigen Baustein: Jede Anwendung kann Identität, Token-Gültigkeit, Rollen und weitere Claims prüfen. Ergänzend bleiben Least Privilege, sichere Endgeräte, Netzwerksegmentierung, Protokollierung und laufende Überwachung erforderlich.
Kapitel 3
Die Projektbeispiele zeigen zwei unterschiedliche Stärken derselben Architektur: die kontrollierte Einbindung externer Partner und einen standardisierten Authentifizierungspfad für anspruchsvolle Organisationsstrukturen.
Bei einem international tätigen Maschinenbauunternehmen dient Keycloak als zentrales Identitäts-Gateway für interne Bereiche und externe Partner. Händlerportale, Kundenplattformen und Wissensangebote können über eine konsistente Identität abgesichert werden.
Nutzen: weniger Identitätssilos, zentral steuerbare Anmeldeprozesse und granulare Zugriffsoptionen für unterschiedliche Partnergruppen.
Bei einer deutschen Kommunalverwaltung entstand aus einer konkreten Projektanforderung ein wiederverwendbarer Integrationspfad für den HEINZELMANN Service.Desk. MFA und konfigurierbare Authentifizierungsflüsse können so in einen zentralen Identity-Ansatz eingebunden werden.
Nutzen: Ein standardisierter Weg reduziert individuellen Entwicklungsaufwand und unterstützt Sicherheitsmaßnahmen, wie sie unter anderem im NIS‑2-Kontext relevant sind.
MFA, Zugriffskontrolle und Identitätsmanagement sind relevante Sicherheitsmaßnahmen. Eine Keycloak-Integration führt jedoch nicht automatisch zu NIS‑2-Konformität. Entscheidend sind die risikobasierte Ausgestaltung, dokumentierte Prozesse, Verantwortlichkeiten und der Nachweis ihrer Wirksamkeit.
Kapitel 4
Die Integration entkoppelt die Anmeldung von einer direkten Passwortprüfung im Service.Desk. Im empfohlenen Authorization-Code-Flow authentifiziert sich der Benutzer beim Identity Provider; die Anwendung erhält anschließend prüfbare Tokens.
HTTPS, Zertifikate, DNS, Verfügbarkeit, Backup und Administrationszugänge bilden die betriebliche Basis.
Client-Typ, erlaubte Redirect-URIs und Web Origins werden so eng wie möglich definiert.
Client-ID und – bei einem vertraulichen serverseitigen Client – das Client Secret werden geschützt im Backend hinterlegt.
Mapper übertragen die benötigten Identitätsmerkmale. Das Rollenmodell des Service.Desk bleibt dabei bewusst und nachvollziehbar steuerbar.
Neben dem Happy Path gehören Token-Ablauf, Widerruf, Rollenänderung, Ausfall des IdP und Notfallzugänge in den Abnahmetest.
Bei diesem Flow wird das Benutzerpasswort nicht an den HEINZELMANN Service.Desk übermittelt. Die Anwendung validiert stattdessen Aussteller, Signatur, Zielgruppe und Gültigkeit der Tokens. Durchgängiges HTTPS bleibt für sämtliche Kommunikationswege unverzichtbar.
Kapitel 5
Keycloak lässt sich nun direkt als zentraler Identity Provider an den HEINZELMANN Service.Desk anbinden. Damit steht ein standardisierter Authentifizierungspfad für Single Sign-On, MFA und zentral steuerbare Anmeldeprozesse zur Verfügung.
SSO · MFA · signierte Tokens
Authentifizierung · Rollen-Mapping · Sitzung
Der HEINZELMANN Service.Desk wird dafür als eigener OIDC-Client in Keycloak registriert. Die Anmeldung erfolgt beim Identity Provider; der Service.Desk validiert anschließend die übermittelten Tokens und ordnet die benötigten Rollen und Gruppen zu.
Benutzer melden sich über Keycloak an. Der Service.Desk erhält prüfbare Identitätsinformationen, ohne das Benutzerpasswort selbst zu verarbeiten.
Claims, Gruppen und Rollen lassen sich nachvollziehbar auf die Berechtigungsstruktur im HEINZELMANN Service.Desk abbilden.
Single Sign-On vereinheitlicht die Anmeldung, nicht automatisch sämtliche Berechtigungen. Rollen, Datenbereiche und erlaubte Aktionen müssen im HEINZELMANN Service.Desk definiert, gemappt und regelmäßig überprüft werden.
Kapitel 6
Die direkte Keycloak-Anbindung erweitert den HEINZELMANN Service.Desk um einen modernen, standardbasierten Authentifizierungspfad. Ihr größter Wert entsteht im Zusammenspiel von Identity Governance, sicherer Konfiguration und klar geregelten Rollen- und Berechtigungsprozessen.
Erfassen Sie Anwendungen, Identitätsquellen, Nutzergruppen, Protokolle und bestehende Sonderlösungen. Markieren Sie besonders direkte Passwortprüfungen, Mehrfachkonten und unklare Verantwortlichkeiten.
Beginnen Sie mit internetnahen Anwendungen, privilegierten Konten und externen Nutzergruppen. Definieren Sie OIDC-Flows, MFA-Verfahren, Rollen-Mappings und Notfallzugänge gemeinsam.
Stimmen Sie Keycloak-Gruppen und Claims mit den Rollen im HEINZELMANN Service.Desk ab. Prüfen Sie dabei zentrale Anmeldung und fachliche Berechtigungen getrennt.
Bewerten Sie künftige Technologie- und KI-Einführungen anhand konkreter Einsatzfälle. Legen Sie Datenzugriffe, Qualitätssicherung, Verantwortlichkeiten und zulässige Automatisierungsgrade vor der Einführung fest.
So entsteht keine isolierte Login-Funktion, sondern eine belastbare Identitätsschicht für sichere Serviceprozesse, konsistente Anmeldewege und künftige Automatisierung.
Kapitel 7
In der Regel nicht vollständig. Active Directory übernimmt unter anderem Domänen-, Geräte- und Gruppenrichtlinienfunktionen. Keycloak konzentriert sich auf Identity Provider, Single Sign-On, moderne Web-Protokolle und Identity Brokering. Beide Systeme können sinnvoll zusammenarbeiten.
OpenID Connect ist ein webnativer Identitätsstandard auf Basis von OAuth 2.0. Er ermöglicht browserbasierte Anmeldeflüsse, signierte Tokens und eine klare Trennung zwischen Authentifizierung beim Identity Provider und der Fachanwendung.
Beim empfohlenen Authorization-Code-Flow meldet sich der Benutzer direkt bei Keycloak an. Der Service.Desk verarbeitet anschließend Autorisierungscode und Tokens, nicht das Benutzerpasswort.
Nein. Sie unterstützen wichtige Maßnahmen rund um Authentifizierung und Zugriffskontrolle. NIS‑2 erfordert jedoch ein umfassendes, risikobasiertes Sicherheitsmanagement mit weiteren technischen, organisatorischen und dokumentarischen Maßnahmen.
Nein. SSO vereinheitlicht primär die Anmeldung. Welche Daten und Funktionen ein Benutzer aufrufen darf, bestimmen die Rollen- und Berechtigungskonzepte der jeweiligen Anwendung sowie das konfigurierte Mapping.
Ja. Keycloak ist Open Source und lässt sich selbst betreiben. Architektur, Hochverfügbarkeit, Updates, Monitoring, Backup und sichere Administration müssen dabei professionell geplant werden.
