SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren

SUSE Multi-Linux Manager ist ein zentrales Administrationssystem. Deshalb gehört die Anmeldung in produktiven Umgebungen in die bestehende Unternehmens-Identity: zentrale Benutzer, MFA, Rollen, Auditierbarkeit und kontrolliertes Offboarding.

Der relevante Integrationspfad ist SAML. Keycloak authentifiziert die Benutzer als Identity Provider. SUSE Multi-Linux Manager bleibt Service Provider und entscheidet weiterhin über Rollen und Berechtigungen im Manager.

https://mlm01.example.test

Zielbild

Der Admin öffnet https://mlm01.example.test. Der Manager leitet zu Keycloak weiter. Keycloak prüft Benutzer, Passwort, MFA und Richtlinien. Danach kommt der Benutzer zurück zum Manager und erhält dort nur die Rollen, die explizit vorgesehen sind.

SSO bedeutet nicht automatisch Administratorrechte. Authentifizierung klärt, wer jemand ist. Autorisierung klärt, was diese Person darf.

Keycloak vorbereiten

Lege einen eigenen Realm oder einen klar getrennten Client im bestehenden Realm an. Redirect-URIs müssen eng gesetzt sein, MFA sollte über Realm-, Gruppen- oder Conditional-Policies erzwungen werden. Private Testkonten gehören nicht in einen produktiven Admin-Fluss.

manager_url: https://mlm01.example.test
realm: forgeone-operations
client: suse-multi-linux-manager
protocol: SAML
mfa_policy: required for administrators

SAML-Client anlegen

Der SAML-Client bekommt als Client ID den Metadata-Endpunkt des Managers. Die Assertion Consumer Service URL zeigt auf den ACS-Endpunkt des Managers. Verwende den echten Manager-FQDN, nicht localhost, keinen SSH-Tunnel und keinen temporären Port.

Client ID=https://mlm01.example.test/rhn/manager/sso/metadata
Valid redirect URI=https://mlm01.example.test/rhn/manager/sso/acs
Name ID format=persistent oder username-basiert
Force POST binding=nach IdP-Policy aktivieren

Mapper, Zertifikat und Metadaten

Für den Start reichen stabile Mapper für Benutzername, Anzeigename und E-Mail. Der Manager muss außerdem dem öffentlichen SAML-Zertifikat des Identity Providers vertrauen. Private Schlüssel gehören nie in Screenshots, Tickets, Git oder öffentliche Beiträge.

curl -k https://mlm01.example.test/rhn/manager/sso/metadata
# Keycloak-Metadaten über abgesicherten Admin-Zugriff exportieren
# Öffentliches IdP-Zertifikat im Manager nach unterstütztem Verfahren hinterlegen

Manager konfigurieren

Die Manager-Konfiguration verbindet Keycloak-Metadaten mit dem lokalen Rollenmodell. Plane diesen Schritt wie einen produktiven Change: Wartungsfenster, Rollback, Break-Glass-Admin, Browser-Test und Auditprüfung.

mgrctl status
mgrctl exec -- bash -lc 'spacewalk-service status'
# SSO-Konfiguration einspielen
# Manager-Services kontrolliert neu laden oder neu starten
mgrctl status

MFA und Rollen testen

Teste einen Administrator, einen Read-only-Benutzer, einen Benutzer ohne Rolle und einen deaktivierten Benutzer. MFA muss im Keycloak-Fluss erzwungen werden. Der Manager darf aus einer erfolgreichen Anmeldung keine ungewollten Rechte ableiten.

acceptance: login_with_keycloak: geprüft mfa_required: geprüft disabled_user_blocked: geprüft user_without_role_blocked: geprüft read_only_user_cannot_patch: geprüft admin_user_can_open_reports: geprüft local_break_glass_admin_available: geprüft

Reports und Audit

Nach der SSO-Integration müssen Reports weiterhin nachvollziehbar bleiben. Prüfe Benutzerlisten, Systemzugriffe, geplante Aktionen und Auditdaten. Für Security-Teams ist wichtig, dass der Login zentral erfolgt, aber Aktionen im Manager weiterhin einem Benutzer zuordenbar sind.

spacewalk-report users
spacewalk-report users-systems
spacewalk-report actions
spacewalk-report system-history

Supportmodell und Grenzen

SUSE beschreibt Keycloak als Beispiel für SAML-SSO. In produktiven Projekten muss klar sein, welche Teile vom SUSE-Support, vom Identity-Team und vom Betriebsdienst verantwortet werden. Diese Klärung gehört vor den Go-live, nicht erst in den Störfall.

Identity-Lifecycle und Offboarding

SSO ist besonders wertvoll, wenn Benutzer nicht manuell in mehreren Administrationssystemen gepflegt werden sollen. Neue Administratoren werden über den Identity-Prozess berechtigt, Rollen werden nachvollziehbar vergeben, und beim Austritt reicht nicht ein vergessenes lokales Konto aus, um später noch Zugriff zu haben.

Trotzdem bleibt der Manager ein sicherheitskritisches System. Gruppen aus Keycloak dürfen deshalb nicht unkontrolliert zu Superuser-Rechten führen. Wir trennen Authentifizierung, Gruppenzuordnung und Manager-Rolle bewusst voneinander.

MFA für privilegierte Konten

Für Administratoren sollte MFA verpflichtend sein. Sinnvoll ist eine Policy, die mindestens alle Manager-Administratoren betrifft und im Zweifel auch Read-only-Zugriffe auf sicherheitsrelevante Reports schützt. Für Notfallkonten gelten eigene Regeln: starkes Passwort, Tresorablage, dokumentierter Zugriff und regelmäßiger Funktionstest.

Attribut- und Namensstrategie

Der Benutzername, der im Manager ankommt, muss stabil sein. Wenn ein Unternehmen E-Mail-Adressen als Login verwendet, müssen Namensänderungen berücksichtigt werden. Für langlebige Admin-Identitäten ist häufig ein stabiler technischer Username besser als eine wechselnde Mailadresse.

identity_mapping: login_name: preferred_username display_name: name mail: email group_source: keycloak_groups manager_roles: assigned deliberately inside SUSE Multi-Linux Manager

Berechtigungen testen

Ein guter Test endet nicht beim erfolgreichen Login. Prüfe konkret, ob ein Read-only-Benutzer Reports lesen kann, aber keine Patchaktion auslösen darf. Prüfe, ob ein Benutzer ohne passende Gruppe zwar authentifiziert wird, aber keinen Manager-Zugriff bekommt. Prüfe, ob ein deaktivierter Keycloak-Benutzer sofort ausgesperrt ist.

Betriebsdokumentation

In die Betriebsdokumentation gehören Realm, Client-ID, ACS-URL, Zertifikatslaufzeit, MFA-Policy, verantwortliche Teams, Break-Glass-Verfahren und Rollback. Keine privaten Schlüssel, keine Passwörter und keine temporärer Zugriffswerts gehören in diese Dokumentation.

Warum SSO für Multi-Linux wichtig ist

Multi-Linux Manager verwaltet Systeme unterschiedlicher Distributionen. Damit steigt auch die Zahl der Teams, die Reports lesen oder Änderungen auslösen möchten: Linux-Betrieb, Security, Netzwerk, Plattformteam, Einkauf und externe Partner. SSO macht diese Zugriffe kontrollierbar, ohne dass jedes Team lokale Konten im Manager pflegen muss.

Schrittfolge für die Keycloak-Integration

Zuerst wird festgelegt, welche Benutzergruppen den Manager überhaupt öffnen dürfen. Danach wird definiert, welche Gruppen nur Reports lesen, welche Patchaktionen planen dürfen und welche Personen echte Administratorrechte erhalten. Diese Entscheidung gehört vor die technische SAML-Konfiguration.

Danach wird der Keycloak-Client angelegt. Client ID und ACS-URL müssen exakt zum produktiven Manager-FQDN passen. Wenn der Manager später über einen anderen Namen, Load Balancer oder Reverse Proxy erreichbar ist, muss diese Zielarchitektur vorab feststehen.

Im nächsten Schritt werden Mapper gesetzt. Der wichtigste Wert ist der stabile Login-Name. Anzeigename und E-Mail sind hilfreich, aber die technische Identität muss dauerhaft eindeutig bleiben. Das verhindert spätere Probleme bei Namensänderungen oder Rollenprüfungen.

Anschließend wird das öffentliche Zertifikat des Identity Providers im Manager hinterlegt. Danach folgt der erste Login-Test mit einem normalen Benutzer, nicht sofort mit einem Volladministrator. So erkennst du, ob Authentifizierung und Rollenzuordnung getrennt funktionieren.

Erst danach werden MFA-Policies, Adminrollen und Break-Glass-Verfahren final geprüft. Der lokale Notfallzugang bleibt bewusst getrennt vom SSO, damit ein Keycloak- oder Zertifikatsproblem nicht den gesamten Manager-Zugriff blockiert.

Prüfung nach dem Go-live

Nach der Aktivierung testest du mehrere Szenarien: erfolgreicher Login, falsches Passwort, fehlender zweiter Faktor, gesperrter Benutzer, Benutzer ohne Rolle, Read-only-Benutzer und Administrator. Zusätzlich prüfst du, ob Aktionen, Reports und Benutzerzugriffe weiterhin auditierbar bleiben.

Warum SSO mehr als Komfort ist

Multi-Linux Manager steuert Patches, Compliance, Inventar und Systemaktionen. Diese Rechte sind sicherheitsrelevant. SSO mit MFA sorgt dafür, dass Adminzugriffe denselben Unternehmensregeln folgen wie andere kritische Plattformen. Das stärkt Betrieb, Security und Nachvollziehbarkeit gleichzeitig.

Für ForgeOne-Projekte ist SSO deshalb ein Architekturthema: Es verbindet Linux-Betrieb, Identity Management, Security Audit und Kundenbetrieb. Der technische Login ist nur ein Teil davon; entscheidend ist, dass Rollen, Reports und Verantwortlichkeiten sauber zusammenpassen.

SSO ist kein kosmetisches Login-Thema. Für einen produktiven Manager trennt es Admin-Identität, MFA, Rollenmodell und Nachvollziehbarkeit von lokalen Einzelkonten. Die getestete Manager-Serie behandelt SSO deshalb als Betriebsbaustein neben Patch, Reporting und Audit.

https://mlm01.example.test/rhn/manager/systems/list/all

Finale technische Abnahme: SSO und MFA

Dieser Abschnitt dokumentiert den abschließenden Live-Rollout-Stand für Teil 8. Grundlage ist das bestandene Lab mit SUSE Multi-Linux Manager 5.2, mgradm 5.2.16, mgrctl 5.2.16, Keycloak 26.7.3, dem Realm suse-mlm-lab, SAML, uid-Mapping, TOTP und Playwright-End-to-End-Tests.

Architektur des getesteten SSO-Flows

Der getestete Weg ist bewusst einfach: SUSE Multi-Linux Manager leitet den Benutzer per SAML zu Keycloak weiter. Keycloak authentifiziert den Benutzer, erzwingt bei aktivierter Richtlinie TOTP und liefert danach die SAML-Antwort an den Manager zurück. Der uid-Mapper stellt sicher, dass die Benutzerzuordnung auf den erwarteten Login-Namen erfolgt.

Konfiguration, die im Lab geprüft wurde

• Keycloak-Realm suse-mlm-lab mit SAML-Client für SUSE Multi-Linux Manager.
• SP-/Entity- und ACS-Werte passend zum Manager-FQDN, ohne interne Test-URLs im öffentlichen Artikel.
• uid-Mapper aktiv, damit der SAML-NameID-/Attributwert dem Manager-Benutzer entspricht.
• TOTP als MFA-Schritt aktiviert und mit Required Action im Loginpfad geprüft.
• Logout und Rückkehr zum Anmeldezustand geprüft.

Basis-SSO-Test

Der Basis-Test öffnet den Manager, folgt dem SAML-Redirect zu Keycloak, meldet den Benutzer an und landet wieder im Manager. Der Test zählt nur als bestanden, wenn die Manager-Oberfläche nach dem Redirect erreichbar ist.

MFA-Test mit TOTP

Der Enrollment-Schritt wurde ausgeführt, aber der QR-Code und das TOTP-Secret werden nicht veröffentlicht. Öffentlich dokumentiert sind nur sichere Schritte: Passwort, TOTP-Prüfung, Negativtests und erfolgreicher Login.

Negativtests

Die Abnahme hat falsches Passwort, fehlenden TOTP-Code und falschen TOTP-Code geprüft. Erst der korrekte MFA-Schritt führte zurück in den Manager.

Typische Fehlerbilder

• Redirect- oder ACS-Fehler: Entity-ID, ACS-URL und externe Manager-URL konsistent prüfen.
• Benutzer wird nicht zugeordnet: uid-Mapper und Manager-Benutzername vergleichen.
• MFA wird nicht abgefragt: Required Action, Realm-Flow und Benutzerstatus in Keycloak prüfen.
• Login gelingt, Rückkehr scheitert: SAML-Antwort, Zertifikate, Zeitabweichung und Browser-Cookies prüfen.

Technische Ergebniskontrolle