Single Sign On via SAML in Google Workspace für Business und Education

Voraussetzung: SAML Single Sign-On benötigt ein passendes edoobox Abonnement. Planen Sie die Einrichtung mit Ihrer Google-Workspace-Administration und halten Sie während des Tests einen unabhängigen Super-Admin-Zugang bereit.

Google Workspace authentifiziert als Identity Provider die Personen, die sich in edoobox anmelden. Je nach Sichtbarkeit im Login verwenden Sie denselben Provider für Admins, Teilnehmende oder beide Gruppen. Google bestätigt die Identität; edoobox entscheidet danach anhand von Login-Scope, Mapping, Rechten und Tags, welcher Zugang entsteht.

Eine identische E-Mail-Adresse allein erteilt keinem neuen Admin automatisch Rechte. Bestehende Admins werden nur bei aktivierter Verknüpfung übernommen; neue Admins benötigen entweder ein gültiges ACL-Mapping oder müssen bereits berechtigt sein.

Voraussetzungen und Testplan

Google-Workspace-Super-Admin für eine benutzerdefinierte SAML-App.
edoobox Super-Admin mit Zugriff auf die SAML-Providerverwaltung.
Mindestens ein Testkonto mit bekannter primärer E-Mail-Adresse.
Entscheidung, ob der Provider für Admin, User oder beide sichtbar ist.
Ein dokumentierter Notfallzugang, der nicht vom neuen Provider abhängt.

1. Benutzerdefinierte SAML-App in Google erstellen

Öffnen Sie in der Google Admin-Konsole Apps > Web- und mobile Apps, fügen Sie eine benutzerdefinierte SAML-App hinzu und vergeben Sie einen eindeutigen Namen wie «edoobox SSO». Google verlangt dafür einen Super-Admin.

Google-Workspace-Assistent für eine benutzerdefinierte SAML-App mit Marker A am Assistenten und B am App-Namen. — In Google Workspace erhält die benutzerdefinierte SAML-App einen internen Namen. Dieser Name ist von der Beschriftung des edoobox Loginbuttons getrennt.
A
Assistent zum Hinzufügen einer benutzerdefinierten SAML-App.
B
Interner App-Name in Google Workspace, beispielsweise «edoobox SAML».

Google-Workspace-Dialog mit Marker C an Metadaten herunterladen; konkrete IdP-Werte sind in der Originalaufnahme unkenntlich gemacht. — Laden Sie die IdP-Metadaten der Google-App als XML herunter. Diese Datei wird anschliessend beim Anlegen des edoobox SAML-Providers verwendet.
C
«Metadaten herunterladen» speichert die IdP-Metadaten für die Einrichtung in edoobox.

Laden Sie die IdP-Metadaten als XML herunter. Für den Google-Ablauf verwenden Sie die heruntergeladene XML-Datei als Metadatenquelle in edoobox.

2. SAML-Provider in edoobox anlegen

Erstellen Sie unter den globalen SAML-Einstellungen einen Provider.
Wählen Sie User & Admin, Nur Admin oder Nur User.
Wählen Sie das NameID-Format. Für primäre Google-E-Mail-Adressen ist Email Address der naheliegende Start.
Wählen Sie den XML-Upload und laden Sie die im vorherigen Schritt aus Google heruntergeladene Metadatendatei hoch.
Bei Admin-Scope wählen Sie ein bewusst eingeschränktes Ausweichrecht.

Schliessen Sie das Anlegen mit der Speicheraktion ab und warten Sie auf die erfolgreiche Anlage. Öffnen Sie anschliessend den gespeicherten Provider; erst dort stehen seine Informationen und die edoobox Metadaten zum Herunterladen bereit.

3. edoobox Metadaten in Google übernehmen

Laden Sie nach dem Erstellen des Providers die federationmetadata.xml aus edoobox. Verwenden Sie daraus die Entity ID und die Assertion Consumer Service URL für die Google-Felder Entity ID und ACS URL. Kopieren Sie keine Beispieladresse aus einem anderen Konto oder einer anderen Umgebung.

Google-Workspace-Dienstanbieter-Einstellungen mit Markern 1 bis 4 für ACS-URL, Entitäts-ID, optionale Start-URL und Name-ID-Format EMAIL. — Die Dienstanbieter-Einstellungen verwenden die Werte Ihres edoobox Providers. Übernehmen Sie ACS-URL und Entitäts-ID aus dessen Metadaten; die Aufnahme enthält bewusst keine kopierbaren Kontowerte.
1
ACS-URL aus dem Location-Attribut des edoobox AssertionConsumerService übernehmen.
2
Entitäts-ID aus entityID in den edoobox Metadaten übernehmen.
3
Optionale Start-URL; sie gehört zur gewünschten Umgebung und wird nicht aus den Metadaten abgeleitet.
4
Name-ID-Format EMAIL für die Anmeldung über die primäre Google-E-Mail-Adresse abstimmen.

Testen Sie den von edoobox gestarteten Login. Die in edoobox angezeigte SSO-URL dient dem Adminlogin; für Teilnehmer verwenden Sie den Login im Buchungsprozess. Die Hostadresse kann je nach Umgebung abweichen; die erzeugten Werte sind deshalb verbindlicher als ein fest eingetragener APP1- oder APP2-Link.

4. Attribute und Field Mapping abstimmen

Ordnen Sie in Google die primäre E-Mail-Adresse, den Vornamen und den Nachnamen App-Attributen zu. Die aktuellen edoobox Standardnamen für Google beziehungsweise generisches SAML sind:

Google-Daten	App-Attribut	edoobox Feld
Primäre E-Mail-Adresse	`email`	`email`
Vorname	`givenName`	`first_name`
Nachname	`sn`	`last_name`

Attributnamen sind exakt. Wenn Sie in Google andere App-Attributnamen vergeben, passen Sie das Field Mapping in edoobox entsprechend an. Mindestens die eindeutige Identität und die für den gewählten Scope erforderlichen Felder müssen ankommen.

5. Aktuelle edoobox Optionen bewusst wählen

Option	Wirkung
Sichtbarkeit im Login	Provider erscheint bei User, Admin oder beiden Loginarten.
Ausweichrecht	Konfigurierte Ausweichberechtigung bei Admin-Scope. Sie erlaubt keiner unbekannten Person allein einen neuen Adminzugang.
Rechteverwaltung via edoobox	Erlaubt das Mapping von `edoobox.acl` auf edoobox Rechte.
Admins mit SAML verknüpfen	Verknüpft einen bestehenden Admin mit derselben E-Mail-Adresse beim ersten SAML-Login.
Auth Request Signed	Signiert den AuthnRequest mit dem für den Provider hinterlegten edoobox Zertifikat. Nur aktivieren, wenn Google dies passend erwartet.
Teilnehmer-Tags	Weist angemeldeten Teilnehmenden aus diesem Provider Tags indirekt zu; Admins sind nicht betroffen.
Tag-Filterung der Angebote	Zeigt nur Angebote mit ausgewählten Provider-Tags oder zeigt sie im additiven Modus zusätzlich an.

Teilnehmer und Angebote mit Provider-Tags steuern

Provider-Tags wirken nur für über diesen SAML-Provider angemeldete Teilnehmende. Ein Angebotsfilter darf nur Tags verwenden, die zuvor als Provider-Tags ausgewählt wurden.

Erzwungener Filter: In der normalen Übersicht bleiben nur Angebote sichtbar, die alle ausgewählten Filtertags tragen.
Additiv: Angebote mit den ausgewählten Tags werden zusätzlich zugänglich. Das ist nützlich, um interne, getaggte Angebote für diese SAML-Gruppe einzublenden.

Testen Sie immer ein passendes und ein nicht passendes Angebot. Ein Tagname und, falls verwendet, sein Wert beziehungsweise Status müssen zusammenpassen.

6. App zuweisen, Provider aktivieren und testen

Aktivieren Sie die Google-App zuerst nur für eine Testgruppe oder Organisationseinheit.
Kontrollieren Sie den Providerstatus in edoobox. Nach erfolgreicher Anlage ist der Provider aktiv; bei bestehenden Providern lässt sich der Status unter Konfiguration ändern.
Öffnen Sie die erzeugte SSO-URL in einem privaten Browserfenster.
Prüfen Sie Identität, Name, E-Mail, Adminrecht beziehungsweise Teilnehmerzugang und Logout.
Bei Teilnehmer-Scope prüfen Sie sichtbare Angebote, Provider-Tags, Promotion-Referenzen und den Rückweg in den Buchungsprozess.

Fehlersuche

App nicht sichtbar: Google-Zuweisung für Person oder Organisationseinheit prüfen.
Antwort abgelehnt: Entity ID, ACS URL, NameID-Format, Zertifikat und Uhrzeit vergleichen.
Felder fehlen: Google App-Attributnamen und edoobox Field Mapping exakt vergleichen.
Admin ohne Zugriff: Admin-Verknüpfung, Ausweichrecht oder edoobox.acl prüfen.
Falsche Angebote: Provider-Tags, Angebots-Tags, Filtermodus und Login-Scope kontrollieren.

Anwendungsbeispiele

Anwendungsbeispiel: Schulverwaltung meldet sich über Google an

Eine Schule setzt den Scope auf Nur Admin, aktiviert die App für die Organisationseinheit «Kursverwaltung» und verknüpft bestehende Admins anhand identischer E-Mail-Adressen. Das Ausweichrecht bleibt bewusst eingeschränkt; ein unabhängiger Super-Admin testet den Prozess.

Anwendungsbeispiel: Interne Weiterbildungen nur für Mitarbeitende

Der Provider hat den Teilnehmer-Tag Mitarbeitende. Interne Angebote tragen denselben normalen Angebotstag. Mit additiver Angebotsfilterung sehen angemeldete Mitarbeitende diese Angebote zusätzlich zur öffentlichen Übersicht; externe Personen sehen sie nicht.

Anwendungsbeispiel: Getrennte Provider für Admins und Lernende

Eine Hochschule erstellt einen Provider mit Scope Nur Admin für die Kursorganisation und einen zweiten mit Nur User für Studierende. So bleiben Adminrechte, Teilnehmer-Tags und Angebotsfilter getrennt testbar.

Bedienhinweise und weiterführende Einrichtung

Der Providerdialog ist in Konfiguration, Datenfeld Mapping und Informationen aufgeteilt. Die ursprüngliche Metadatenquelle wird unter Informationen schreibgeschützt angezeigt. Bei Quellenwechsel oder einer notwendigen Erneuerung einer hochgeladenen XML planen Sie die Umstellung mit Ihrer zuständigen SSO-Administration.

Konfigurieren Sie den Datenabgleich mit SAML-Datenfelder und Adminrechte. Für Nur User, zusätzliche Teilnehmerfelder, indirekte Provider-Tags, interne Angebote und den Login in eingebundenen Buchungsseiten lesen Sie Teilnehmer-SSO, Tags und Angebotszugriff.

Die externe Einrichtung folgt der offiziellen Google-Anleitung für benutzerdefinierte SAML-Apps (geprüft am 16. Oktober 2026). Google unterscheidet das Signieren der Antwort vom Signieren eines ausgehenden AuthnRequests. Setzen Sie Auth Request Signed in edoobox daher nicht mit Googles Option Signed response gleich.