Veröffentlicht am 4. August 2026

AGOV für Cloud-, SaaS- und Hyperscaler-Architekturen

Zusammenspiel mit Microsoft Entra ID, Microsoft 365, AWS, Google Cloud und weiteren Plattformen

1. Ausgangslage

AGOV ist der Authentifizierungsdienst der Schweizer Behörden. Zielapplikationen können über OpenID Connect, kurz OIDC, oder SAML 2.0 direkt oder über ein bestehendes Identitäts- und Zugriffsmanagement an AGOV angebunden werden.

AGOV ist nicht an ein bestimmtes Betriebsmodell gebunden. Eine Zielapplikation kann insbesondere:

in einem Rechenzentrum der zuständigen Behörde
in einem Rechenzentrum der zuständigen Behörde
bei einem öffentlichen oder privaten Leistungserbringer
in einer Private Cloud
als Software as a Service
auf einer Hyperscaler-Plattform
oder in einer hybriden beziehungsweise organisationsübergreifenden Architektur

betrieben werden.

Voraussetzung ist, dass die Zielapplikation selbst oder eine vorgeschaltete IAM-Komponente ein mit AGOV kompatibles OIDC- oder SAML-Profil unterstützt.

AGOV schliesst die Anbindung von SaaS-, Cloud- oder Hyperscaler-Lösungen nicht aus. Die technische Anschlussfähigkeit ist jedoch von der rechtlichen, sicherheitstechnischen und organisatorischen Zulässigkeit des jeweiligen Betriebsmodells zu unterscheiden.

2. Identität, organisatorischer Kontext und Berechtigung

AGOV authentisiert natürliche Personen. Es bestätigt gegenüber einer angeschlossenen Zielapplikation, welche Person sich angemeldet hat und mit welcher Authentifizierungs- beziehungsweise Identitätsprüfungsqualität die Anmeldung erfolgt ist.

Ein AGOV-Konto repräsentiert immer genau eine natürliche Person. Es bildet insbesondere keine:

Zugehörigkeit zu einer Behörde oder Organisation
dienstliche Funktion
Vertretungsbefugnis
Fachrolle
Cloudlizenz
Applikationsberechtigung
oder Ressourcenzuweisung

ab.

Diese Informationen und Entscheide verbleiben bei der zuständigen Behörde, ihrem Organisations-IAM, der Cloudplattform oder der jeweiligen Fachanwendung.

Das grundlegende Verantwortungsmodell lautet:

AGOV authentisiert die natürliche Person.

Das Organisations-IAM ordnet die Person einer Organisation, Funktion oder Rolle zu.

Die Cloudplattform verwaltet ihre plattformspezifischen Konten, Lizenzen, Gruppen, Rollen und Tokens.

Die Fachanwendung entscheidet über die konkrete fachliche Berechtigung.

3. Integrationsmodelle

3.1 Direkte Anbindung

Eine Zielapplikation kann unmittelbar als OIDC Relying Party oder SAML Service Provider an AGOV angeschlossen werden.

Zielapplikation ↔ AGOV

Dieses Modell eignet sich insbesondere für eigenentwickelte Behördenanwendungen, E-Government-Portale und Standardlösungen mit einer frei konfigurierbaren OIDC- oder SAML-Anbindung.

3.2 Anbindung über ein bestehendes IAM oder einen Identity-Broker

Mehrere Zielapplikationen können über eine gemeinsame IAM-Komponente an AGOV angebunden werden.

Zielapplikationen ↔ IAM oder Identity-Broker ↔ AGOV

Die Vermittlungsschicht kann insbesondere:

unterschiedliche Protokollprofile aufeinander abstimmen
Claims und Attribute transformieren
interne Personenkennungen ergänzen
Organisationszugehörigkeiten aus separaten Verzeichnissen beziehen
Gruppen und Rollen zuordnen
mehrere Anwendungen in einer SSO-Domäne zusammenfassen
produktspezifische Besonderheiten gegenüber AGOV kapseln

Die Anbindung über ein bestehendes IAM-System ist Bestandteil des vorgesehenen AGOV-Integrationsmodells.

3.3 Anbindung über das IAM einer Cloudplattform

Das IAM einer Cloudplattform kann gegenüber AGOV als Relying Party oder als vermittelnde Identitätsschicht auftreten.

Cloudanwendung ↔ Cloud-IAM ↔ AGOV

In diesem Modell übernimmt AGOV die Authentisierung der natürlichen Person. Die Cloudplattform stellt anschliessend ihre eigenen Tokens aus und verwaltet die plattformspezifischen Konten, Rollen und Zugriffsentscheide.

4. Protokollunterstützung und konkrete Interoperabilität

Die Unterstützung von OIDC oder SAML bildet die technische Grundlage für eine Anbindung. Für die konkrete Integration ist zusätzlich zu prüfen, ob die von AGOV und der jeweiligen Zielplattform verwendeten Profile und Abläufe miteinander übereinstimmen.

Zu berücksichtigen sind insbesondere:

OIDC- oder SAML-Profile
Issuer, Audience und Entity IDs
Redirect- und Callback-Verfahren
stabile Personenidentifikatoren
Claims und Attribute
Signatur- und Verschlüsselungsverfahren
Schlüssel- und Zertifikatswechsel
Sitzungsdauer und erneute Authentisierung
Authentifizierungsqualitäten und Step-up
Single Logout
Anforderungen von Browsern, mobilen Anwendungen, Desktop-Clients oder Kommandozeilenwerkzeugen

Abweichungen in einzelnen Punkten schliessen eine Integration nicht grundsätzlich aus. Sie können je nach Ausgangslage durch Konfiguration, eine Ergänzung des Integrationsprofils, eine Weiterentwicklung von AGOV oder den Einsatz eines kontrollierten Identity-Brokers gelöst werden.

5. Microsoft Entra ID und Microsoft 365

Microsoft 365 verwendet Microsoft Entra ID als Verzeichnis-, Token-, Lizenz- und Zugriffsplattform.

Eine Microsoft-365-Domäne kann grundsätzlich mit einem externen SAML-Identity-Provider föderiert werden. Microsoft verwendet dafür ein spezifisches Integrationsprofil mit definierten Anforderungen an Endpunkte, Identifikatoren, Claims, Signaturen und Clientverfahren.

Ein mögliches Integrationsmodell lautet:

Microsoft 365 ↔ Microsoft Entra ID ↔ AGOV oder Identity-Broker

AGOV übernimmt dabei die Authentisierung der natürlichen Person. Microsoft Entra ID bleibt insbesondere zuständig für:

Microsoft-365-Benutzerkonten
User Principal Names
Lizenzen
Gruppen
Rollen
Anwendungszuweisungen
Microsoft-Tokens
Microsoft Graph
Microsoft-spezifische Zugriffsrichtlinien

Eine direkte Föderation zwischen AGOV und Microsoft Entra ID setzt voraus, dass die verwendeten Profile und Abläufe kompatibel sind. Soweit eine produktspezifische Anforderung nicht unmittelbar erfüllt wird, kann eine geeignete Vermittlungsschicht eingesetzt oder eine entsprechende Weiterentwicklungsanforderung an AGOV gestellt werden.

Von der Föderation einer Microsoft-365-Domäne zu unterscheiden sind Szenarien mit Microsoft Entra External ID. Diese betreffen insbesondere den Zugriff externer Personen auf ausgewählte Entra-geschützte Ressourcen und sind technisch sowie organisatorisch separat zu beurteilen.

6. Amazon Web Services

Bei AWS sind unterschiedliche Anwendungsszenarien zu unterscheiden.

6.1 Zugang zur AWS-Managementebene

Für den personengebundenen Zugang zu AWS-Konten und zur AWS Management Console kann AWS IAM Identity Center eingesetzt werden. IAM Identity Center kann die Authentisierung an einen externen SAML-Identity-Provider delegieren.

AWS Management Console ↔ AWS IAM Identity Center ↔ AGOV oder Identity-Broker

AGOV authentisiert die natürliche Person. AWS verwaltet insbesondere:

AWS-Konten
Permission Sets
IAM-Rollen
Gruppen
Ressourcenrichtlinien
AWS-Sitzungen und AWS-Tokens

Die SAML-Föderation ersetzt nicht die Bereitstellung der in AWS benötigten Benutzer-, Gruppen- und Rollenzuordnungen. Diese erfolgen separat, beispielsweise durch SCIM, manuelle Administration oder ein vorgelagertes Organisations-IAM.

6.2 Auf AWS betriebene Fachanwendungen

Eine auf AWS betriebene Fachanwendung kann direkt über OIDC oder SAML an AGOV angeschlossen werden.

Fachanwendung auf AWS ↔ AGOV

Alternativ kann Amazon Cognito als Vermittlungsschicht eingesetzt werden.

Fachanwendung auf AWS ↔ Amazon Cognito ↔ AGOV

In diesem Modell übernimmt Cognito die produktspezifische Token-Ausstellung und Attributzuordnung gegenüber der Anwendung.

6.3 Technische Workloads

Technische Prozesse, Server, Container, Funktionen und Servicekonten werden nicht über AGOV authentisiert. Für solche Workloads sind die jeweiligen Verfahren für technische Identitäten, kurzlebige Berechtigungsnachweise und Workload Federation einzusetzen.

7. Google cloud

Google Cloud ermöglicht mit Workforce Identity Federation die Einbindung externer OIDC- oder SAML-Identity-Provider für natürliche Personen.

Google Cloud ↔ Workforce Identity Federation ↔ AGOV

AGOV authentisiert die natürliche Person. Google Cloud ordnet die übermittelte Identität und die zulässigen Attribute seinen eigenen IAM-Rollen und Ressourcenberechtigungen zu.

Google Cloud bleibt insbesondere zuständig für:

Workforce Pools
Attribut-Mappings
Principal Sets
Google-Cloud-IAM-Rollen
Ressourcenrichtlinien
Kurzlebige Google-Tokens

Workforce Identity Federation für natürliche Personen ist von Workload Identity Federation für technische Prozesse zu unterscheiden.

Google Cloud Workforce Identity Federation ist zudem nicht mit Google Workspace gleichzusetzen. Eine Anbindung von Google Workspace ist als separates Produktszenario zu beurteilen.

8. Weitere Cloud- und SaaS-Plattformen

8.1 Oracle Cloud Infrastructure

OCI IAM Identity Domains können die Authentisierung an einen externen SAML-Identity-Provider delegieren.

Oracle Cloud ↔ OCI IAM Identity Domain ↔ AGOV oder Identity-Broker

Gruppen, Rollen, Policies und Cloudberechtigungen verbleiben in OCI beziehungsweise im zuständigen Organisations-IAM.

8.2 SAP Business Technology Platform

SAP BTP kann je nach Dienst und Architektur direkt über SAML oder vermittelt über SAP Cloud Identity Services an AGOV angebunden werden.

Direktes Modell:

SAP-BTP-Anwendung ↔ AGOV

Vermitteltes Modell:

SAP-BTP-Anwendung ↔ SAP Cloud Identity Services ↔ AGOV

SAP-spezifische Role Collections, Geschäftsrollen und Berechtigungen verbleiben ausserhalb von AGOV.

8.3 Salesforce

Salesforce kann als SAML Service Provider gegenüber AGOV oder einem Identity-Broker betrieben werden.

Salesforce ↔ AGOV oder Identity-Broker

Benutzerobjekte, Profile, Permission Sets, Lizenzen und fachliche Berechtigungen verbleiben in Salesforce beziehungsweise im zuständigen Organisations-IAM.

8.4 ServiceNow und weitere SaaS-Lösungen

ServiceNow und zahlreiche weitere SaaS-Produkte unterstützen die Anbindung externer Identity-Provider über OIDC oder SAML.

Unterstützt eine SaaS-Lösung einen kundenseitig bestimmbaren OIDC- oder SAML-Identity-Provider, kann grundsätzlich eine direkte oder vermittelte Anbindung an AGOV geprüft und umgesetzt werden.

9. Übersicht

Plattform oder Szenario
Möglicher AGOV-Anbindungsweg
Verbleibende Verantwortung

Eigenentwickelte Fachanwendung
Direkt über OIDC oder SAML
Fachrollen, Berechtigungen, Sessions und Geschäftsdaten

Microsoft 365
Über Microsoft Entra ID, direkt bei Profilkompatibilität oder über einen Broker
Konten, UPN, Lizenzen, Gruppen, Rollen und Microsoft-Tokens

AWS Management Console
SAML über AWS IAM Identity Center
AWS-Konten, Permission Sets, IAM-Rollen und Provisionierung

Fachanwendung auf AWS
Direkt über OIDC oder SAML oder vermittelt über Amazon Cognito
Anwendungsprofile, AWS-Ressourcen und fachliche Rechte

Google Cloud
OIDC oder SAML über Workforce Identity Federation
Attribut-Mapping, IAM-Rollen und Ressourcenrichtlinien

Oracle Cloud
SAML über OCI IAM Identity Domains
OCI-Gruppen, Rollen und Policies

SAP BTP
Direkt über SAML oder vermittelt über SAP Cloud Identity Services
Role Collections und SAP-Geschäftsrollen

Salesforce
SAML direkt oder über einen Broker
Profile, Permission Sets, Lizenzen und fachliche Berechtigungen

Weitere SaaS-Lösungen
OIDC oder SAML nach Prüfung des konkreten Integrationsprofils
Produktspezifische Konten, Rollen, Daten und Prozesse

10. Anforderungen an AGOV

AGOV wird auf die Bedürfnisse der Schweizer Behörden ausgerichtet und entsprechend weiterentwickelt.

Benötigt eine Relying Party für die Anbindung einer Cloud- oder SaaS-Plattform beispielsweise:

ein zusätzliches Claim
ein bestimmtes Attribut
eine ergänzende Signaturvariante
ein spezifisches Protokollverhalten
eine Erweiterung eines bestehenden Integrationsprofils
oder eine weitere standardbasierte Funktion,

kann diese Anforderung über die vorgesehenen Anschluss-, Austausch- und Governancekanäle an die Schweizerische Bundeskanzlei eingebracht werden.

Produktspezifische Interoperabilitätsanforderungen sind Teil der regulären Weiterentwicklung von AGOV. Sie stellen keinen grundsätzlichen Ausschlussgrund für die betreffende Plattform dar.

Die Bundeskanzlei beurteilt solche Anforderungen insbesondere unter Berücksichtigung von:

Sicherheit
Datenschutz
Standardkonformität
Nutzen für mehrere Behörden und Relying Parties
Auswirkungen auf bestehende Integrationen
Betriebsfähigkeit
Kosten
Vermeidung unnötiger Herstellerabhängigkeiten

Eine Weiterentwicklung von AGOV ist insbesondere dann zweckmässig, wenn eine Anforderung auf offenen Standards beruht, die Interoperabilität verbessert und nicht dazu führt, dass fachliche Rollen, Organisationszugehörigkeiten oder produktspezifische Berechtigungen in AGOV verlagert werden.

Ist eine Anforderung ausschliesslich für ein einzelnes Produkt relevant oder stark proprietär ausgestaltet, kann ein kontrollierter Identity-Broker die geeignetere Lösung darstellen.

11. Hyperscaler, digitale Souveränität und E-Government

11.1 Zuständigkeitsbereich von AGOV

AGOV regelt die Authentisierung und die dafür erforderlichen IAM-spezifischen Rahmenbedingungen.

Die Verwendung von AGOV entscheidet nicht darüber, ob eine Fachanwendung lokal, in einer Private Cloud, als SaaS-Lösung oder auf einer Hyperscaler-Plattform betrieben werden darf.

AGOV stellt für diese Beurteilung keine zusätzlichen materiellen Cloud- oder Souveränitätsvorgaben auf, die über den für AGOV geltenden IAM-Rahmen, insbesondere die Verordnung über Identitätsverwaltungs-Systeme und Verzeichnisdienste des Bundes, IAMV, hinausgehen.

Ein Anschluss an AGOV bedeutet deshalb weder eine Freigabe noch einen Ausschluss einer bestimmten Cloudplattform.

11.2 Verantwortung der Relying Party

Die für den Fachprozess verantwortliche Behörde beziehungsweise Relying Party beurteilt die Zulässigkeit des gewählten Betriebsmodells.

Sie bleibt insbesondere verantwortlich für:

die gesetzliche Grundlage des Fachprozesses
Zweck und Verhältnismässigkeit der Datenbearbeitung
die Auswahl der Cloud-, SaaS- oder Plattformlösung
die Klassifizierung und den Schutzbedarf der Daten
die Vergabe von Rollen und Zugriffsrechten
die Informationssicherheit
den Datenschutz
die Auftragsbearbeitung
allfällige Unterauftragsbearbeiter
Datenbekanntgaben ins Ausland
Aufbewahrung und Löschung
Protokollierung und Nachvollziehbarkeit
Business Continuity
Exit- und Migrationsfähigkeit
die Information der betroffenen Personen

Diese Verantwortung wird durch die Verwendung von AGOV nicht auf die Bundeskanzlei oder den Authentifizierungsdienst übertragen.

11.3 Bürgerdaten

E-Government-Anwendungen bearbeiten häufig Personendaten von Bürgerinnen und Bürgern. Je nach Fachprozess können darunter besonders schützenswerte Personendaten, Steuerdaten, Gesundheitsdaten, Sozialdaten, Verfahrensdaten oder andere Informationen mit erhöhtem Schutzbedarf fallen.

Vor einer Verarbeitung auf einer SaaS- oder Hyperscaler-Plattform muss die zuständige Behörde insbesondere prüfen:

ob eine ausreichende gesetzliche Grundlage besteht
welche Daten für den jeweiligen Zweck erforderlich sind
welche Folgen eine Verletzung von Vertraulichkeit, Integrität, Verfügbarkeit oder Nachvollziehbarkeit hätte
an welchen Orten Daten, Backups, Logs und Telemetriedaten bearbeitet werden
welche administrativen und technischen Zugriffsmöglichkeiten der Anbieter besitzt
welche Unterauftragsbearbeiter beteiligt sind
ob Zugriffe aus dem Ausland möglich sind
wer die kryptografischen Schlüssel kontrolliert
ob Daten vollständig exportiert und gelöscht werden können
ob ein Wechsel zu einer anderen Plattform möglich ist
wie der Betrieb bei Ausfällen, Vertragsbeendigung oder geopolitischen Veränderungen sichergestellt wird

11.4 Digitale Souveränität

Digitale Souveränität ist kein binärer Zustand. Sie bezeichnet die erforderliche Kontroll- und Handlungsfähigkeit einer Behörde im digitalen Raum.

Bei der Nutzung eines Hyperscalers sind insbesondere abzuwägen:

die rechtliche und technische Kontrolle
die Abhängigkeit von einem einzelnen Anbieter
die Wechsel- und Rückholfähigkeit
die Kontrolle über Daten und kryptografische Schlüssel
die Verfügbarkeit von Alternativen
die Beherrschung der Gesamtarchitektur
die eigene Betriebs- und Steuerungskompetenz
die vertragliche Durchsetzungsfähigkeit
Konzentrations- und Kaskadenrisiken
die Widerstandsfähigkeit gegenüber Krisen und geopolitischen Veränderungen

Ein internationaler Anbieter ist nicht allein aufgrund seiner Internationalität ausgeschlossen. Ebenso ist eine Lösung nicht allein deshalb digital souverän, weil Daten in einem Rechenzentrum in der Schweiz gespeichert werden.

Massgebend ist die tatsächliche Kontroll- und Handlungsfähigkeit der zuständigen Behörde.

11.5 Beitrag von AGOV

AGOV kann die digitale Souveränität einer Cloudarchitektur stärken, indem die primäre Authentisierung der natürlichen Person nicht vollständig an den Cloudanbieter übertragen werden muss.

Dadurch können insbesondere folgende Abhängigkeiten reduziert werden:

zusätzliche Passwörter beim Cloudanbieter
proprietäre Authentisierungsverfahren
die vollständige Verlagerung der primären Personenidentität in ein kommerzielles Cloudverzeichnis
unterschiedliche Identitätsprüfungen für einzelne Plattformen
eine dauerhafte Bindung der staatlichen Authentisierung an ein einzelnes Anbieterökosystem

Der Einsatz von AGOV beseitigt jedoch nicht die übrigen Abhängigkeiten einer Cloudplattform. Datenhaltung, Applikationslogik, Administration, Berechtigungsverwaltung, Verfügbarkeit und Exit-Fähigkeit sind weiterhin separat zu beurteilen.

12. Schlussfolgerung

AGOV kann für lokal betriebene Anwendungen, SaaS-Produkte und Anwendungen auf Hyperscaler-Plattformen eingesetzt werden.

Die Anbindung erfolgt direkt oder über ein bestehendes IAM beziehungsweise einen Identity-Broker mittels OIDC oder SAML.

Produktspezifische Interoperabilitätsanforderungen können regulär bei der Schweizerischen Bundeskanzlei eingebracht werden. Sie sind Bestandteil der AGOV-Produktsteuerung und der Weiterentwicklung des Dienstes.

AGOV authentisiert die natürliche Person. Es entscheidet nicht über die Zulässigkeit einer Cloudplattform, die Verarbeitung von Bürgerdaten oder die fachlichen Zugriffsrechte.

Die jeweils verantwortliche Behörde beziehungsweise Relying Party beurteilt die gesetzliche Grundlage, den Schutzbedarf, die Informationssicherheit, den Datenschutz, die digitale Souveränität und die erforderlichen technischen, organisatorischen und vertraglichen Massnahmen.

Damit können eine behördlich gesteuerte Authentisierung und moderne Cloudtechnologien miteinander verbunden werden, ohne die Verantwortlichkeiten zwischen AGOV, Relying Party und Cloudanbieter zu vermischen.