Zammad SSO with SAML and OpenID Connect guide

Why Zammad SSO with SAML and OpenID Connect is more than a settings change

A team that must put Zammad login behind the corporate identity provider needs to plan for more than a configuration screen. Zammad supports third-party login through SAML, OpenID Connect, Microsoft and other providers, but the work spans identity provider setup, redirect and certificate handling, account matching, role mapping and fallback access. Each of these pieces can break sign-in on its own, and they only work together when they are designed as one change, tested with real accounts and documented for the people who will operate Zammad after go-live. The first difficulty is that agents and customers do not necessarily follow the same login path. Agents sign in to the agent interface, where role and group permissions decide what they can see and act on. Customers use the customer interface, where a federated login must still create or match a customer record without giving that customer agent rights. A design that works for staff can quietly fail for customers, so each audience needs its own test cases before cutover. Confirm with your identity team which user populations will authenticate through the provider and which will keep local credentials.

The second difficulty is account collision. Most helpdesks already contain local accounts for staff and customers, often created by email import, earlier migrations or manual setup. When a federated identity arrives with the same email address or an unrelated username, the matching rule decides whether Zammad links it to the existing record, creates a duplicate or refuses the login. Duplicates split ticket history, and wrong links can expose one person's tickets to another. Before enabling the provider, export a list of existing accounts, decide which attribute the identity provider sends as the stable key, and agree who resolves the cases that do not match cleanly.

The third difficulty is that a misconfigured callback can block everyone. SAML and OpenID Connect depend on exact values for the redirect or assertion consumer URL, the audience or client identifier, the signing certificate and the expected claims. A small mismatch in the external URL behind the reverse proxy, an expired certificate or a changed claim name can stop every login at once, including administrators. Plan a fallback before changing production settings: keep at least one local administrator account that is tested and documented, confirm how a locked-out administrator recovers access, and rehearse the change in a non-production instance that uses the same proxy and certificate chain.

Role mapping adds a fourth decision. The identity provider groups or claims must translate into Zammad roles and groups, and that mapping determines who can reach which tickets. Map only the groups the helpdesk needs, avoid granting agent rights through broad directory groups, and record who approves changes to the mapping. Ask your identity provider administrator which group attribute will be sent, whether nested groups are flattened and how removals from a group are handled, because offboarding depends on those answers as much as on the initial setup.

Which Zammad settings and identity parts the SSO work touches

Zammad SSO touches more than one login setting. The Zammad third-party application configuration, the external identity provider, the public HTTPS address served by the reverse proxy, user records and role assignments all have to agree before a single sign-on works for agents and customers.

Zammad third-party application settings

Zammad holds the SAML, OpenID Connect and Microsoft login configuration in its admin third-party application settings. Each provider needs its own entry, with endpoints, client identifiers and secrets copied from the identity side. Confirm the exact menu path and field names against the Zammad admin documentation for the version you run, because these labels change between releases. Record which provider is enabled and which is only configured for testing.

External identity provider registration

The identity provider, such as a corporate directory or hosted identity service, must register Zammad as a relying party or application. That registration defines the redirect or assertion consumer URLs, the signing certificate or client secret, and the claims or attributes sent back. Ask the identity team who owns this registration, how secrets are rotated, and whether test and production tenants are separate.

Public HTTPS callback base URL

Zammad builds its callback addresses from the public URL it presents, so the host name, scheme and path must match exactly what the identity provider expects. The reverse proxy, either Nginx or Apache, must terminate TLS and forward the original host and protocol headers correctly. A mismatch here is the most common reason a login fails after the configuration looks complete, so verify the URL before anything else.

User records and attribute mapping

When a user signs in through an external provider, Zammad matches or creates a local user record using attributes such as email address or a stable identifier. Decide which attribute is the unique key, how names and email addresses are mapped, and whether existing local accounts may be linked. Test with a duplicate email address and with a user who changes their name at the identity provider, since both cases show how the mapping behaves.

Role and group assignments

Access in Zammad depends on the roles and groups a user holds, and the distinction between agent and customer access decides what each person can see and do. The mapping from identity provider groups or claims to Zammad roles and groups must be defined explicitly. Review the least-privilege model with the support lead before go-live, and confirm the mapping behavior for users who lose a group in the identity provider.

Choosing SAML, OpenID Connect or Microsoft login for Zammad

This table compares the main login decisions for Zammad: the protocol, whether local passwords stay enabled, whether customers share the agent identity provider, and whether accounts are created on first login or pre-provisioned. Read each row against your identity provider's documentation, because the operational cost of certificates and client secrets depends on how your provider handles rotation. The main takeaway is that every SSO option still needs a tested break-glass local admin and a dated rotation owner.

Decision	When it fits	Operational cost and trade-off
SAML	Your identity provider is configured for SAML and your team already manages SAML applications for other systems.	The signing certificate expires and must be rotated in both the identity provider and Zammad before the deadline. Confirm the metadata refresh process and the certificate lifetime your provider uses.
OpenID Connect	You want a standard OAuth 2.0-based login flow with a client ID and client secret that your identity provider team can manage.	The client secret has an expiry in many providers and must be rotated in Zammad when it changes. Confirm the secret lifetime and whether your provider supports overlapping secrets during rotation.
Built-in Microsoft login	Your agents and administrators sign in with Microsoft accounts and you want to configure the Microsoft provider in Zammad directly.	Application registration, redirect URIs and credential expiry sit in the Microsoft tenant and must be owned by someone who can change them. Confirm current registration steps and credential lifetimes in Microsoft's documentation before committing.
Keep local password login enabled	You need administrators to sign in if the identity provider is unavailable, or you have service accounts that cannot use SSO.	Local passwords need their own policy, reset process and two-factor settings, so they add a second login surface to review. Keep at least one tested break-glass local admin with a stored, audited credential.
Disable local password login for agents	Your security policy requires all staff to authenticate through the central identity provider with its own multi-factor controls.	A failed identity provider or expired certificate can lock out every agent at once. Test a documented recovery path, including who can re-enable local login and where the break-glass credential is kept.
Same identity provider for customers and agents	Customers and staff belong to one directory, such as a single corporate tenant, and role mapping can separate them cleanly.	Customer accounts inherit the directory's lifecycle and group rules, which can grant unintended agent access if group mapping is loose. Review role mapping before go-live.
Separate login path for customers	Customers are external users who should not be in your staff directory, so they need a different provider, a separate application or local accounts.	Each separate path is another certificate or secret to rotate, another user lifecycle to manage and another login page to support. Confirm with the identity provider vendor whether a second application or tenant is required.
Create accounts on first login	Your user base changes often and you want the first successful SSO sign-in to create the Zammad account automatically.	Accounts exist only after first login, so reporting, assignment and role changes made before that point need a process. Review default roles so new users do not receive more access than intended.
Pre-provision accounts	You need roles, groups and organizations assigned before a user can sign in, or you must control who can open a helpdesk account.	Someone must keep the user list current, which adds recurring administration effort. Pair it with a deprovisioning step so leavers lose access and their tickets stay assigned to an owner.

How to configure Zammad SAML and OpenID Connect login step by step

This sequence takes a Zammad installation to a tested single sign-on login for agents and customers. Run it first in a non-production instance built from the same Zammad version as production, so redirect URIs, attribute mappings and role defaults are proven before any user depends on them. The output is a documented configuration that another administrator can reproduce and audit.

Confirm public URL and TLS
The platform engineer and the network team confirm the external hostname Zammad will use, that the reverse proxy (Nginx or Apache) terminates TLS with a valid certificate chain, and that the forwarded host and protocol headers reach Zammad unchanged. Identity providers reject mismatched redirect URIs, so this must be settled first. Done when a browser outside the internal network opens the address, the certificate matches the hostname, and HTTP requests redirect to HTTPS.
Register Zammad at the identity provider
The identity team creates a SAML service provider or an OpenID Connect client for Zammad. They enter the exact callback URL that Zammad's configuration shows for the chosen provider, built from the URL confirmed in the previous step, and record the entity ID, client ID and issuer. Done when the application appears in the identity provider console and its redirect URI matches the Zammad callback string character for character, including any trailing slash.
Enable and configure the provider
An administrator enables the chosen provider in Zammad's third-party application settings and enters its endpoints. For SAML, this is the single sign-on URL, the signing certificate and the entity ID. For OpenID Connect, it is the issuer, client ID, client secret and scopes. Keep client secrets and private material in your secrets store, not in tickets or chat. Done when the sign-in option appears on the login page and a test login reaches the identity provider and returns without error. Record certificate expiry dates now.
Map identity attributes to user fields
The administrator maps the identity provider's claims or assertions to Zammad user fields, including email address, first name and last name. Decide which attribute uniquely identifies a person and set the login matching rule to match on that value. Matching on a mutable field such as a display name can create duplicate accounts when it changes, so confirm the choice with the identity team. Done when a test identity produces a user record with the expected fields populated and a second sign-in does not create a duplicate.
Set default roles and group access
The administrator decides which role and group access new users receive when Zammad creates their account on first login. Customers should never receive agent rights by default. Agent access is assigned by group, and if the identity provider sends group claims, they are mapped to Zammad roles and groups in this step. Done when a new agent test identity sees only its assigned groups and a new customer test identity cannot open the agent interface.
Test with agent and customer accounts
The team signs in with one agent account and one customer account from a test group, not with administrator accounts. Each tester signs in through the provider, logs out, creates and views a ticket, and confirms the screens match the role assigned. Keep a local administrator login as a fallback and confirm it still works. Record every failure, fix it, and rerun both tests. Widen the rollout only after both accounts pass cleanly.
Record the final configuration
The administrator writes down the provider type, redirect URIs, endpoint values, attribute mappings, login matching rule, default roles, group mappings, certificate expiry dates and an owner for each. Secrets are referenced by their vault location, never copied into the record. Include the test results. Done when a second administrator can locate every setting from the document alone. Retest login after each Zammad upgrade or security release, because identity behavior can change between versions.

What drives SSO effort and cost for Zammad

This table lists the factors that change how much work a Zammad SSO build takes, and what to do about each one. Read each row as a lever: the left column names the driver, the right columns show why it matters and how to keep it contained. The main takeaway is that most effort comes from identity decisions and account cleanup made before any configuration starts.

Driver	Why it changes effort	How to keep it down
Identity providers and protocols	Each SAML or OpenID Connect provider needs its own metadata, certificate or client setup, claim checks and login testing.	Agree one identity provider for agents first, then add others only if a real need is confirmed.
Corporate directory or customer identity service	Agents usually sit in the corporate directory, while customers may need a separate identity service with different attributes and sign-up rules.	Keep customer login on the existing Zammad method unless customer SSO is a stated requirement.
Existing Zammad accounts and duplicates	Duplicate users with the same email address can block or confuse provisioning and cause split ticket histories.	Audit and merge duplicates and remove stale accounts before cutover, not after users start logging in.
Groups and roles needing mapping	Every identity provider group mapped to a Zammad group or role adds rules to build, test and maintain.	Limit role mapping to a short, documented list and handle the rest by manual assignment.
Access to identity provider administrators	Claim changes, new applications and certificate renewals depend on people outside the helpdesk team.	Confirm named administrators, their availability and their change approval path during scoping.
Number of environments	Test, staging and production each need their own redirect URIs, certificates and identity provider registrations.	Use a test tenant or client for early builds and copy only the settings that were proven there.
Compliance evidence requirements	Assessors may expect records of access approval, role design, change tickets and login test results.	Decide the evidence list before build so that tests and change records are captured as work happens.

How SSO setup changes on single node, multi-instance and Kubernetes deployments

A single node installation runs the Zammad application on one host, with its own reverse proxy in front of it. Because there is only one application instance, session data and cache entries do not need to be shared with another node, and Zammad can use the file system cache that the software requirements describe for single installations. The SSO configuration is simpler to reason about because every login callback reaches the same server.

For this model, the identity work usually centers on the following points:

Public hostname: Set the external URL that users see in the browser and register the same value as the redirect or callback URL at the identity provider.
Reverse proxy headers: Confirm that the proxy passes the original host and protocol headers so Zammad builds the callback URL with HTTPS.
Certificate and clock: Check the SAML signing certificate and the server time, since assertion validity windows depend on accurate clocks.
Restart after changes: Confirm with the Docker Compose or package installation documentation whether configuration changes require a service restart.
Fallback admin access: Keep a local administrator account available in case the identity provider is unavailable during testing.

Before go-live, test one login for an agent and one for a customer, and confirm the callback URL matches the registered value exactly, including scheme and port.

What to monitor, rotate and document after Zammad SSO goes live

Monitor failed sign-ins and callback errors from the first day of go-live, because SSO problems usually show up as a rise in login failures before anyone reports an outage. Correlate three sources: the identity provider's sign-in logs, the Zammad application log, and the access and error logs of the Nginx or Apache reverse proxy that receives the SAML assertion or OpenID Connect callback requests. Look for rejected assertions, signature validation failures, redirect URI mismatches and clock skew warnings. Set an alert threshold, name the person who responds, and confirm with your identity provider how long its sign-in logs are retained, since an investigation may need a longer window than the default.

Calendar every certificate and secret expiry before it happens. An expired SAML signing certificate or OpenID Connect client secret stops federated logins for every user at once, and the failure looks like a generic error at the login page. Record the expiry date of each credential in your configuration register, set reminders well ahead of it, and rotate with overlap: publish the new SAML certificate or secret at the identity provider, confirm a test login against Zammad, then retire the old one. Confirm whether your identity provider accepts more than one valid client secret during rotation. Rehearse the steps in a staging instance first, because a mistake there is cheap to correct and a mistake in production blocks everyone.

Review role and group mappings whenever the identity provider changes its groups, claims or attribute names. Zammad grants agent or customer access and group membership based on the attributes the identity provider sends at login, so a renamed group, a restructured department or a changed claim can move agents into the wrong groups or remove permissions without any error. Review the mapping after every reorganization and staff transfer, compare each mapped value against the current directory, and remove mappings that no longer match anything. Keep one test account per role and check what it can see and change after each review. Confirm in your Zammad version's documentation exactly how role and group mapping is configured for each provider.

Keep a local administrator account that does not depend on the identity provider, and test it on a schedule. Store its credentials in a vault with restricted, logged access, and record who can retrieve them and under what conditions. Test that the account still signs in after each upgrade, because an SSO change can leave you locked out during an identity provider outage. Plan releases with the same care. The 7.2 line received security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and the 6.5 line received 6.5.5 on 15 October 2026. If you run either line, add these releases to the upgrade plan, and retest SSO after each one with a login for every provider, a role check and a logout, since any release can change authentication behavior.

Document the SSO configuration, the owners and the identity provider change process before go-live, and keep the record current. For each provider, capture the metadata endpoints, entity IDs or client identifiers, redirect URIs, attribute and group mappings, certificate or secret expiry dates, and the named owner on the Zammad side and on the identity provider side. Describe the change process in writing: who requests a change to claims, groups or application settings, who approves it, where it is tested first, and who confirms the result in production. Review the document after each release and each identity provider change, so the next person to troubleshoot a login failure works from the current configuration rather than from memory.

Securing Zammad SSO: certificates, secrets and fallback access

Single sign-on moves the trust decision for every agent and customer login into your identity provider and into the settings that connect the two. The cards below cover the controls that protect those connections, from transport and key handling to role mapping and recovery access, and what to verify in each.

Terminate all login traffic over TLS

Serve Zammad only over HTTPS at the Nginx or Apache reverse proxy, including the SAML assertion consumer endpoint and the OpenID Connect callback. Confirm that plain HTTP redirects to HTTPS, that the public hostname in Zammad matches the certificate, and that proxy headers passed to Zammad reflect the external scheme so callbacks are not generated as HTTP. Check the certificate chain from outside your network, not only from inside it.

Keep redirect URIs exact

Register the exact callback and assertion consumer URLs in the identity provider, character for character, including scheme, host, port and path. Avoid wildcard or path-prefix redirect patterns and remove stale entries left from test environments. Review the list again after any hostname change, because an overly broad entry lets a token be sent to a location you do not control.

Store keys and client secrets outside shared documents

Keep the SAML service provider private key and the OpenID Connect client secret in a secrets manager or a restricted configuration store with named access. Do not paste them into tickets, wiki pages or chat during setup. Record who can read and rotate them, and plan a rotation date for the client secret and the signing certificate that the identity provider also needs to trust.

Require signed assertions and validate claims

Where the protocol allows, require the identity provider to sign SAML assertions and responses, and confirm that Zammad rejects unsigned or incorrectly signed messages in a test login. For OpenID Connect, check that the issuer, audience and token expiry are validated against the values registered for your application. Test with a deliberately wrong audience or issuer and confirm that login fails.

Restrict which groups map to administrator roles

Map only a small, named identity provider group to Zammad administrator rights, and keep agent and customer mappings separate from it. Review group membership on a set schedule and ask who can add users to the admin group in the identity provider, since that person effectively controls Zammad administration. Confirm that a user removed from the group loses admin rights at next login.

Keep a tested local administrator path

Retain at least one local Zammad administrator account that does not depend on the identity provider, store its credentials in a sealed, access-logged location, and test that it can sign in during a planned window. Without this path, an identity provider outage or a misconfigured SAML certificate can lock every administrator out. Document the steps for using it and who is authorized to do so.

Log authentication events centrally

Enable and retain logs for successful and failed SSO logins, role changes and local administrator sign-ins, then forward them to your central monitoring platform. Confirm which events Zammad records by default and which need additional configuration on the reverse proxy or application server. Test that alerts fire on repeated failures and on any use of the local administrator account.

Align with the hardening baseline

Apply the password, two-factor and TLS settings from your Zammad security hardening baseline to the local accounts that remain, including the fallback administrator. Decide whether SSO users are subject to the identity provider's multi-factor policy only, and document that decision so auditors can trace it. Review the baseline when the identity provider or Zammad release changes authentication behavior.

How to test Zammad SSO and confirm it fails safely

A Zammad SSO change is not ready for users until a written test plan shows that valid logins succeed, invalid logins are refused, and a local administrator can still get in when the identity provider is unavailable. Build the plan around each protocol you enable, whether SAML, OpenID Connect or a Microsoft account, and run it separately for agents and customers. For each protocol and user type, use at least one test account that is expected to succeed and one that is expected to fail. Record the exact identity provider application, the Zammad third-party application settings in use, and the tester's name and date for every run, so the results can be repeated after the next release or configuration change.

Next, test how Zammad creates and matches accounts. Log in with a user who has never signed in before and confirm that a single account is created with the expected email address, name and organization. Then log in with a user who already exists in Zammad and confirm that the login attaches to that account rather than creating a duplicate. Include an edge case where the identity provider sends a different email format for the same person. Check roles and groups against a written matrix that lists each test user, the identity provider group or attribute that should grant access, and the exact Zammad role and groups expected. Verify in the admin interface, not only at login, and confirm that a customer account never receives agent rights.

Test the negative paths deliberately. Attempt login with a user who is not assigned to the Zammad application in the identity provider, with an expired or replaced signing certificate, and with a wrong client secret for OpenID Connect. Each attempt should be refused with a clear error, should not create an account or partial session, and should appear in the logs you have agreed to review. Also check logout and session expiry: confirm the session timeout configured in Zammad ends access after the agreed idle period, and confirm whether signing out of Zammad also ends the identity provider session. Note any difference you find, because it affects shared workstations.

The break-glass check is the most important part of the plan. With the identity provider made unavailable in a test environment, confirm that a named local administrator can still sign in with the credentials and second factor required by your policy. Do not recover by turning off password login, two-factor requirements or TLS. If a test fails, roll back by reverting the SSO settings in Zammad and restoring the previous configuration, and confirm access again. Keep all test evidence, including the matrix, dates, results, log references and approvals, with the change record so an auditor or future engineer can see what was tested and what was accepted.

What teams ask before hiring help with Zammad SSO

How much does Zammad SSO setup cost if the software is free?

Self-hosted Zammad has no license fee, so the cost is the work of configuring login, testing it and handing it over. Who is paid: your staff (identity and helpdesk time), or a partner under a written scope, plus any infrastructure you run. One-time work: scoping, identity provider configuration, role mapping, testing with agents and customers, and documentation. Recurring costs: changes to identity providers, upgrades that touch authentication, and any optional support subscription. Zammad's self-hosted support tiers are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with response times of 6, 4 and 2 hours respectively (Zammad pricing page). Ask any partner for a quote built from a written scope that lists identity providers, login methods and user groups.

Can our in-house team set up Zammad SSO without a partner?

Yes, a team can do this in-house if it has administrator access to the identity provider, a non-production Zammad instance to test against, and working knowledge of SAML or OpenID Connect. Skills to confirm: how your identity provider issues assertions or tokens, how attributes map to Zammad roles, and how to test failure paths such as a disabled account or a user with no group. Where teams often get stuck: coordinating identity administrators, agreeing who approves role mapping, and finding time for test cycles. A partner is most useful when those constraints, rather than the Zammad settings themselves, set the pace. Either way, write down the role mapping and the rollback path before going live.

How long does SSO integration take for self-hosted Zammad?

The duration depends on scope and on how quickly people outside the helpdesk team can respond, so ask for a timeline in the written scope rather than relying on a general estimate. Main schedule drivers: the number of identity providers and login methods, whether SAML, OpenID Connect or a Microsoft or Google account is used, the complexity of role and group mapping, and whether customers log in through the same provider as staff. Waiting time: identity administrators, change approvals, and certificate or secret issuance. Testing: each login path needs agent and customer test cases, plus a test of how Zammad behaves when attributes are missing. Confirm with any provider which of these items are included in the fixed price and which are assumed to be done by your team.

What does the SSO work need from our side before it starts?

Most of the schedule depends on access and decisions from your side, so prepare these before work starts. People: identity provider administrators who can create the application or client, change its attribute settings and export its configuration, and a named approver who signs off on role mapping and go-live. Environment: a test Zammad instance that mirrors production's login path, with test accounts for agents, administrators and customers. Data: an export of existing Zammad users, their roles and organizations, and the group list from your identity provider. Decisions: which domains are allowed to sign in, what happens to accounts that already exist locally, and who owns certificate and secret renewal after go-live.

Does adding SSO change the Zammad license position?

Configuring SSO does not add a license fee for self-hosted Zammad, which is licensed under the GNU Affero General Public License version 3 and has no license fee for self-hosted use. What SSO does change: your operating costs and your support needs, because login failures become helpdesk-wide outages and certificate or secret expiry becomes a planned task. Support subscriptions: Business, Enterprise and Corporation are optional support contracts sold by Zammad, separate from the software license. Hosted plans: these are billed per agent per month (Starter, Professional and Plus), so the cost model is different. Ask Zammad to confirm in writing how any feature you rely on is licensed, and ask your legal or procurement team to review the AGPL obligations that apply to your deployment.

Should we use SAML or OpenID Connect for Zammad login?

Use the protocol your identity provider supports best and that your identity team already operates, because the operating burden usually comes from the identity side. Factors to compare: whether your provider offers both protocols or only one, how attributes and group claims are delivered, how certificates or client secrets are rotated, and how logout and session lifetimes behave. Practical checks: confirm that the provider can send the attributes Zammad needs for role mapping, including a stable user identifier. Support: Zammad documents SAML and OpenID Connect as third-party login options, and Microsoft, Google, GitHub and GitLab are also listed (Zammad admin documentation). Test the chosen method with a real customer flow and an agent flow before committing, and record which attributes each flow depends on.

What usually breaks after Zammad single sign-on goes live?

Most post-launch problems come from configuration drift and expiring credentials rather than from Zammad itself. Common failures: a certificate or client secret reaches its expiry date, a redirect or callback address changes after a domain or proxy change, the identity provider stops sending a group or attribute that role mapping depends on, and clock differences between systems cause token validation failures. Less obvious issues: a user who already exists locally signs in through SSO and gets a second account, or a role change in the identity provider does not reach Zammad until the next login. Checks to set up: calendar reminders for certificate and secret expiry, a login test after every reverse proxy or domain change, an alert on failed logins, and a documented emergency login path for administrators.

What should we receive at handover for Zammad SSO?

Ask for handover material that lets your own team operate and change the login setup without the original builders. Configuration record: the settings for each login method, the identity provider application details (excluding secret values), and the callback addresses. Role mapping: a table that links each identity provider group or attribute to a Zammad role and permission set, with the owner for each mapping. Test evidence: the test cases, who ran them, and the results for agents, administrators and customers. Operations: a runbook covering certificate and secret rotation, rollback to the previous login method, adding a new identity provider, and what to check after an upgrade. Ownership: a named owner on each side for identity changes and for Zammad changes. Confirm in the written scope which of these items are included.

How DeployOpen scopes, builds and hands over Zammad SSO

DeployOpen plans and implements Zammad login through SAML, OpenID Connect or Microsoft accounts inside your own infrastructure. Engagements are fixed-scope, so the identity provider, role mapping and handover are agreed in writing before work starts. Work is split into scoping, build, handover and optional support, so each stage has a clear deliverable your team can check.

How we scope

Inventory the identity providers in use, such as SAML, OpenID Connect, Microsoft, Google, GitHub or GitLab, and which apply.
Define which agents and customers sign in through SSO and which accounts keep local access for emergencies.
Map identity provider groups or claims to Zammad groups and roles, agreed in writing before any build begins.

How we build

Configure the SAML or OpenID Connect provider settings in a staging Zammad instance before touching production.
Test attribute mapping, user provisioning and group-to-role mapping using named test accounts for agents and customers.
Confirm callback addresses, redirect URIs and TLS settings match the public hostname served by your reverse proxy.

How we hand over

Deliver a written configuration record covering provider metadata, claim names, role mappings and fallback admin access.
Provide test evidence for each login path, recording pass or fail results for agents and customers separately.
Supply a runbook for rotating signing certificates or client secrets and for adding new identity groups later.

How we support

Ongoing support and upgrades are available as a retainer after go-live, including Zammad release changes that affect login.
Re-test SSO after each Zammad minor or security release before the change reaches production users.
Support scope and response terms are set in the written agreement, so confirm them against your own requirements.

Zammad SSO with SAML and OpenID Connect