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 Fleet Engine-Implementierung erläutert. Darin werden die Verfahren beschrieben, die Sie zum Sichern Ihrer Fleet Engine-Funktionsaufrufe ausführen müssen.

Sie können die von der Last Mile Fleet Solution bereitgestellten Funktionen über die Google Cloud Console konfigurieren. Für diese APIs und SDKs müssen JSON Web Tokens (JWTs) verwendet werden, die mit Dienstkonten signiert wurden, die über die Cloud Console erstellt wurden.

Übersicht

Im Rahmen seines Autorisierungsmechanismus bietet Fleet Engine zusätzliche Sicherheit bei Aufrufen, die aus Umgebungen mit geringer Vertrauensbasis stammen. Zu den Zero-Trust-Umgebungen gehören Smartphones und Browser. Darüber hinaus verwendet Fleet Engine das Prinzip der geringsten Berechtigung, wobei ein Aufruf nur die Berechtigungen erhält, die zum Ausführen der Aufgabe erforderlich sind.

Zum Schutz von Funktionsaufrufen, die aus Umgebungen mit einer geringen Vertrauensstellung stammen, hat Google einen Mechanismus entwickelt, bei dem Ihr Code ein Token auf Ihrem Back-End-Server erstellt. Dies ist eine vollständig vertrauenswürdige Umgebung. Jeder Aufruf enthält eine vollständige Sicherheitsbeschreibung, die dann in einem JWT verschlüsselt wird, das Sie mit dem Aufruf aus einer beliebigen Umgebung übergeben.

Designprinzipien für die Authentifizierung

Der Authentifizierungsvorgang der Fleet Engine umfasst die folgenden Designprinzipien.

IAM-Rollen definieren den Bereich der zulässigen Aktivitäten für den Aufrufer. Beispielsweise kann die Rolle SuperNutzer alles tun, während die Rolle Nicht vertrauenswürdiger Treiber nur minimale Standortaktualisierungen ausführen darf.
IAM-Rollen sind Dienstkonten zugeordnet.
JWT-Anforderungen schränken die Entitäten, mit denen der Aufrufer arbeiten kann, weiter ein. Das können spezielle Aufgaben oder Lieferfahrzeuge sein.
An Fleet Engine gesendete Anfragen enthalten immer ein JWT.
- Da JWTs Dienstkonten zugeordnet sind, werden an Fleet Engine gesendete Anfragen implizit mit dem Dienstkonto verknüpft, das mit dem JWT verknüpft ist.
Um das entsprechende JWT anzufordern, das Sie dann an Fleet Engine übergeben können, muss Ihr Code, der in einer Umgebung mit niedriger Vertrauensstellung ausgeführt wird, zuerst Code in einer vollständig vertrauenswürdigen Umgebung aufrufen.
Fleet Engine führt die folgenden Sicherheitsprüfungen durch:
1. Mit dem Dienstkonto verknüpfte IAM-Rollen ermöglichen dem Aufrufer die korrekte Autorisierung zur Ausführung des API-Aufrufs.
2. Die JWT-Anforderungen, die in der Anfrage übergeben werden, stellen die richtige Autorisierung für den Aufruf der Entität bereit.

Authentifizierungsvorgang

Das folgende Sequenzdiagramm zeigt Details zum Authentifizierungsablauf.

Der Flottenadministrator erstellt Dienstkonten.
Der Flottenadministrator weist den Dienstkonten bestimmte IAM-Rollen zu.
Der Flottenadministrator konfiguriert sein Back-End mit den Dienstkonten.
Die Client-App fordert ein JWT vom Back-End des Partners an. Der Anfragende kann die Driver-App, die Consumer-App oder eine Monitoring-App sein.
Fleet Engine gibt ein JWT für das entsprechende Dienstkonto aus. Die Clientanwendung empfängt das JWT.
Die Client-App verwendet das JWT, um eine Verbindung zu Fleet Engine zum Lesen oder Ändern von Daten herzustellen, abhängig von den IAM-Rollen, die ihm während der Einrichtung zugewiesen wurden.

Diagramm: Authentifizierungssequenz

Cloud-Projekt einrichten

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

So erstellen Sie ein Google Cloud-Projekt:

Erstellen Sie ein Google Cloud-Projekt mit der Google Cloud Console.
Aktivieren Sie über das Dashboard für 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 verwendet, um JWTs zu erstellen, die abhängig von der Rolle unterschiedliche Berechtigungen gewähren. Um Missbrauch zu verhindern, können Sie mehrere Dienstkonten mit den erforderlichen Mindestrollen erstellen.

Die Lösung für die letzte Flotte verwendet die folgenden Rollen:

Rolle	Beschreibung
Vertrauenswürdiger Treiber für die Fleet Engine Delivery `roles/fleetengine.deliveryTrustedDriver`	Berechtigung zum Erstellen und Aktualisieren von Lieferfahrzeugen und -aufgaben, einschließlich Aktualisierung des Lieferorts und des Aufgabenstatus oder -ergebnisses. Tokens, die von einem Dienstkonto mit dieser Rolle erstellt werden, werden normalerweise von den Mobilgeräten Ihres Bereitstellungstreibers oder von Ihren Back-End-Servern verwendet.
Nicht vertrauenswürdiger Fleet Engine Delivery-Treiber `roles/fleetengine.deliveryUntrustedDriver`	Berechtigung zum Aktualisieren des Lieferorts des Fahrzeugs. Tokens, die von einem Dienstkonto mit dieser Rolle erstellt werden, werden in der Regel von den Mobilgeräten des Zustellungstreibers verwendet.
Nutzer von Fleet Engine Delivery-Nutzern `roles/fleetengine.deliveryConsumer`	Gewährt die Berechtigung, nach Aufgaben mit einer Tracking-ID zu suchen und Aufgabeninformationen zu lesen, aber nicht zu aktualisieren. Tokens, die von einem Dienstkonto mit dieser Rolle erstellt werden, werden normalerweise im Webbrowser eines Bereitstellungsnutzers verwendet.
Fleet Engine Delivery-Superuser `roles/fleetengine.deliverySuperUser`	Gewährt Berechtigungen für alle APIs für Lieferfahrzeuge und Aufgaben. Tokens, die von einem Dienstkonto mit dieser Rolle erstellt werden, werden normalerweise von Ihren Back-End-Servern verwendet.
Leser für den Flottenversand von Fleet Engine `roles/fleetengine.deliveryFleetReader`	Berechtigung zum Lesen von Lieferfahrzeugen und -aufgaben sowie zum Suchen nach Aufgaben mithilfe einer Tracking-ID. Tokens, die von einem Dienstkonto mit dieser Rolle erstellt werden, werden normalerweise im Webbrowser eines Flottenbetreibers verwendet.

Organisationen, die ihre Bereitstellungstreiber mit Geräten ausstatten, die von der Unternehmens-IT verwaltet werden, können die Flexibilität der Rolle des vertrauenswürdigen Treibers für Fleet Engine nutzen und sich dafür entscheiden, einige oder alle Fleet Engine-Interaktionen in die mobile App zu integrieren.

Organisationen, die BYOL-Richtlinien (Bring Your Own Device) unterstützen, sollten sich für die Sicherheit der Rolle des nicht vertrauenswürdigen Fleet Engine-Nutzers der Fleet Engine entscheiden und sich nur auf die mobile App verlassen, um Updates zum Fahrzeugstandort an Fleet Engine zu senden. Alle anderen Interaktionen sollten von den Kunden-Back-End-Servern stammen.

Die Treiber- und Nutzer-SDKs basieren auf diesen Standardrollen. Es ist jedoch möglich, benutzerdefinierte Rollen zu erstellen, mit denen beliebige Berechtigungen zusammengefasst werden können. Die Treiber- und Nutzer-SDKs zeigen Fehlermeldungen an, wenn eine erforderliche Berechtigung fehlt. Daher empfehlen wir dringend, den oben aufgeführten Standardrollensatz anstelle von benutzerdefinierten Rollen zu verwenden.

Dienstkonto erstellen

Sie können ein Dienstkonto in der Google Cloud Console auf dem Tab IAM & Admin > Service Accounts 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 empfiehlt sich, das Konto anzugeben, das mit jeder 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 Einfachheit halber Tokens für Dienstkonto-Tokens mit gcloud-Befehlszeilentools 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 für die Authentifizierung bei gcloud (gcloud auth list --format='value(account)').

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

In Fleet Engine bieten JWTs eine kurzlebige Authentifizierung und sorgen dafür, dass Geräte nur Fahrzeuge oder Aufgaben ändern dürfen, für die sie autorisiert sind. JWTs enthalten einen Header und einen Anspruchsabschnitt. Der Header-Abschnitt enthält Informationen wie den zu verwendenden privaten Schlüssel (entnommen aus Dienstkonten) und den Verschlüsselungsalgorithmus. Der Anspruchsabschnitt enthält Informationen wie die Erstellungszeit des Tokens, die Gültigkeitsdauer des Tokens, die Dienste, auf die das Token den Zugriff anfordert, und andere Autorisierungsinformationen, um den Zugriff einzuschränken, z. B. die Lieferfahrzeug-ID.

Ein Abschnitt des JWT-Headers enthält die folgenden Felder:

Feld	Beschreibung
alg	Der zu verwendende Algorithmus. „RS256“.
Typ	Der Typ des Tokens. „JWT“.
Kind	Die private Schlüssel-ID Ihres Dienstkontos. Sie finden diesen Wert im Feld „private_key_id“ der JSON-Datei Ihres Dienstkontos. Achten Sie darauf, dass Sie einen Schlüssel aus einem Dienstkonto mit der richtigen Berechtigungsstufe verwenden.

Ein Abschnitt mit JWT-Ansprüchen enthält die folgenden Felder:

Feld	Beschreibung
iss	Die E-Mail-Adresse Ihres Dienstkontos.
sub	Die E-Mail-Adresse Ihres Dienstkontos.
aud	SERVICE_NAME Ihres Dienstkontos, in diesem Fall https://fleetengine.googleapis.com/
iat	Zeitstempel für die Erstellung des Tokens, angegeben in Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC Warten Sie 10 Minuten. Wenn der Zeitstempel zu weit in der Vergangenheit oder in der Zukunft liegt, meldet der Server möglicherweise einen Fehler.
exp	Der Zeitstempel, wenn das Token abläuft, angegeben in Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC. Die Anfrage schlägt fehl, wenn der Zeitstempel mehr als eine Stunde in der Zukunft liegt.
authorization	Je nach Anwendungsfall können „deliveryvehicleid“, „trackingid“, „taskid“ oder „taskids“ enthalten sein.

Beim Minieren eines JWT-Tokens wird es signiert. Eine Anleitung und Codebeispiele zum Erstellen und Signieren des JWT finden Sie unter Dienstkontoautorisierung ohne OAuth. Sie können dann ein gRPC-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 Ansprüche. Durch die Verwendung privater Ansprüche wird gewährleistet, dass nur autorisierte Clients auf ihre eigenen Daten zugreifen können. Wenn Ihr Back-End beispielsweise ein JSON-Webtoken für das Mobilgerät eines Zustellers ausgibt, sollte dieses Token die Anforderung deliveryvehicleid mit dem Wert der Zustellfahrzeug-ID dieses Treibers enthalten. Je nach Treiberrolle ermöglichen Tokens dann nur den Zugriff für die spezifische Lieferfahrzeug-ID und nicht für eine andere beliebige Fahrzeug-ID.

Die Lösung für die letzte Flotte verwendet die folgenden privaten Ansprüche:

deliveryvehicleid: wird beim Aufrufen von APIs pro Fahrzeug aufgerufen.
taskid: wird beim Aufrufen von aufgabenspezifischen APIs verwendet.
taskids: wird beim Aufrufen von BatchCreateTasksAPI verwendet. Diese Anforderung muss in Arrayform vorliegen und das Array sollte alle Aufgaben-IDs enthalten, die zum Abschließen der Anfrage erforderlich sind. Fügen Sie keine delivervehicleid-, trackingid- oder taskid-Ansprüche ein.
trackingid: wird beim Aufrufen von SearchTasksAPI verwendet. Der Anspruch muss mit der Tracking-ID in der Anfrage übereinstimmen. Fügen Sie keine delivervehicleid-, taskid- oder taskids-Ansprüche ein.

Das Token muss auch die entsprechende Anforderung enthalten, wenn Sie APIs von Ihrem Back-End-Server aufrufen. Sie können jedoch den speziellen Wert eines Sternchens ("*") für deliveryvehicleid-, taskid- und trackingid-Ansprüche 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 Tokeninhaber erstellen und signieren möchten, anstatt OAuth 2.0-Zugriffstokens zu verwenden, lesen Sie die Anleitung für die Dienstkontoautorisierung{.external} 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, das für den Aufruf verwendet wird. Ein Mechanismus zum Angeben eines Tokens für einen HTTP-Aufruf besteht darin, einen Autorisierungsheader mit einem Inhabertoken aufzunehmen, dessen Wert das Token ist, wie in den Autorisierungshinweisen für einzelne Anwendungsfälle der Versandverfolgung oder Flottenleistung angegeben.

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 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 Fahrzeug 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 Endnutzer:

    {
      "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 Treiberanwendung:

    {
      "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 private Schlüssel-ID 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 im Feld aud https://SERVICE_NAME/ an.
Geben Sie im Feld iat den Zeitstempel für die Erstellung des Tokens in Sekunden an, die seit 1. Januar 1970 um 00:00:00 UTC verstrichen sind. Warten Sie 10 Minuten. Wenn der Zeitstempel zu weit in der Vergangenheit oder in der Zukunft liegt, meldet der Server möglicherweise einen Fehler.
Geben Sie im Feld exp den Zeitstempel nach Ablauf des Tokens in Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC an. Der empfohlene Wert ist iat + 3600.

Wenn Sie das Token signieren, das an ein Mobilgerät oder einen Endnutzer übergeben werden soll, müssen Sie die Datei mit den Anmeldedaten für die Rolle „Zusteller“ oder „Nutzer“ verwenden. Andernfalls können Mobilgeräte oder Endnutzer Informationen ändern oder aufrufen, auf die sie keinen Zugriff haben.