Nutzer mit PHP authentifizieren

---

Bei Anwendungen, die auf von Google Cloud verwalteten Plattformen wie App Engine ausgeführt werden, können Sie die Nutzerauthentifizierung und Sitzungsverwaltung vermeiden, wenn Sie Identity-Aware Proxy (IAP) verwenden, um den Zugriff darauf zu steuern. IAP kann nicht nur den Zugriff auf die Anwendung steuern, sondern auch Informationen über die authentifizierten Nutzer bereitstellen, einschließlich der E-Mail-Adresse und einer persistenten Anwendungskennung in Form neuer HTTP-Header.

Lernziele

• Für Nutzer der App Engine-Anwendung festlegen, dass sie sich mithilfe von IAP authentifizieren müssen

• Auf Identitäten von Nutzern in der Anwendung zugreifen, um die E-Mail-Adresse des aktuellen Nutzers aufzurufen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• App Engine
• IAP

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Install the Google Cloud CLI.

4. To initialize the gcloud CLI, run the following command:

   gcloud init

5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

6. Install the Google Cloud CLI.

7. To initialize the gcloud CLI, run the following command:

   gcloud init

Hintergrund

In dieser Anleitung werden Nutzer mithilfe von IAP authentifiziert. Dies ist nur eine von mehreren möglichen Vorgehensweisen zur Authentifizierung. Weitere Informationen über die verschiedenen Methoden zur Authentifizierung von Nutzern finden Sie im Abschnitt Authentifizierungskonzepte.

Anwendung "Hello user-email-address"

Die Anwendung für diese Anleitung ist eine App Engine-Minimalanwendung vom Typ "Hello World", mit einem untypischen Feature: Anstelle von "Hello World" wird "Hello user-email-address" angezeigt, wobei user-email-address die E-Mail-Adresse des authentifizierten Nutzers ist.

Zur Bereitstellung dieser Funktionalität werden die Authentifizierungsinformationen ausgewertet, die der IAP-Dienst jeder Webanfrage hinzufügt, die er an die Anwendung weiterleitet. Jeder Webanfrage an Ihre Anwendung werden drei neue Anfrageheader hinzugefügt. Die ersten beiden Header sind Nur-Text-Strings, mit denen Sie den Nutzer identifizieren können. Der dritte Header ist ein kryptografisch signiertes Objekt mit denselben Informationen.

• X-Goog-Authenticated-User-Email: Ein Nutzer wird durch seine E-Mail-Adresse identifiziert. Speichern Sie keine personenbezogenen Daten, wenn dies für Ihre Anwendung möglich ist. Diese Anwendung speichert keine Daten, sondern gibt sie lediglich an den Nutzer zurück.

• X-Goog-Authenticated-User-Id: Diese von Google zugewiesene Nutzer-ID stellt keine Information über den Nutzer dar. Eine Anwendung kann aber aufgrund der Nutzer-ID feststellen, dass ein angemeldeter Nutzer zuvor schon einmal authentifiziert wurde.

• X-Goog-Iap-Jwt-Assertion: Sie können Google Cloud-Anwendungen so konfigurieren, dass neben Webanfragen aus dem Internet auch Webanfragen von anderen Cloud-Anwendungen unter Umgehung von IAP akzeptiert werden. Wenn eine Anwendung in dieser Weise konfiguriert ist, besteht die Möglichkeit, dass solche Anfragen gefälschte Header haben. Anstatt der oben genannten Nur-Text-Header können Sie deshalb auch den kryptografisch signierten Header verwenden und verifizieren. Damit lässt sich prüfen, ob die Informationen von Google bereitgestellt wurden. Die E-Mail-Adresse des Nutzers sowie eine nichtflüchtige Nutzer-ID stehen als Teil dieses signierten Headers zur Verfügung.

Wenn die Anwendung so konfiguriert ist, dass nur Webanfragen aus dem Internet darauf zugreifen können, und dafür gesorgt ist, dass niemand den IAP-Dienst für die Anwendung deaktivieren kann, muss für den Abruf einer eindeutigen Nutzer-ID nur eine einzige Codezeile geschrieben werden:

$userId = getallheaders()['X-Goog-Authenticated-User-Id'] ?? null;

Hinweis: Die Funktion getallheaders ist nur für NGINX in PHP 7.3 oder höher verfügbar.

Eine robuste Anwendung sollte jedoch auf Fehler vorbereitet sein, etwa, wenn unerwartete Konfigurations- oder Umgebungsprobleme auftreten. Daher empfehlen wir stattdessen, eine Funktion zu erstellen, die den kryptografisch signierten Header verwendet und verifiziert. Die Signatur eines solchen Headers kann nicht gefälscht und kann nach erfolgter Verifizierung zur Rückgabe der Identifizierung verwendet werden.

Quellcode erstellen

1. Erstellen Sie mit einem Texteditor eine Datei mit dem Namen index.php und fügen Sie den folgenden Code ein:

   Authenticate-users/index.php

   Auf GitHub ansehen

   require_once __DIR__ . '/vendor/autoload.php';
   
   /**
    * Checks that the JWT assertion is valid (properly signed, for the
    * correct audience) and if so, returns strings for the requesting user's
    * email and a persistent user ID. If not valid, returns null for each field.
    *
    * @param string $idToken The JWT string to assert.
    * @param string $audience The audience of the JWT.
    *
    * @return string[] array containing [$email, $id]
    * @throws Exception on failed validation
    */
   function validate_assertion(string $idToken, string $audience) : array
   {
       $auth = new Google\Auth\AccessToken();
       $info = $auth->verify($idToken, [
         'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
         'throwException' => true,
       ]);
   
       if ($audience != $info['aud'] ?? '') {
           throw new Exception(sprintf(
               'Audience %s did not match expected %s', $info['aud'], $audience
           ));
       }
   
       return [$info['email'], $info['sub']];
   }
   
   /**
    * This is an example of a front controller for a flat file PHP site. Using a
    * static list provides security against URL injection by default.
    */
   switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
       case '/':
           if (!Google\Auth\Credentials\GCECredentials::onGce()) {
               throw new Exception('You must deploy to appengine to run this sample');
           }
           $metadata = new Google\Cloud\Core\Compute\Metadata();
           $audience = sprintf(
               '/projects/%s/apps/%s',
               $metadata->getNumericProjectId(),
               $metadata->getProjectId()
           );
           $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
           try {
               list($email, $id) = validate_assertion($idToken, $audience);
               printf("<h1>Hello %s</h1>", $email);
           } catch (Exception $e) {
               printf('Failed to validate assertion: %s', $e->getMessage());
           }
           break;
       case '': break; // Nothing to do, we're running our tests
       default:
           http_response_code(404);
           exit('Not Found');
   }

   Die Datei index.php wird weiter unten im Abschnitt Erläuterungen zum Code dieser Anleitung ausführlich erläutert.

2. Erstellen Sie eine weitere Datei mit dem Namen composer.json und fügen Sie Folgendes ein:

   Authenticate-users/composer.json

   Auf GitHub ansehen

   {
     "require": {
       "php": ">=7.1",
       "google/auth": "^1.9",
       "google/cloud-core": "^1.32",
       "kelvinmo/simplejwt": "^0.4.0"
     }
   }
   

   In der Datei composer.json sind alle PHP-Bibliotheken aufgeführt, die App Engine für die Anwendung laden muss:

   • firebase/php-jwt stellt die Prüf- und Decodierungsfunktion des JWT bereit.

   • guzzle/http ist ein HTTP-Client zum Abrufen von Daten aus Websites.

3. Erstellen Sie eine Datei mit dem Namen app.yaml und fügen Sie den folgenden Text ein:

   authenticate-users/app.yaml

   Auf GitHub ansehen

   runtime: php73
   

   Die Datei app.yaml gibt für App Engine an, welche Sprachumgebung Ihr Code benötigt.

Code verstehen

In diesem Abschnitt wird gezeigt, wie der Code in index.php funktioniert. Wenn Sie nur die Anwendung ausführen möchten, können Sie mit dem Abschnitt Anwendung bereitstellen fortfahren.

Der im Folgenden aufgeführte Code ist in der Datei index.php enthalten. Wenn die Anwendung eine HTTP GET-Anfrage für die Startseite empfängt, wird die Switch Case-Anweisung für / aufgerufen:

Authenticate-users/index.php

Auf GitHub ansehen

/**
 * This is an example of a front controller for a flat file PHP site. Using a
 * static list provides security against URL injection by default.
 */
switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
    case '/':
        if (!Google\Auth\Credentials\GCECredentials::onGce()) {
            throw new Exception('You must deploy to appengine to run this sample');
        }
        $metadata = new Google\Cloud\Core\Compute\Metadata();
        $audience = sprintf(
            '/projects/%s/apps/%s',
            $metadata->getNumericProjectId(),
            $metadata->getProjectId()
        );
        $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
        try {
            list($email, $id) = validate_assertion($idToken, $audience);
            printf("<h1>Hello %s</h1>", $email);
        } catch (Exception $e) {
            printf('Failed to validate assertion: %s', $e->getMessage());
        }
        break;
    case '': break; // Nothing to do, we're running our tests
    default:
        http_response_code(404);
        exit('Not Found');
}

Die Switch-Anweisung ruft den JWT-Assertion-Headerwert ab, den IAP aus der eingehenden Anfrage hinzugefügt hat, und ruft eine Funktion auf, um diesen kryptografisch signierten Wert zu validieren. Der erste zurückgegebene Wert (E-Mail-Adresse) wird dann für eine Minimalwebseite verwendet, die erstellt und zurückgegeben wird.

Authenticate-users/index.php

Auf GitHub ansehen

/**
 * Checks that the JWT assertion is valid (properly signed, for the
 * correct audience) and if so, returns strings for the requesting user's
 * email and a persistent user ID. If not valid, returns null for each field.
 *
 * @param string $idToken The JWT string to assert.
 * @param string $audience The audience of the JWT.
 *
 * @return string[] array containing [$email, $id]
 * @throws Exception on failed validation
 */
function validate_assertion(string $idToken, string $audience) : array
{
    $auth = new Google\Auth\AccessToken();
    $info = $auth->verify($idToken, [
      'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
      'throwException' => true,
    ]);

    if ($audience != $info['aud'] ?? '') {
        throw new Exception(sprintf(
            'Audience %s did not match expected %s', $info['aud'], $audience
        ));
    }

    return [$info['email'], $info['sub']];
}

Die Funktion validate_assertion verwendet die Bibliothek google/auth, um zu überprüfen, ob die Assertion ordnungsgemäß signiert ist, und um die Nutzlastinformationen aus der Assertion zu extrahieren. Wenn die Assertion nicht decodiert werden kann, gibt die Funktion eine Ausnahme aus. Bei Erfolg gibt die Funktion die E-Mail-Adresse des authentifizierten Nutzers sowie eine persistente eindeutige ID für den Nutzer zurück.

Damit eine JWT-Assertion validiert werden kann, müssen die Public-Key-Zertifikate der Entität, die die Assertion signiert hat (in diesem Fall Google), und das Ziel (Identitätsanbieter) bekannt sein, für das die Assertion bestimmt ist. Bei einer App Engine-Anwendung ist das Ziel ein String mit Identifizierungsinformationen für das Google Cloud-Projekt. Die Funktion ruft diese Zertifikate und den Zielstring aus den Funktionen ab, die zuvor ausgeführt wurden.

Authenticate-users/index.php

Auf GitHub ansehen

$metadata = new Google\Cloud\Core\Compute\Metadata();
$audience = sprintf(
    '/projects/%s/apps/%s',
    $metadata->getNumericProjectId(),
    $metadata->getProjectId()
);

Sie können die numerische ID und den Namen des Google Cloud-Projekts selbst ermitteln und in den Quellcode einfügen oder dies von der Funktion audience erledigen lassen. Diese Funktion fragt den Standard-Metadatendienst ab, der allen App Engine-Anwendungen zur Verfügung steht.

Der App Engine-Metadatendienst und vergleichbare Metadatendienste für andere Google Cloud-Computing-Dienste verhalten sich wie eine Website und werden mit Standardwebabfragen abgefragt. Er ist jedoch keine externe Website, sondern ein internes Feature, das angeforderte Informationen zur ausgeführten Anwendung zurückgibt. Sie können also ohne Sicherheitsbedenken http-Anfragen anstelle von https-Anfragen verwenden. Mit dem Dienst werden die aktuellen Google Cloud-Kennungen abgerufen, die zur Bestimmung des gewünschten Ziels der JWT-Assertion erforderlich ist.

Anwendung bereitstellen

Jetzt können Sie die Anwendung bereitstellen und IAP aktivieren, damit sich Nutzer authentifizieren müssen, bevor sie auf die Anwendung zugreifen können.

1. Wechseln Sie in Ihrem Terminalfenster zum Verzeichnis mit der Datei app.yaml und stellen Sie die Anwendung in App Engine bereit:

   gcloud app deploy
   

2. Wählen Sie bei entsprechender Aufforderung eine Region in der Nähe aus.

3. Wenn Sie gefragt werden, ob Sie den Bereitstellungsvorgang fortsetzen möchten, geben Sie Y ein.

   Ihre Anwendung ist dann innerhalb weniger Minuten online verfügbar.

4. Rufen Sie die Anwendung auf:

   gcloud app browse
   

   Kopieren Sie in der Ausgabe die Webadresse der Anwendung (web-site-url).

5. Fügen Sie web-site-url in ein Browserfenster ein, um die Anwendung zu öffnen.

   Es wird keine E-Mail-Adresse angezeigt, da Sie IAP noch nicht verwenden und damit keine Nutzerinformationen an die Anwendung gesendet werden.

IAP aktivieren

Nachdem jetzt eine App Engine-Instanz vorhanden ist, können Sie sie mit IAP schützen:

1. Rufen Sie in der Google Cloud Console die Seite Identity-Aware Proxy auf.

   Zur Seite "Identity-Aware Proxy"

2. Da Sie zum ersten Mal eine Authentifizierungsoption für dieses Projekt aktiviert haben, werden Sie in einer Meldung darauf hingewiesen, dass Sie den OAuth-Zustimmungsbildschirm konfigurieren müssen, bevor Sie IAP verwenden können.

   Klicken Sie auf Zustimmungsbildschirm konfigurieren.

3. Geben Sie auf dem Tab OAuth-Zustimmungsbildschirm der Seite Anmeldedaten Werte in die folgenden Felder ein:

   • Wenn sich Ihr Konto in einer Google Workspace-Organisation befindet, wählen Sie Extern aus und klicken Sie auf Erstellen. Die Anwendung ist anfangs nur für Nutzer verfügbar, die Sie ausdrücklich zulassen.

   • Geben Sie im Feld Name der Anwendung den Namen IAP Example ein.

   • Geben Sie im Feld Support-E-Mail-Adresse Ihre E-Mail-Adresse ein.

   • Geben Sie im Feld Autorisierte Domain den Hostnamen-Teil der Anwendungs-URL ein, z. B. iap-example-999999.uc.r.appspot.com. Drücken Sie die Taste Enter, nachdem Sie den Hostnamen im Feld eingegeben haben.

   • Geben Sie im Feld Link zur Startseite der Anwendung die URL für Ihre Anwendung ein, z. B. https://iap-example-999999.uc.r.appspot.com/.

   • Verwenden Sie zu Testzwecken im Feld Link zur Datenschutzerklärung der Anwendung die URL für den Link zur Startseite.

4. Klicken Sie auf Speichern. Wenn Sie aufgefordert werden, Anmeldedaten zu erstellen, können Sie das Fenster schließen.

5. Rufen Sie in der Google Cloud Console die Seite Identity-Aware Proxy auf.

   Zur Seite "Identity-Aware Proxy"

6. Klicken Sie zum Aktualisieren der Seite auf Aktualisieren . Auf der Seite wird eine Liste von Ressourcen angezeigt, die Sie schützen können.

7. Klicken Sie in die Spalte IAP, um IAP für die Anwendung zu aktivieren.

8. Rufen Sie in Ihrem Browser noch einmal web-site-url auf.

9. Anstelle der Webseite wird ein Anmeldebildschirm zur Authentifizierung angezeigt. Wenn Sie sich anmelden, wird Ihnen der Zugriff verweigert, da in IAP keine Liste von Nutzern vorhanden ist, die für die Anwendung zugelassen sind.

Autorisierte Nutzer in die Anwendung einfügen

1. Rufen Sie in der Google Cloud Console die Seite "Identity-Aware Proxy" auf.

   Zur Seite "Identity-Aware Proxy"

2. Klicken Sie auf das Kästchen für die App Engine-Anwendung und dann auf Hauptkonto hinzufügen.

3. Geben Sie allAuthenticatedUsers ein und wählen Sie dann die Cloud IAP-Rolle Nutzer von IAP-gesicherten Web-Apps aus.

4. Klicken Sie auf Speichern.

Nun hat jeder Nutzer, der von Google authentifiziert werden kann, die Möglichkeit, auf die Anwendung zuzugreifen. Bei Bedarf können Sie den Zugriff weiter einschränken und dafür etwa eine oder mehr Personen bzw. Gruppen als Hauptkonto hinzufügen:

• Gmail- oder Google Workspace-E-Mail-Adressen

• E-Mail-Adresse einer Google-Gruppe

• Google Workspace-Domainname

Auf die Anwendung zugreifen

1. Rufen Sie im Browser web-site-url auf:

2. Klicken Sie zum Aktualisieren der Seite auf Aktualisieren .

3. Melden Sie sich auf dem Anmeldebildschirm mit Ihren Google-Anmeldedaten an.

   Die Seite "Hello user-email-address" wird mit Ihrer E-Mail-Adresse angezeigt.

   Wenn Sie noch immer die gleiche Seite wie zuvor sehen, aktualisiert der Browser neue Anfragen möglicherweise nicht vollständig, nachdem IAP jetzt aktiviert ist. Schließen Sie in diesem Fall alle Browserfenster, öffnen Sie sie wieder und versuchen Sie es noch einmal.

Konzepte der Authentifizierung

Es gibt mehrere Möglichkeiten für Anwendungen, Nutzer zu authentifizieren und den Zugriff auf autorisierte Nutzer einzuschränken. In den folgenden Abschnitten werden gängige Authentifizierungsmethoden dargestellt, wobei die Methoden mit höherem Aufwand für die Anwendung zuerst aufgeführt sind.

Option	Vorteile	Nachteile
Authentifizierung von Anwendungen	Die App kann auf jeder Plattform mit oder ohne Internetverbindung ausgeführt werden. Nutzer müssen keinen anderen Dienst verwenden, um die Authentifizierung zu verwalten.	Die App muss Nutzeranmeldedaten sicher verwalten und vor Offenlegung schützen Die App muss Sitzungsdaten für angemeldete Nutzer verwalten. Die App muss Nutzerregistrierung, Passwortänderungen und Passwortwiederherstellung bereitstellen
OAuth2	Die Anwendung kann auf jeder mit dem Internet verbundenen Plattform ausgeführt werden, einschließlich einer Entwicklerworkstation Die Anwendung benötigt keine Nutzerregistrierung, Passwortänderungen oder Funktionen zur Passwortwiederherstellung. Das Risiko der Offenlegung von Nutzerdaten wird an einen anderen Dienst delegiert Neue Maßnahmen zur Anmeldesicherheit außerhalb der App	Nutzer müssen sich beim Identitätsdienst registrieren Die App muss Sitzungsdaten für angemeldete Nutzer verwalten.
IAP	Die Anwendung muss keinen Code zur Verwaltung von Nutzern, Authentifizierung oder Sitzungsstatus enthalten Die App enthält keine Nutzeranmeldedaten, die gehackt werden könnten	Die Anwendung kann nur auf Plattformen ausgeführt werden, die vom Dienst unterstützt werden. Das gilt besonders für bestimmte Google Cloud-Dienste, die IAP unterstützen, z. B. App Engine.

Von der Anwendung verwaltete Authentifizierung

Bei dieser Methode wird jeder Aspekt der Nutzerauthentifizierung von der Anwendung selbst verwaltet. Die Anwendung muss dabei ihre eigene Datenbank mit Nutzeranmeldedaten bereitstellen sowie Nutzersitzungen verwalten. Außerdem muss sie Funktionen zum Verwalten von Nutzerkonten und Passwörtern, zum Prüfen von Nutzeranmeldedaten sowie zum Erstellen, Prüfen und Aktualisieren von Nutzersitzungen bei jeder authentifizierten Anmeldung enthalten. Das folgende Diagramm veranschaulicht diese Methode, bei der die Authentifizierung von der Anwendung verwaltet wird.

Wie im Diagramm dargestellt, erstellt und verwaltet die App nach der Anmeldung des Nutzers Informationen zur Nutzersitzung. Wenn der Nutzer eine Anfrage an die Anwendung sendet, muss die Anfrage Sitzungsinformationen enthalten, für deren Verifizierung die Anwendung zuständig ist.

Der Hauptvorteil besteht bei diesem Ansatz darin, dass er eigenständig ist und von der Anwendung gesteuert werden kann. Die Anwendung muss dabei nicht im Internet verfügbar sein. Der Hauptnachteil ist, dass die Anwendung nun für die Bereitstellung aller Kontoverwaltungsfunktionen und für den Schutz aller vertraulichen Anmeldedaten zuständig ist.

Externe Authentifizierung mit OAuth2

Eine gute Alternative zur Verwaltung und Ausführung aller Vorgänge in der Anwendung ist die Verwendung eines externen Identitätsdienstes wie Google. Dieser ist für alle Kontoinformationen und Funktionen sowie für den Schutz vertraulicher Anmeldedaten zuständig. Wenn sich dann ein Nutzer bei der Anwendung anmeldet, wird die Anfrage an den Identitätsdienst weitergeleitet, der den Nutzer authentifiziert und die Anfrage mit den erforderlichen Authentifizierungsinformationen an die Anwendung zurücksendet. Weitere Informationen finden Sie unter OAuth 2.0 für Webserveranwendungen verwenden.

Das folgende Diagramm zeigt die externe Authentifizierung mit der OAuth2-Methode.

Der Ablauf im Diagramm beginnt, wenn der Nutzer eine Anfrage zum Zugriff auf die Anwendung sendet. Anstatt direkt zu reagieren, leitet die Anwendung den Browser des Nutzers an die Google-Identitätsplattform weiter. Auf dieser Plattform wird dann eine Seite zur Anmeldung bei Google angezeigt. Nach erfolgreicher Anmeldung wird der Browser des Nutzers zurück zur Anwendung geleitet. Diese Anfrage enthält Informationen, mit denen die Anwendung Informationen über den nun authentifizierten Nutzer abrufen kann. Danach antwortet die Anwendung dem Nutzer.

Diese Methode bietet viele Vorteile für die Anwendung. Alle Kontoverwaltungsfunktionen und Risiken werden dabei an den externen Dienst delegiert. Dieser ist dann auch für die Verbesserung der Anmeldungs- und Kontosicherheit zuständig, die dort ohne Änderung der Anwendung vorgenommen werden kann. Allerdings muss die Anwendung bei dieser Methode Zugriff auf das Internet haben, wie im vorherigen Diagramm gezeigt. Darüber hinaus ist die Anwendung nach der Authentifizierung des Nutzers für die Verwaltung der Sitzungen verantwortlich.

Identity-Aware Proxy

Beim dritten der in dieser Anleitung behandelten Ansätze wird mit IAP die gesamte Authentifizierung und Sitzungsverwaltung mit etwaigen Änderungen an der Anwendung durchgeführt. IAP fängt alle Webanfragen an Ihre Anwendung ab, blockiert alle nicht authentifizierten Anfragen und leitet die anderen weiter, wobei Nutzeridentitätsdaten an jede Anfrage angefügt werden.

Die Verarbeitung von Anfragen wird im folgenden Diagramm gezeigt.

Anfragen von Nutzern werden von IAP abgefangen und nicht authentifizierte Anfragen werden blockiert. Authentifizierte Anfragen werden an die Anwendung weitergeleitet, wenn der authentifizierte Nutzer in der Liste der zugelassenen Nutzer enthalten ist. An die über IAP weitergeleiteten Anfragen werden Header angefügt, die den Nutzer identifizieren, der die Anfrage gestellt hat.

Die Anwendung muss dabei keine Informationen zu Nutzerkonten oder Sitzungen verarbeiten. Jeder Vorgang, der eine eindeutige Kennung für den Nutzer benötigt, kann diese direkt aus jeder eingehenden Webanfrage abrufen. Dieser Ansatz ist jedoch nur für Computing-Dienste möglich, die IAP unterstützen, beispielsweise App Engine und Load-Balancer. Sie können IAP nicht auf einem lokalen Entwicklungscomputer verwenden.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Nächste Schritte

• Hier finden Sie weitere Informationen zu IAP
• Sitzungen mit Firestore verarbeiten
• Hintergrundverarbeitung mit Pub/Sub and Cloud Run einrichten
• Anwendung in Compute Engine bereitstellen
• Anwendung in Google Kubernetes Engine bereitstellen