Externe Identitäten

Dieser Artikel enthält zusätzliche Informationen zur Verwendung externer Identitäten mit dem Identity-Aware Proxy (IAP) anstelle von Google-Konten.

Übersicht

IAP steuert den Zugriff auf Ihre App Engine-Anwendungen und Compute Engine-VMs, die in Google Cloud ausgeführt werden. Dabei werden die Nutzeridentität und der Kontext einer Anfrage genutzt, um festzustellen, ob einem Nutzer Zugriff gewährt werden soll. IAP ist ein Baustein für BeyondCorp, ein Sicherheitsmodell für Unternehmen, das Mitarbeitern ermöglicht, ohne VPN mit nicht vertrauenswürdigen Netzwerken zu arbeiten.

Standardmäßig verwendet IAP Google-Identitäten und IAM. Wenn Sie stattdessen Identity Platform verwenden, können Sie Nutzer mit einer Vielzahl externer Identitätsanbieter authentifizieren. Dazu zählen zum Beispiel:

  • E-Mail-Adresse/Passwort
  • OAuth (Google, Facebook, Twitter, GitHub, Microsoft usw.)
  • SAML
  • OIDC
  • Telefonnummer
  • Benutzerdefiniert
  • Anonym

Dies ist hilfreich, wenn Ihre Anwendung bereits ein externes Authentifizierungssystem verwendet und die Migration Ihrer Nutzer zu Google-Konten keine sinnvolle Option ist.

Mehrinstanzenfähigkeit

Die Mehrinstanzenfähigkeit (oder Mehrmandantenfähigkeit) von Identity Platform wurde ursprünglich für B2B-Szenarien entwickelt, in denen ein Unternehmen seinen Dienst an andere Unternehmen verkauft. In solchen Fällen ist es unter Entwicklern üblich, Nutzerpopulationen in isolierte Pools aufzuteilen. Solche Silos werden als Mandanten bezeichnet.

Betrachten Sie dazu dieses Diagramm mit fiktiven Beziehungen:

Hierarchie mit mehreren Mandanten

In diesem Beispiel ist Acme ein Autohersteller (der Agent), der mithilfe von Identity Platform einen Dienst für Autohändler (Mandanten) bereitstellt. Diese Autohändler bieten ihrerseits Dienste für ihre Kunden, Mitarbeiter und Auftragnehmer an. Obwohl der Hersteller Eigentümer des Dienstes ist, kann jeder Autohändler seine eigenen Identitätsanbieter zur Authentifizierung verwenden. Nutzersitzungen und -daten werden auf Basis einzelner Mandanten aufgeteilt. Wenn ein Nutzer Beziehungen zu mehreren Autohändlern unterhält, werden diese unabhängig voneinander behandelt.

Je nach Anwendungsfall gibt es verschiedene Möglichkeiten, die Mandantenhierarchie zu strukturieren.

Keine Mandanten

Die Mehrinstanzenfähigkeit ist nur erforderlich, wenn Sie Ressourcen isolieren müssen. Diese Voraussetzung gilt aber nicht für alle Anwendungen. Wenn Sie beispielsweise eine einzelne App Engine-Anwendung haben und den Zugriff für alle Nutzer außerhalb Ihres Netzwerks blockieren möchten, ist keine Mehrinstanzenfähigkeit erforderlich. Standardmäßig speichert und authentifiziert Identity Platform Nutzer auf Projektbasis, sodass in diesem Fall keine zusätzliche Konfiguration erforderlich ist.

Ein anderes Beispiel ist ein Mischkonzern mit mehreren Tochtergesellschaften. Auch wenn jede Tochtergesellschaft ein eigenes verwaltetes Authentifizierungssystem verwendet (mit OIDC oder SAML), erhalten unter Umständen alle Mitarbeiter des Konzerns die gleichen grundlegenden Leistungen, z. B. in Bezug auf Gesundheitsversorgung, Urlaub und Gehaltsabrechnung. In diesem Fall ist die Authentifizierung auf Projektebene ausreichend.

Ein Mandant pro Ressource

Standardmäßig sind Identity Platform-Tokens ohne Mandanten auf Projektebene gültig. Theoretisch bedeutet dies, dass sich ein Nutzer mit einer IAP-Ressource authentifizieren und dann mit dem Token auf einen anderen Dienst im selben Projekt zugreifen kann. Das ist ein Sicherheitsrisiko.

Weisen Sie deshalb jedem IAP seinen eigenen Mandanten zu, um ihn zu isolieren. So lässt sich ein Tokenmissbrauch verhindern. Tokens, die in einem mandantenspezifischen Kontext erstellt werden, sind nur für diesen spezifischen Mandanten gültig. Wenn der Nutzer versucht, auf eine andere IAP-Ressource zuzugreifen, die einen anderen Mandanten verwendet, wird er aufgefordert, sich erneut zu authentifizieren.

Mehrere Mandanten pro Ressource

Einer einzelnen IAP-Ressource können mehrere Mandanten zugeordnet sein.

Wenn ein Nutzer auf die Ressource zugreift, haben Sie mehrere Möglichkeiten festzulegen, welcher Mandant verwendet werden soll. Sie können den Nutzer beispielsweise auffordern, zuerst seine E-Mail-Adresse einzugeben, und dann programmatisch nach einem Mandanten suchen, bei dem eine Übereinstimmung mit der E-Mail-Domain besteht. Alternativ haben Sie die Möglichkeit, eine UI anzeigen zu lassen, in der alle gültigen Mandanten aufgelistet werden, aus denen der Nutzer auswählen muss.

Nutzer können mehreren Mandanten mit unterschiedlichen Zugriffsebenen angehören. Sie können IAM zwar nicht zum Verwalten der Zugriffssteuerung mit externen Identitäten verwenden, aber Sie können die Zugriffe nach dem ausgewählten Mandanten oder nach den zugrunde liegenden ID-Token-Anforderungen des Nutzers filtern.

Ein Beispiel für ein Szenario mit mehreren Mandanten ist ein Unternehmen für betriebliche Altersversorgung mit zahlreichen Kunden, die alle dasselbe Webportal nutzen. Wenn ein Nutzer das Portal aufruft, wählt er zuerst sein Unternehmen (den Mandanten) aus und authentifiziert sich dann mit seinen Unternehmensanmeldedaten über den Anbieter, den der Arbeitgeber verwendet.

Nächste Schritte