Page principale Navigation Contenu Contact Sitemap Recherche

Generiert mit ChatGPT am 17.7.2026 BK DTI mis, nicht durch Menschen validiert.

Klassisches Login zuerst · Accessmanagement danach

Föderierte Authentifizierung und zwei alternative Access-Konzepte

Jeder Zugriff beginnt mit einem klassischen föderierten Login. Die Person authentisiert sich bei einem Identity Provider ihrer Organisation. Die erfolgreiche Anmeldung wird über ein etabliertes Föderationsprotokoll wie OpenID Connect (OIDC) oder SAML an die Anwendung vermittelt. Erst danach werden die für die Autorisierung erforderlichen Rollen, Eigenschaften und Berechtigungen ausgewertet.

1. Login beim IdP 2. Föderation über OIDC oder SAML 3. Accessdaten bestimmen 4. Autorisierungsentscheid

1. Gemeinsame Basis: klassische föderierte Authentifizierung

Die beteiligten Organisationen können unterschiedliche Identity Provider, IAM-Produkte und Authentisierungsmittel verwenden. Eine Föderationsinstanz beziehungsweise ein Identity Broker vermittelt das klassische Login gegenüber den angeschlossenen Anwendungen. Die Verbindungen können je nach Architektur über OIDC oder SAML erfolgen.

Die Authentifizierung ist für beide nachfolgend dargestellten Access-Konzepte identisch: IdP-Login und Föderation erfolgen klassisch über OIDC oder SAML.

2. Zwei alternative Konzepte für Accessmanagement und Autorisierung

Nach dem erfolgreichen föderierten Login muss bestimmt werden, welche Rollen, Geschäftsfunktionen, Organisationszugehörigkeiten oder weiteren Eigenschaften für den Zugriff gelten. Diese Accessdaten können entweder in einem gemeinsamen zentralen Berechtigungsdienst oder verteilt in Form von Verifiable Credentials bereitgestellt werden.

A

Klassisches Accessmanagement mit zentralem Berechtigungsdienst

Rollen, Gruppenzugehörigkeiten, Geschäftsfunktionen, Gültigkeiten, Delegationen und weitere Entitlements werden in einem gemeinsamen, zentral erreichbaren Berechtigungsdienst verwaltet.

Schema: klassisches Login bleibt vorgelagert
IdP Authentisiert die Person
OIDC / SAML
Identity Broker Vermittelt das Login
Anwendung Erhält die föderierte Anmeldung
Rollen und Entitlements
Zentraler Berechtigungsdienst Führt Rollen, Zuordnungen, Gültigkeiten und Policies
Policy Decision Point Bewertet Login, Rolle, Kontext, Ressource und Operation
erlauben / verweigern
Geschützte Ressource Zugriff wird durch die ressourcenhaltende Anwendung durchgesetzt
Gemeinsamer zentraler «Topf» für das Accessmanagement
Rollenkatalog · Organisationen · Rollenzuordnungen · Gültigkeiten · Delegationen · Entitlements · Policies · Entzüge

Wie erhält eine Person eine Rolle?

  1. Autoritative Grunddaten Personal-, Organisations- oder IAM-Systeme führen die massgebenden Angaben zur Person, ihrer Organisation und ihrem organisatorischen Kontext.
  2. Antrag oder fachlicher Auslöser Eine Rolle wird beantragt oder aufgrund eines definierten Geschäftsprozesses vorgeschlagen.
  3. Fachliche Prüfung und Genehmigung Die zuständige Rollen-, Organisations- oder Ressourcenverantwortung prüft Zweck, Umfang, Funktion und zeitliche Notwendigkeit.
  4. Zentrale Rollenzuordnung Die genehmigte Rolle wird im zentralen Berechtigungsdienst mit Organisation, Kontext, Gültigkeit und gegebenenfalls Delegationsrecht gespeichert.
  5. Klassisches Login Die Person authentisiert sich weiterhin bei ihrem IdP. Das Login wird über OIDC oder SAML an die Anwendung vermittelt.
  6. Aktuelle Accessdaten beziehen Die Anwendung oder der Policy Decision Point bezieht die aktuellen Rollen und Entitlements aus dem zentralen Berechtigungsdienst.
  7. Ressourcenbezogene Entscheidung Die ressourcenhaltende Organisation vergleicht die Rolle mit der aktuellen Policy der konkreten Ressource und der verlangten Operation.
  8. Mutation, Ablauf oder Entzug Änderungen erfolgen grundsätzlich im zentralen Dienst und werden unmittelbar oder zeitnah für alle angeschlossenen Systeme wirksam.
Abgrenzung Der zentrale Berechtigungsdienst muss nicht die Passwörter oder Authentisierungsmittel der Personen führen. Die Authentifizierung verbleibt bei den föderierten Identity Providern.
B

Verteiltes Accessmanagement mit Verifiable Credentials

Die autorisierungsrelevanten Eigenschaften werden von zuständigen Organisationen als digital signierte Nachweise ausgestellt, in einer Wallet gehalten und nach dem klassischen Login einem Verifier präsentiert.

Schema: VC ergänzt das klassische Login
IdP Authentisiert die Person
OIDC / SAML
Identity Broker Vermittelt das Login
Issuer Stellt ein VC auf Grundlage autoritativer Daten aus
Wallet / Holder Hält das VC und präsentiert die verlangten Claims
Verifier Prüft Issuer, Signatur, Gültigkeit, Status und Holder-Bindung
Anwendung Ist bereits über OIDC oder SAML föderiert angemeldet
VC-Präsentation, z. B. OpenID4VP
Verifier Liefert verifizierte Claims an die Autorisierung
Policy Decision Point Bewertet Login, VC-Claims, Ressource und Operation
erlauben / verweigern
Geschützte Ressource Zugriff wird durch die ressourcenhaltende Anwendung durchgesetzt

Wie erhält eine Person ein Verifiable Credential?

  1. Autoritative Grunddaten Die zuständige Organisation führt die massgebenden Angaben zur Person, ihrer Organisationszugehörigkeit, Rolle, Geschäftsfunktion oder weiteren Eigenschaft.
  2. Ausstellungsregel und Genehmigung Es wird geprüft, ob die Person die fachlichen Voraussetzungen erfüllt und ob die Organisation genau diesen Nachweistyp ausstellen darf.
  3. Issuing Der technische Issuer erzeugt und signiert das VC. Die technische Ausgabe an die Wallet kann beispielsweise über OpenID4VCI erfolgen.
  4. Ausgabe an Wallet und Holder-Bindung Das VC wird an die richtige Person beziehungsweise deren Wallet gebunden und dort durch den Holder verwaltet.
  5. Klassisches Login Beim späteren Zugriff authentisiert sich die Person zuerst regulär bei ihrem IdP. Das Login wird über OIDC oder SAML an die Anwendung vermittelt.
  6. Präsentationsanfrage Erst nach dem Login fordert der Verifier die für den konkreten Zugriff notwendigen Nachweise oder Claims an.
  7. Verifikation Der Verifier prüft Signatur, Issuer-Vertrauen, Ausstellungsberechtigung, Gültigkeit, Status, Holder-Bindung und die konkrete Präsentation.
  8. Ressourcenbezogene Entscheidung Die verifizierten Claims werden an den Policy Decision Point übergeben. Die ressourcenhaltende Organisation entscheidet weiterhin über den konkreten Zugriff.
  9. Ablauf, Suspendierung, Widerruf oder Neuausstellung Ändert sich die zugrunde liegende Eigenschaft, muss das VC zeitnah unwirksam werden oder mit aktualisierten Claims neu ausgestellt werden.
Abgrenzung Ein gültiges VC ist weder ein Login noch automatisch eine Ressourcenberechtigung. Es liefert nach dem Login verifizierte Aussagen als Grundlage für die fachliche Autorisierungsentscheidung.

3. Gemeinsamer Zugriffsablauf

Die ersten drei Schritte sind in beiden Access-Konzepten identisch. Erst nach dem klassischen föderierten Login unterscheidet sich, wie die autorisierungsrelevanten Rollen und Eigenschaften bereitgestellt werden.

1 Login starten Die Person öffnet eine Anwendung und wird zur Anmeldung aufgefordert.
2 IdP authentisiert Die Person authentisiert sich beim Identity Provider ihrer Organisation.
3 OIDC oder SAML Der Broker vermittelt die erfolgreiche Authentifizierung an die Anwendung.
4 Ressource wählen Die Person verlangt eine bestimmte Operation auf einer geschützten Ressource.
5 Accessdaten bestimmen Zentrale Rolle abrufen oder VC-Claims präsentieren und verifizieren.
6 Policy prüfen Person, Organisation, Rolle, Kontext, Ressource und Operation werden bewertet.
7 Zugriff durchsetzen Der Policy Enforcement Point erlaubt oder verweigert die verlangte Operation.
8 Nachvollziehen Entscheid und Zugriff werden angemessen und datenschutzkonform protokolliert.

4. Vergleich der beiden Access-Konzepte

Aspekt Klassischer zentraler Berechtigungsdienst Verteilte Verifiable Credentials
Login Klassischer föderierter Login beim IdP über OIDC oder SAML Ebenfalls klassischer föderierter Login beim IdP über OIDC oder SAML
Funktion des VC Kein VC erforderlich Ergänzt das Login um verifizierbare autorisierungsrelevante Aussagen
Ort der Rolleninformation Zentraler Rollen-, Entitlement- und Policy-Dienst Als ausgestellter Nachweis in der Wallet der Person
Fachliche Datenquelle Lokale Systeme liefern Daten an den zentralen Dienst oder Rollen werden dort über definierte Genehmigungsprozesse zugeordnet. Die zuständige Organisation verwendet autoritative Quellen für die Ausstellung des VC.
Bereitstellung beim Zugriff Onlineabfrage oder gesicherte Übermittlung aktueller Rollen und Entitlements Präsentation und Verifikation der notwendigen Claims nach dem Login
Aktualität Grundsätzlich unmittelbar über die zentrale Quelle prüfbar Abhängig von Gültigkeit, Statusprüfung, Suspendierung, Widerruf oder kurzer Laufzeit
Benutzerinteraktion Die Rollenprüfung erfolgt normalerweise ohne zusätzliche Präsentationshandlung. Die Person beziehungsweise ihre Wallet ist zusätzlich in die Nachweispräsentation eingebunden.
Vertrauensmodell Vertrauen in den Identity Broker, die zentrale Rollenverwaltung, die Datenlieferanten und die angeschlossenen Systeme Zusätzlich Vertrauen in Issuer, Nachweistyp, Vertrauensinfrastruktur, Wallet und Verifier
Entzug Entzug oder Mutation der Zuordnung im zentralen Berechtigungsdienst Widerruf, Suspendierung, Ablauf oder Neuausstellung des Nachweises
Ressourcenbezogene Autorisierung In beiden Konzepten durch die ressourcenhaltende Organisation beziehungsweise deren Anwendung. Login, Rolle oder VC ersetzen diesen Entscheid nicht.

5. Vor- und Nachteile der beiden Access-Konzepte

Beide Konzepte können die gemeinsamen Anforderungen an Authentifizierung und Autorisierung erfüllen. Die Unterschiede liegen vor allem in der Betriebsverantwortung, der Aktualität der Accessdaten, der Benutzerinteraktion sowie im Governance- und Integrationsaufwand.

Klassischer zentraler Berechtigungsdienst

Rollen, Entitlements und Policies werden in einem gemeinsamen Accessmanagement geführt und beim Zugriff online ausgewertet.

Vorteile

  • Rollenänderungen und Entzüge können grundsätzlich unmittelbar an einer zentralen Stelle wirksam werden.
  • Nach dem föderierten Login ist normalerweise keine zusätzliche Handlung der Person erforderlich.
  • Rollen, Genehmigungen, Delegationen und Policies können einheitlich gesteuert und nachvollzogen werden.
  • Es werden keine Wallet-, Issuing- und Credential-Statusprozesse benötigt.

Nachteile

  • Der zentrale Dienst wird zu einer betrieblich kritischen Abhängigkeit und muss hochverfügbar ausgelegt sein.
  • Die zentrale Zusammenführung vieler Rollen- und Berechtigungsdaten erhöht Schutzbedarf und Governance-Aufwand.
  • Neue Organisationen und Anwendungen benötigen Schnittstellen, Rollen-Mappings und verbindliche Anschlussprozesse.
  • Unterschiedliche Organisationsmodelle müssen in einem gemeinsamen Berechtigungsmodell harmonisiert werden.

Verteiltes Accessmanagement mit Verifiable Credentials

Zuständige Organisationen stellen autorisierungsrelevante Eigenschaften als prüfbare Nachweise aus, die bei Bedarf präsentiert und verifiziert werden.

Vorteile

  • Die fachlich zuständige Organisation bleibt für ihre Eigenschaften und deren Ausstellung verantwortlich.
  • Nachweise können gegenüber mehreren Verifiern verwendet werden, sofern Vertrauensmodell und Policies dies zulassen.
  • Es müssen nicht sämtliche Rollenzuordnungen in einem einzigen zentralen Berechtigungsbestand zusammengeführt werden.
  • Je nach Credential- und Präsentationsformat können gezielt nur die benötigten Claims offengelegt werden.

Nachteile

  • Issuing, Wallet-Bindung, Ablauf, Suspendierung, Widerruf und Neuausstellung erfordern zusätzliche Betriebsprozesse.
  • Die zeitnahe Feststellung ungültig gewordener Eigenschaften benötigt verlässliche und hochverfügbare Statusmechanismen.
  • Die Person beziehungsweise ihre Wallet ist zusätzlich in die Präsentation eingebunden, was Bedienung und Support erweitert.
  • Issuer, Nachweistypen, Schemas, Verifier und Vertrauensregister benötigen eine organisationsübergreifende Governance.
Einordnung: Keines der beiden Konzepte ist generell überlegen. Die Bewertung muss sich unter anderem an Aktualitätsanforderungen, Anzahl der beteiligten Organisationen, Benutzerfreundlichkeit, Datenschutz, Betriebsmodell, Governance und Integrationsaufwand orientieren. Auch eine Kombination ist möglich, sofern Zuständigkeiten und führende Quellen eindeutig bleiben.

6. Verbindliche Regeln für beide Konzepte

Login bleibt klassisch

Die Authentifizierung erfolgt beim IdP und wird über OIDC oder SAML föderiert. Ein VC ersetzt diesen Login nicht.

Rolle ist nicht Ressourcenberechtigung

Eine zentrale Rolle oder ein VC-Claim ersetzt nicht die Prüfung der konkreten Berechtigung auf der geschützten Ressource.

Zeitnaher Entzug

Rollenwechsel, Austritt, Sperrung und Berechtigungsentzug müssen unmittelbar oder innerhalb einer verbindlich definierten Frist wirksam werden.

Ressourcenhoheit bleibt lokal

Die ressourcenhaltende Organisation bestimmt die erlaubten Operationen und behält die abschliessende Kontrolle über den Zugriff.

Delegation: Eine delegierende Organisation darf weder einen grösseren Umfang noch eine längere Gültigkeit weitergeben, als ihr ursprünglich eingeräumt wurde. Der Entzug des ursprünglichen Rechts muss auch alle davon abgeleiteten Rechte erfassen.

Gemini-Review des obigen ChatGPT-Artikels
×

Fachliches Gutachten / Review

Review: Föderierte Authentifizierung & Access-Konzepte

Status: Fachlich freigegeben (Excellent)
Dieses Dokument beschreibt die Zielarchitektur fehlerfrei und trennt die Identitätsvermittlung (AuthN) präzise von den beiden Autorisierungs-Ansätzen (Zentraler Dienst vs. Dezentrale VCs).

Empfehlung für die Zielgruppe (BK DTI): Der Artikel eignet sich hervorragend als strategische Entscheidungsgrundlage. Er entzaubert den "VC-Hype", indem er zeigt, dass VCs die bewährte Föderation (wie AGOV) nicht konkurrenzieren, sondern das Berechtigungsmanagement auf ein neues, föderiertes Level heben.