Multi-IAM-Interoperabilität Erstellt am 6.3.2026. Mischung manuell und KI. BK DTI mis.

Mit der zunehmenden Digitalisierung und Vernetzung von Organisationen entsteht die Anforderung, auf Anwendungen und Daten über Organisations- und Systemgrenzen hinweg zugreifen zu können. Gleichzeitig betreiben die beteiligten Stellen häufig eigene Identity- und Access-Management-Systeme (IAM) sowie unterschiedliche Fachanwendungen und Sicherheitsinfrastrukturen. Diese historisch gewachsenen, heterogenen Systeme sind in der Regel nicht direkt miteinander kompatibel und verwenden unterschiedliche Authentifizierungsmechanismen, Identitätsmodelle und Rollenstrukturen.

Die zentrale Herausforderung besteht darin, eine vertrauenswürdige und interoperable Architektur zu schaffen, welche diese Systeme miteinander verbindet, ohne ihre organisatorische und technische Autonomie vollständig aufzuheben.

Dabei sind zwei Dimensionen zu unterscheiden: Authentifizierung (Identität) und Autorisierung (Rollen, Rechte, Attribute). Beide Dimensionen können unabhängig voneinander gestaltet und unterschiedlich kombiniert werden.

Es gibt zwei Dimensionen, Authentifizierung (Identität) und Autorisierung (Rollen, Rechte, Attribute), welche separat zu betrachten sind, unterschiedliche Kombinationen sind möglich.

Bei diesem Modell authentifizieren sich Benutzer weiterhin bei ihrer Heimorganisation. Greift ein Benutzer auf eine Anwendung einer anderen Organisation zu, wird er zunächst zu seinem eigenen Identity Provider weitergeleitet, meldet sich dort an und kehrt danach mit einer signierten Bestätigung der Authentifizierung zur Zielanwendung zurück.

Das notwendige Vertrauen wird üblicherweise über eine Föderation organisiert. Diese betreibt ein gemeinsames Metadatenregister mit den Identity Providern und Anwendungen der Teilnehmer. Alle Systeme laden diese Metadaten regelmässig und akzeptieren Authentifizierungsbestätigungen von den darin aufgeführten Identity Providern. Dadurch müssen nicht alle Organisationen direkt miteinander Vertrauensbeziehungen einrichten, sondern vertrauen indirekt über die gemeinsame Föderation.

Vorteile:
– organisatorische Autonomie der Teilnehmer bleibt erhalten
– bewährter, standardisierter Ansatz für föderierte Authentifizierung
– Benutzer können ihre bestehenden Organisationslogins verwenden

Nachteile:
– Integration für Anwendungen relativ komplex
– Attribut- und Rollenmodelle müssen zwischen Organisationen abgestimmt werden
– Benutzerführung (Auswahl der Heimorganisation) kann unübersichtlich sein

Ein zentraler Trustbroker wie z. B. vermittelt zwischen mehreren Identity Providern und Anwendungen. Benutzer authentifizieren sich weiterhin bei ihrer Heimorganisation, jedoch erfolgt die technische Integration der Anwendungen nur mit dem Trustbroker. Dieser übernimmt die Weiterleitung der Authentifizierungsanfragen, vereinheitlicht Protokolle und kann Attribute oder Identitäten normalisieren.

Vorteile:
– Anwendungen müssen nur eine einzige Authentifizierungsschnittstelle integrieren
– unterschiedliche IAM-Systeme und Protokolle können miteinander verbunden werden
– Attribute und Identitäten können zentral vereinheitlicht werden

Nachteile:
– zusätzliche zentrale Infrastrukturkomponente
– hoher Vertrauens- und Governancebedarf für den Betreiber
– potenzieller Single Point of Failure ohne geeignete Redundanz

Ein gemeinsamer Identitätsprovider stellt eine zentrale Authentifizierungsinfrastruktur bereit, die von mehreren Organisationen genutzt werden kann. In der Schweiz kann diese Rolle beispielsweise AGOV übernehmen. Organisationen behalten ihre bestehenden IAM-Systeme, können jedoch zusätzlich AGOV als weiteren Loginweg anbieten oder ihre Identitäten mit AGOV föderieren.

Im Gegensatz zu einem zentralen Trustbroker wird AGOV nicht als Vermittlungsinstanz zwischen allen Identitätssystemen eingesetzt. Stattdessen wird AGOV als zusätzlicher Identity Provider in die bestehenden IAM-Landschaften integriert.

Der wesentliche Vorteil liegt darin, dass die Identität des Subjekts nach standardisierten Verfahren überprüft wird. Dadurch kann ein hohes Vertrauensniveau (z. B. Level of Assurance 3) erreicht werden. Bei rein föderierten Szenarien mit vielen unterschiedlichen Identity Providern ist dieses Niveau oft nicht gewährleistet, da die jeweiligen Onboarding- und Identifikationsprozesse der einzelnen IdPs variieren können.

Vorteile:
– standardisierte und geprüfte Identität (z. B. LoA 3)
– einheitlicher und vertrauenswürdiger Login für viele Anwendungen
– zusätzlicher Loginweg neben bestehenden Organisations-IAMs

Nachteile:
– AGOV muss mit bestehenden IAM-Systemen föderiert oder integriert werden
– keine automatische Vereinheitlichung der IAM-Landschaft
– organisatorische Rollen und Berechtigungen müssen weiterhin separat verwaltet werden

Die Schweizer e-ID kann grundsätzlich auch direkt als Login für Anwendungen verwendet werden. Dabei integriert die Anwendung einen sogenannten e-ID-Verifier, der die Authentifizierung der elektronischen Identität überprüft. Dieses Modell kann zusätzlich zu bestehenden IAM-Systemen eingesetzt werden, ohne dass diese selbst föderiert werden müssen.

Voraussetzung ist jedoch, dass das Zielökosystem einen eindeutigen Identifikator aus der e-ID verwenden darf. Der einzige dafür geeignete Identifier ist die AHV-Nummer, da nur sie eine stabile und organisationsübergreifend eindeutige Zuordnung der Person ermöglicht. Wenn die Verwendung der AHV-Nummer nicht zulässig ist, fehlt ein verlässlicher globaler Identifier für die Zuordnung von Benutzerkonten.

Im Gegensatz zu einem gemeinsamen Identitätsprovider wie AGOV muss bei diesem Modell nicht jedes IAM mit einem zentralen Login föderieren. Stattdessen muss jede Anwendung einen e-ID-Verifier integrieren.

In vielen Szenarien ist eine direkte e-ID-Anbindung jedoch weniger attraktiv, da AGOV die e-ID ebenfalls unterstützt und zusätzlich eigene technische Identifier bereitstellt, die auch ohne Verwendung der AHV-Nummer funktionieren. Dadurch kann die Integration über AGOV häufig einfacher und flexibler umgesetzt werden.

Vorteile:
– direkte Nutzung einer staatlich geprüften digitalen Identität
– kein Föderieren der bestehenden IAM-Systeme notwendig
– zusätzlicher Loginweg unabhängig von Organisationsidentitäten

Nachteile:
– eindeutiger Identifier nur über die AHV-Nummer möglich
– jede Anwendung muss einen e-ID-Verifier integrieren
– häufig geringerer Mehrwert gegenüber einer Integration über AGOV

Siehe auch das Autorisierungsmuster „Verifiable Credentials via e-ID-Vertrauensinfrastruktur“, bei dem Berechtigungen über kryptografisch signierte Nachweise übertragen werden können. Dieses Muster kann ebenfalls über AGOV genutzt werden und erfordert keine direkte Integration der e-ID in jede Anwendung.

Beim Active Directory-Trust vertrauen sich mehrere Active-Directory-Domänen gegenseitig für die Authentifizierung. Benutzer melden sich in ihrer Heimdomäne an und können anschliessend auf Ressourcen in anderen Domänen zugreifen. Voraussetzung ist, dass alle beteiligten Organisationen Active Directory einsetzen, da das Vertrauensmodell und die Authentifizierungsmechanismen darauf basieren. Die Authentifizierung erfolgt typischerweise über Kerberos, wobei die Zielumgebung der Authentifizierung der vertrauenden Domäne vertraut.

Autorisation erfolgt üblicherweise über Gruppen und Berechtigungen in der Zielumgebung, wobei auch Gruppen aus vertrauenden Domänen verwendet werden können.

Vorteile:
– direkte domänenübergreifende Authentifizierung ohne zusätzliche Föderationsinfrastruktur
– Gruppen können domänenübergreifend für Berechtigungen verwendet werden
– in bestehenden Windows-Infrastrukturen gut integriert

Nachteile:
– setzt voraus, dass alle beteiligten Organisationen Active Directory verwenden
– komplexe Vertrauensbeziehungen bei vielen Organisationen
– weniger geeignet für Internet- oder plattformübergreifende Szenarien

Bei diesem Modell einigen sich alle beteiligten Organisationen auf ein gemeinsames Rollen- und Attributschema. Rollen, Funktionen und andere Berechtigungsattribute werden organisationsübergreifend einheitlich definiert, sodass Anwendungen diese direkt interpretieren können. Die Identity Provider übermitteln diese standardisierten Rollen oder Attribute zusammen mit der Authentifizierung.

Die Harmonisierung kann komplementär oder subsidiär erfolgen. In einem komplementären Modell behalten Organisationen ihre bestehenden Rollen- und Attributmodelle bei und führen zusätzlich das gemeinsame Schema ein, das für organisationsübergreifende Anwendungen verwendet wird. In einem subsidiären Modell ersetzt das gemeinsame Rollenmodell die bisherigen organisationsspezifischen Nomenklaturen.

Der Vorteil liegt in der einfachen Autorisierungslogik: Anwendungen können Berechtigungen direkt auf Basis der übermittelten Rollen prüfen, ohne zusätzliche Mapping- oder Transformationslogik.

Vorteile:
– einfache und transparente Autorisierungslogik
– Anwendungen können Rollen direkt interpretieren
– klare organisationsübergreifende Semantik von Rollen und Attributen

Nachteile:
– hoher organisatorischer Abstimmungsaufwand zwischen den Beteiligten
– Pflege eines gemeinsamen Rollenmodells erforderlich
– Änderungen am Rollenmodell können mehrere Organisationen gleichzeitig betreffen

Bei diesem Modell behalten Organisationen ihre eigenen Rollen- und Attributmodelle, während eine zentrale Komponente diese Informationen für die Nutzung in gemeinsamen Anwendungen übersetzt oder interpretiert. Ein Mapper transformiert organisationsspezifische Rollen oder Attribute in ein gemeinsames Zielschema, das von den Anwendungen verstanden wird. Dadurch wird eine Viele-zu-Viele-Beziehung zwischen unterschiedlichen Rollenmodellen der Organisationen und den Anforderungen der Anwendungen aufgelöst.

Verwandt mit diesem Ansatz ist der Einsatz einer Policy Engine. Während ein Mapper primär Rollen oder Attribute transformiert, trifft eine Policy Engine anhand von Regeln eine Autorisierungsentscheidung für eine konkrete Anfrage, beispielsweise den Zugriff auf eine Ressource oder eine bestimmte Funktion.

Vorteile:
– bestehende Rollenmodelle der Organisationen können unverändert bleiben
– keine vollständige Harmonisierung der Rollen erforderlich
– flexible Autorisierungslogik möglich

Nachteile:
– zusätzliche zentrale Infrastrukturkomponente
– Pflege von Mappingregeln oder Policies kann komplex werden
– Autorisierungslogik weniger transparent als bei harmonisierten Rollen

Bei diesem Modell werden Berechtigungen oder Eigenschaften einer Person als Verifiable Credentials (VC) ausgestellt. Organisationen einigen sich dazu auf gemeinsame Aussagen (Claims), die in diesen Credentials enthalten sind, beispielsweise Rollen, Funktionen oder organisatorische Zugehörigkeiten. Jede Organisation betreibt typischerweise einen eigenen Issuer, der solche Credentials für ihre Benutzer ausstellt, meist hinter dem bestehenden IAM-System.

Für die Autorisierung integrieren Anwendungen zusätzlich zu ihrem bestehenden Accessmanagement einen Verifier, der diese Credentials prüfen kann. Benutzer aus anderen Organisationen müssen daher nicht im lokalen Accessmanagement geführt werden, sondern weisen ihre Berechtigungen durch entsprechende Verifiable Credentials nach.

Die Authentifizierung ist von diesem Modell unabhängig. Benutzer können sich über beliebige Loginmechanismen anmelden; die Verifiable Credentials werden anschliessend zusätzlich verwendet, um Berechtigungen nachzuweisen.

Ein zentraler Issuer wäre zwar denkbar, würde jedoch selbst wieder ein eigenes Identitätsmanagement benötigen. Deshalb ist es in vielen Szenarien sinnvoller, dass jede Organisation ihre Credentials selbst ausstellt.

Vorteile:
– Organisationen behalten ihr eigenes Accessmanagement
– fremde Benutzer müssen nicht im Zielsystem verwaltet werden
– dezentrale und organisationsübergreifende Berechtigungsnachweise möglich

Nachteile:
– gemeinsame Definition der Credential-Aussagen erforderlich
– zusätzliche Komponenten (Issuer und Verifier) notwendig
– Governance der Vertrauensinfrastruktur erforderlich

Bei diesem Modell liefert die Authentifizierung lediglich eine Identität des Benutzers. Die eigentliche Autorisierung erfolgt vollständig innerhalb der Zielapplikation. Rollen und Berechtigungen werden dort lokal verwaltet, beispielsweise über Benutzerkonten, Gruppen oder interne Rollenmodelle.

Externe Benutzer müssen daher in der Zielapplikation bekannt sein oder dort angelegt werden, etwa manuell oder über Provisioningmechanismen. Dieses Modell ist technisch einfach umzusetzen, führt jedoch dazu, dass organisationsübergreifende Benutzer häufig in mehreren Systemen separat verwaltet werden müssen.

Vorteile:
– sehr einfache Architektur ohne zusätzliche Infrastruktur
– vollständige Kontrolle über Berechtigungen in der Zielorganisation
– unabhängig von organisationsübergreifenden Rollenmodellen

Nachteile:
– fremde Benutzer müssen im Zielsystem verwaltet werden
– hoher administrativer Aufwand bei vielen Organisationen
– schlechte Skalierbarkeit bei stark vernetzten Systemlandschaften