SUSE Multi-Linux Manager 5.2: integrate SSO with Keycloak, SAML and MFA

SUSE Multi-Linux Manager is a central administration system. In production, login belongs into the enterprise identity model: central users, MFA, roles, auditability and controlled offboarding.

The relevant integration path is SAML. Keycloak authenticates users as identity provider. SUSE Multi-Linux Manager remains the service provider and still controls local roles and permissions.

https://mlm01.lab.example

Complete series path

This series guides you step by step through production deployment: 1. Install SLES 16 for production · 2. Install SUSE Multi-Linux Manager 5.2 · 3. Onboard first Linux clients · 4. Patch and lifecycle management · 5. Manage mixed Linux · 6. OpenSCAP, compliance and audit · 7. Build proxies for sites · 8. Integrate SSO with Keycloak · 9. Use Ansible next to Salt · 10. Reporting, inventory and audit · 11. Operate and harden in production

Target model

The admin opens https://mlm01.lab.example. The Manager redirects to Keycloak. Keycloak validates user, password, MFA and policies. The user returns to the Manager and receives only explicitly assigned roles.

SSO does not mean administrator rights. Authentication identifies the person. Authorization decides what that person may do.

Prepare Keycloak

Create a dedicated realm or a clearly separated client in an existing realm. Redirect URIs must be strict, MFA should be enforced through realm, group or conditional policies, and private test accounts must not become the production admin path.

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

Create the SAML client

The SAML client uses the Manager metadata endpoint as Client ID. The Assertion Consumer Service URL points to the Manager ACS endpoint. Use the real Manager FQDN, not localhost, not an SSH tunnel and not a temporary port.

Client ID=https://mlm01.lab.example/rhn/manager/sso/metadata
Valid redirect URI=https://mlm01.lab.example/rhn/manager/sso/acs
Name ID format=persistent or username-based
Force POST binding=enable according to IdP policy

Mappers, certificate and metadata

Stable mappers for username, display name and email are enough for the first path. The Manager must trust the public SAML certificate of the identity provider. Private keys never belong in screenshots, tickets, Git or public articles.

curl -k https://mlm01.lab.example/rhn/manager/sso/metadata
# Export Keycloak metadata through secured admin access
# Add the public IdP certificate to the Manager by supported procedure

Configure the Manager

Manager configuration connects Keycloak metadata with the local role model. Treat this as a production change: maintenance window, rollback, break-glass admin, browser test and audit check.

mgrctl status
mgrctl exec -- bash -lc 'spacewalk-service status'
# Apply SSO configuration
# Reload or restart Manager services in a controlled way
mgrctl status

Test MFA and roles

Test an administrator, a read-only user, a user without roles and a disabled user. MFA must be enforced in Keycloak. The Manager must not derive unintended privileges from successful authentication.

acceptance:
  login_with_keycloak: PASS
  mfa_required: PASS
  disabled_user_blocked: PASS
  user_without_role_blocked: PASS
  read_only_user_cannot_patch: PASS
  admin_user_can_open_reports: PASS
  local_break_glass_admin_available: PASS

Reports and audit

After SSO integration, reports must remain attributable. Check user lists, system access, scheduled actions and audit data. Security teams need central login and clear user attribution for Manager actions.

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

Support model and limits

SUSE documents Keycloak as an example for SAML SSO. In production, clarify which parts are owned by SUSE support, the identity team and operations before go-live.

Identity lifecycle and offboarding

SSO is most valuable when users should not be maintained manually in several administration systems. New administrators are enabled through the identity process, roles become traceable and offboarding does not depend on remembering every local account.

The Manager remains a security-critical system. Keycloak groups must not automatically grant superuser permissions. Authentication, group mapping and Manager roles are deliberately separated.

MFA for privileged accounts

MFA should be mandatory for administrators. A good policy covers all Manager administrators and often read-only access to security-relevant reports as well. Emergency accounts need separate rules: strong password, vault storage, documented access and regular tests.

Attribute and naming strategy

The username arriving at the Manager must be stable. If an organization uses email addresses as login, name changes must be handled. For long-lived admin identities, a stable technical username is often better than a changing mail address.

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

Test permissions

A good test does not end with successful login. Verify that a read-only user can read reports but cannot trigger patch actions. Verify that a user without the right group authenticates but receives no Manager access. Verify that a disabled Keycloak user is blocked immediately.

Operations documentation

Operations documentation contains realm, client ID, ACS URL, certificate lifetime, MFA policy, responsible teams, break-glass procedure and rollback. Private keys, passwords and tokens never belong into that documentation.

Why SSO matters for Multi-Linux

Multi-Linux Manager handles systems from different distributions. More teams therefore need access to reports or actions: Linux operations, security, networking, platform teams, purchasing and partners. SSO makes access controllable without maintaining local accounts for every team.

Step sequence for Keycloak integration

First decide which user groups may open the Manager at all. Then define which groups can only read reports, which may schedule patch actions and which people receive real administrator rights. This decision comes before technical SAML configuration.

Next create the Keycloak client. Client ID and ACS URL must exactly match the production Manager FQDN. If the Manager will later be reached through another name, load balancer or reverse proxy, that target architecture must be clear first.

Then configure mappers. The most important value is the stable login name. Display name and email are useful, but the technical identity must stay unique over time. This prevents problems during name changes or role reviews.

After that, add the public certificate of the identity provider to the Manager. Run the first login test with a normal user, not directly with a full administrator. That shows whether authentication and role assignment are separated correctly.

Only then finalize MFA policies, admin roles and break-glass procedures. Local emergency access remains separate from SSO so Keycloak or certificate issues do not lock everyone out of the Manager.

Checks after go-live

After activation, test several scenarios: successful login, wrong password, missing second factor, disabled user, user without role, read-only user and administrator. Also verify that actions, reports and user access remain auditable.

Why SSO is more than convenience

Multi-Linux Manager controls patches, compliance, inventory and system actions. These rights are security-relevant. SSO with MFA makes admin access follow the same enterprise rules as other critical platforms and improves operations, security and traceability.

For ForgeOne projects, SSO is an architecture topic. It connects Linux operations, identity management, security audit and customer operations. The technical login is only one part; roles, reports and responsibilities must match cleanly.