Last Mile Fleet Solution ist derzeit nur für ausgewählte Kunden verfügbar. Weitere Informationen erhalten Sie vom Vertrieb.

Diese Seite wurde von der Cloud Translation API übersetzt.

Authentifizierung und Autorisierung

In diesem Abschnitt werden die Konzepte der Authentifizierung und Autorisierung in Bezug auf die Einbindung in Fleet Engine erläutert.

Sie können die Funktionen der Last Mile Fleet Solution über die Google Cloud Console konfigurieren. Fleet Engine SDKs erfordern die Verwendung von JSON Web Tokens (JWTs), die von einem entsprechenden Dienstkonto signiert wurden.

Überblick

Kunden-Back-Ends zur Authentifizierung und Autorisierung bei Fleet Engine sollten die Standardmechanismen für Standardanmeldedaten für Anwendungen verwenden.

Fleet Engine erhält auch Aufrufe aus Umgebungen mit niedrigem Vertrauen wie Smartphones und Browsern. Zum Schutz der geheimen Dienstkontoschlüssel, die nur für vertrauenswürdige Umgebungen geeignet sind, wird von den Back-Ends der Kunden erwartet, dass sie signierte JSON Web Tokens (JWT) mit zusätzlichen, Fleet Engine-spezifischen Anforderungen generieren, die dann an nicht vertrauenswürdige Umgebungen wie Smartphones ausgegeben werden können.

Designprinzipien für die Authentifizierung

Der Authentifizierungsvorgang von Fleet Engine basiert auf den folgenden Designprinzipien.

IAM-Rollen definieren eine Reihe von Berechtigungen für Ressourcen, die für ein Hauptkonto zulässig sind. Die Admin-Rollen dürfen beispielsweise alles mit den Standardanmeldedaten für Anwendungen tun, während die Rolle „Nicht vertrauenswürdiger Fahrer*“ nur zum Aktualisieren des Fahrzeugstandorts berechtigt und auf die Verwendung von JWTs zur Authentifizierung und Autorisierung beschränkt ist.
In nicht vertrauenswürdigen Umgebungen schränken JWT-Anforderungen die Entitäten weiter ein, mit denen der Aufrufer arbeiten kann. Dabei kann es sich um bestimmte Aufgaben oder Lieferfahrzeuge handeln.
Der Code, der in einer Umgebung mit wenig Vertrauen ausgeführt wird, muss zuerst den Code aufrufen, der in einer vertrauenswürdigen Umgebung ausgeführt wird, um ein JWT auszugeben.
Fleet Engine führt bei API-Aufrufen für eine Ressource die folgenden Sicherheitsprüfungen durch:
1. Das aufrufende Hauptkonto hat (über Rollenzuweisung) die entsprechenden Berechtigungen für die Aktion für die Ressource.
2. Bei Nicht-Administratorrollen stellen die in der Anfrage übergebenen JWT-Anforderungen die erforderliche Berechtigung für die Ressource bereit.

Authentifizierungsvorgang

Im folgenden Sequenzdiagramm werden diese Details zum Authentifizierungsvorgang veranschaulicht.

Der Flottenadministrator erstellt Dienstkonten.
Der Flottenadministrator weist den Dienstkonten bestimmte IAM-Rollen zu.
Der Flottenadministrator konfiguriert sein Back-End mit den Dienstkonten und Standardanmeldedaten für Anwendungen.
Die Client-App fordert vom Kunden-Back-End ein JWT an. Der Anforderer kann die Treiber-, die Nutzer- oder eine Monitoring-App sein.
Das Back-End des Kunden signiert und gibt ein JWT für das jeweilige Dienstkonto aus. Die Client-App empfängt das JWT.
Die Clientanwendung verwendet das JWT, um eine Verbindung zu Fleet Engine herzustellen und Daten zu lesen oder zu ändern, je nachdem, welche IAM-Rollen ihr während der Einrichtungsphase zugewiesen wurden.

Sequenzdiagramm für die Authentifizierung

Cloud-Projekt einrichten

Erstellen Sie zuerst das Projekt und dann die Dienstkonten, um Ihr Cloud-Projekt einzurichten.

So erstellen Sie Ihr Google Cloud-Projekt:

Erstellen Sie mit der Google Cloud Console ein Google Cloud-Projekt.
Aktivieren Sie im Dashboard „APIs und Dienste“ die Local Rides and Deliveries API.

Dienstkonten und IAM-Rollen

Ein Dienstkonto ist eine spezielle Art von Konto, das von einer Anwendung und nicht von einer Person verwendet wird. In der Regel wird ein Dienstkonto zum Erstellen von JWTs verwendet, die je nach Rolle unterschiedliche Berechtigungen gewähren. Um das Risiko von Missbrauch zu verringern, können Sie mehrere Dienstkonten erstellen, jedes mit dem erforderlichen Mindestsatz an Rollen ().

Last Mile Fleet Solution verwendet die folgenden Rollen:

Rolle	Beschreibung
Nutzer von vertrauenswürdigen Treibern von Fleet Engine Delivery `roles/fleetengine.deliveryTrustedDriver`	Gewährt die Berechtigung zum Erstellen und Aktualisieren von Lieferfahrzeugen und -aufgaben, einschließlich der Aktualisierung des Standorts des Lieferfahrzeugs und des Aufgabenstatus oder ‐ergebnisses. Von einem Dienstkonto mit dieser Rolle geprägte Tokens werden in der Regel von den Mobilgeräten Ihres Zustellungstreibers oder von Ihren Back-End-Servern verwendet.
Nicht vertrauenswürdiger Treibernutzer für Fleet Engine Delivery `roles/fleetengine.deliveryUntrustedDriver`	Gewährt die Berechtigung zum Aktualisieren des Standorts des Lieferfahrzeugs. Von einem Dienstkonto mit dieser Rolle geprägte Tokens werden normalerweise von den Mobilgeräten Ihres Lieferfahrers verwendet.
Fleet Engine Delivery-Nutzer für Privatnutzer `roles/fleetengine.deliveryConsumer`	Gewährt die Berechtigung zum Suchen nach Aufgaben mithilfe einer Tracking-ID und zum Lesen, aber nicht aktualisieren von Aufgabeninformationen. Von einem Dienstkonto mit dieser Rolle erstellte Tokens werden normalerweise im Webbrowser eines Bereitstellungsnutzers verwendet.
Fleet Engine Delivery-Administrator `roles/fleetengine.deliveryAdmin`	Gewährt Lese- und Schreibberechtigungen für Bereitstellungsressourcen. Hauptkonten mit dieser Rolle müssen keine JWTs verwenden und sollten stattdessen Standardanmeldedaten für Anwendungen verwenden. Benutzerdefinierte JWT-Anforderungen werden ignoriert. Diese Rolle sollte auf vertrauenswürdige Umgebungen (Kunden-Back-End) beschränkt werden.
~~Fleet Engine Delivery-Superuser~~ (VERWORFEN) `roles/fleetengine.deliverySuperUser`	Gewährt Berechtigungen für alle APIs für Lieferfahrzeuge und -aufgaben. Von einem Dienstkonto mit dieser Rolle erstellte Tokens werden normalerweise von Ihren Back-End-Servern verwendet.
Leser von Fleet Engine Delivery-Flotten `roles/fleetengine.deliveryFleetReader`	Gewährt die Berechtigung zum Lesen von Lieferfahrzeugen und -aufgaben und zum Suchen nach Aufgaben mithilfe einer Tracking-ID. Von einem Dienstkonto mit dieser Rolle erstellte Tokens werden normalerweise über den Webbrowser eines Anbieters von Bereitstellungsflotten verwendet.

Organisationen, die ihren Lieferfahrern Geräte zur Verfügung stellen, die von der Unternehmens-IT verwaltet werden, können die Flexibilität der Fleet Engine Trusted Driver User-Rolle nutzen und einige oder alle Fleet Engine-Interaktionen in die mobile App integrieren.

Organisationen, die Richtlinien zum Verwenden eigener Geräte (Bring Your Own Device) unterstützen, sollten sich für die Sicherheit der Fleet Engine-Rolle „Nicht vertrauenswürdiger Fahrernutzer“ entscheiden und Updates zum Fahrzeugstandort nur über die mobile App an Fleet Engine senden. Alle anderen Interaktionen sollten von den Back-End-Servern des Kunden ausgehen.

Die Treiber und das Consumer SDK basieren auf diesen Standardrollen. Es ist jedoch möglich, benutzerdefinierte Rollen zu erstellen, mit denen ein beliebiger Satz von Berechtigungen gebündelt werden kann. Das Treiber- und das Consumer SDK zeigen Fehlermeldungen an, wenn eine erforderliche Berechtigung fehlt. Daher empfehlen wir dringend, anstelle von benutzerdefinierten Rollen den oben beschriebenen Standardsatz von Rollen zu verwenden.

Dienstkonto erstellen

Sie können ein Dienstkonto auf dem Tab IAM & Admin > Service Accounts in der Google Cloud Console erstellen. Wählen Sie in der Drop-down-Liste „Rolle“ die Option „Fleet Engine“ aus und weisen Sie dem Dienstkonto eine der Rollen zu. Es hat sich bewährt, das Konto anzugeben, das mit der jeweiligen Rolle verknüpft ist. Geben Sie dem Dienstkonto beispielsweise einen aussagekräftigen Namen.

Wenn Sie JWTs für nicht vertrauenswürdige Clients erstellen müssen, können Sie der Rolle „Service Account Token Creator“ Nutzer hinzufügen, um Tokens mit gcloud-Befehlszeilentools zu erstellen.

gcloud projects add-iam-policy-binding project-id \
       --member=user:my-user@example.com \
       --role=roles/iam.serviceAccountTokenCreator

Dabei ist my-user@example.com die E-Mail-Adresse, die für die Authentifizierung bei gcloud verwendet wird (gcloud auth list --format='value(account)').

Fleet Engine-Auth-Bibliothek

Fleet Engine verwendet JWTs, um den Zugriff auf Fleet Engine APIs in nicht vertrauenswürdigen Umgebungen einzuschränken. Die auf GitHub verfügbare Fleet Engine Auth Library vereinfacht das Erstellen von Fleet Engine-JWTs und signiert sie sicher.

Die Bibliothek bietet folgende Vorteile:

Vereinfacht das Erstellen von Fleet Engine-Tokens.
Stellt Tokensignaturmechanismen bereit, die keine Anmeldedatendateien verwenden (z. B. die Identität eines Dienstkontos).

JSON-Webtoken (JWT) für die Autorisierung erstellen

Wenn Sie die Fleet Engine Auth Library nicht verwenden, müssen JWTs direkt in Ihrer Codebasis erstellt werden. Dazu müssen Sie sowohl ein tiefes Verständnis der JWTs als auch deren Beziehung zu Fleet Engine haben. Aus diesem Grund empfehlen wir UNBEDINGT, die Fleet Engine Auth Library zu nutzen.

In Fleet Engine bieten JWTs eine kurzlebige Authentifizierung und sorgen dafür, dass Geräte nur Fahrzeuge oder Aufgaben ändern können, für die sie autorisiert sind. JWTs enthalten einen Header und einen Anforderungsabschnitt. Der Header-Abschnitt enthält Informationen wie den zu verwendenden privaten Schlüssel (von Dienstkonten abgerufen) und den Verschlüsselungsalgorithmus. Der Anforderungsabschnitt enthält Informationen wie den Erstellungszeitpunkt des Tokens, die Gültigkeitsdauer des Tokens, die Dienste, auf die das Token Zugriff beansprucht, sowie andere Autorisierungsinformationen zur Verkleinerung des Zugriffs, z. B. die ID des Lieferfahrzeugs.

Ein JWT-Header-Abschnitt enthält die folgenden Felder:

Field	Beschreibung
`alg`	Der zu verwendende Algorithmus. „RS256“.
`typ`	Der Tokentyp. „JWT“.
`kid`	Die private Schlüssel-ID Ihres Dienstkontos. Sie finden diesen Wert im Feld „private_key_id“ der JSON-Datei Ihres Dienstkontos. Achten Sie darauf, einen Schlüssel von einem Dienstkonto mit der richtigen Berechtigungsstufe zu verwenden.

Der Abschnitt für die JWT-Anforderungen enthält die folgenden Felder:

Field	Beschreibung
`iss`	Die E-Mail-Adresse Ihres Dienstkontos.
`sub`	Die E-Mail-Adresse Ihres Dienstkontos.
`aud`	Der SERVICE_NAME Ihres Dienstkontos, in diesem Fall https://fleetengine.googleapis.com/
`iat`	Der Zeitstempel für die Erstellung des Tokens, angegeben in Sekunden, die seit dem 1. Januar 1970 um 00:00:00 UTC (UTC) vergangen sind. Planen Sie 10 Minuten für die Verzerrung ein. Wenn der Zeitstempel zu weit in der Vergangenheit oder Zukunft liegt, meldet der Server möglicherweise einen Fehler.
`exp`	Der Zeitstempel für das Ablaufdatum des Tokens, angegeben in Sekunden, die seit dem 1. Januar 1970 um 00:00:00 UTC (UTC) vergangen sind. Die Anfrage schlägt fehl, wenn der Zeitstempel mehr als eine Stunde in der Zukunft liegt.
`authorization`	Kann je nach Anwendungsfall „deliveryvehicleid“, „trackingid“, „taskid“ oder „taskids“ enthalten.

Beim Erstellen eines JWT-Tokens wird es signiert. Eine Anleitung und Codebeispiele zum Erstellen und Signieren des JWT findest du unter Dienstkontoautorisierung ohne OAuth. Sie können dann ein Minted Token an gRPC-Aufrufe oder andere Methoden anhängen, die für den Zugriff auf Fleet Engine verwendet werden.

JWT-Anforderungen

Last Mile Fleet Solution verwendet private Anforderungen. Durch die Verwendung privater Anforderungen wird sichergestellt, dass nur autorisierte Clients auf ihre eigenen Daten zugreifen können. Wenn Ihr Back-End beispielsweise ein JSON Web Token für das Mobilgerät eines Lieferfahrers ausgibt, sollte dieses Token die deliveryvehicleid-Anforderung mit dem Wert der Lieferfahrzeug-ID dieses Fahrers enthalten. Je nach Fahrerrolle ermöglichen Tokens dann den Zugriff nur für die jeweilige zu übermittelnde Fahrzeug-ID und nicht für eine andere beliebige Fahrzeug-ID.

Last Mile Fleet Solution verwendet die folgenden privaten Anforderungen:

deliveryvehicleid: wird beim Aufrufen von APIs für Fahrzeuge pro Lieferung verwendet.
taskid: wird beim Aufrufen von APIs pro Aufgabe verwendet.
taskids: beim Aufrufen von BatchCreateTasksAPI verwenden. Diese Anforderung muss im Arrayformat vorliegen und das Array sollte alle Aufgaben-IDs enthalten, die zum Ausführen der Anfrage erforderlich sind. Füge keine delivervehicleid-, trackingid- oder taskid-Ansprüche hinzu.
trackingid: wird beim Aufrufen von GetTaskTrackingInfoAPI verwendet. Der Anspruch muss mit der Tracking-ID in der Anfrage übereinstimmen. Füge keine delivervehicleid-, taskid- oder taskids-Ansprüche hinzu.

Das Token muss auch die entsprechende Anforderung enthalten, wenn Sie APIs über Ihren Back-End-Server aufrufen. Sie können jedoch den speziellen Wert eines Sternchens ("*") für die Anforderungen deliveryvehicleid, taskid und trackingid verwenden. Das Sternchen ("*") kann auch in der taskids-Anforderung verwendet werden, muss aber das einzige Element im Array sein.

Wenn Sie eine JSON-Datei direkt als Token-Inhaber erstellen und signieren möchten, anstatt OAuth 2.0-Zugriffstokens zu verwenden, lesen Sie die Anleitung zur Dienstkonto-Autorisierung ohne OAuth in der Dokumentation für Identity Developer.

Der Mechanismus zum Anhängen des Tokens an einen gRPC-Aufruf hängt von der Sprache und dem Framework ab, die für den Aufruf verwendet werden. Der Mechanismus zum Angeben eines Tokens für einen HTTP-Aufruf besteht darin, einen Autorisierungsheader mit einem Inhabertoken einzubinden, dessen Wert das Token ist, wie in den Autorisierungshinweisen zu individuellen Anwendungsfällen für die Sendungsverfolgung oder die Flottenleistung beschrieben.

Das folgende Beispiel zeigt ein Token für einen Vorgang pro Aufgabe von Ihrem Back-End-Server:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskid": "*"
       }
    }

Das folgende Beispiel zeigt ein Token für einen Batch-Erstellungsvorgang für Aufgaben von Ihrem Back-End-Server:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskids": ["*"]
       }
    }

Das folgende Beispiel zeigt ein Token für einen Vorgang pro Lieferfahrzeug von Ihrem Back-End-Server:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "*"
       }
    }

Das folgende Beispiel zeigt ein Token für Endnutzerkunden:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_consumer_service_account"
    }
    .
    {
      "iss": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "sub": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "trackingid": "shipment_12345"
       }
    }

Das folgende Beispiel zeigt ein Token für Ihre Treiber-App:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_driver_service_account"
    }
    .
    {
      "iss": "driver@yourgcpproject.iam.gserviceaccount.com",
      "sub": "driver@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "driver_12345"
       }
    }

Geben Sie im Feld kid im Header die ID des privaten Schlüssels Ihres Dienstkontos an. Sie finden diesen Wert im Feld private_key_id der JSON-Datei Ihres Dienstkontos.
Geben Sie in den Feldern iss und sub die E-Mail-Adresse Ihres Dienstkontos an. Sie finden diesen Wert im Feld client_email der JSON-Datei Ihres Dienstkontos.
Geben Sie für das Feld aud https://SERVICE_NAME/ an.
Geben Sie für das Feld iat den Zeitstempel für die Erstellung des Tokens in Sekunden an, die seit dem 1. Januar 1970 um 00:00:00 UTC vergangen sind. Planen Sie 10 Minuten für Abweichungen ein. Wenn der Zeitstempel zu weit in der Vergangenheit oder Zukunft liegt, meldet der Server möglicherweise einen Fehler.
Geben Sie für das Feld exp den Zeitstempel in Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC an. Der empfohlene Wert ist iat + 3.600.

Verwenden Sie beim Signieren des Tokens, das an ein Mobilgerät oder einen Endnutzer übergeben werden soll, die Anmeldedatendatei für die Rolle „Delivery Driver“ oder „Consumer“. Andernfalls kann das Mobilgerät oder der Endnutzer Informationen ändern oder ansehen, auf die er keinen Zugriff haben sollte.