Rozwiązanie ostatniej mili jest obecnie dostępne tylko dla wybranych klientów. Aby dowiedzieć się więcej, skontaktuj się z zespołem sprzedaży.

Ta strona została przetłumaczona przez Cloud Translation API.

Uwierzytelnianie i autoryzacja

W tej sekcji omawiamy pojęcia uwierzytelniania i autoryzacji w zakresie integracji z Fleet Engine.

Możliwości udostępniane przez usługę Last Mile Fleet Solution możesz skonfigurować za pomocą Google Cloud Console. Pakiety SDK Fleet Engine wymaga użycia tokenów sieciowych JSON (JWT), które zostały podpisane przez odpowiednia Usługa Konto.

Omówienie

Backendy uwierzytelniania i autoryzacji klienta w usłudze Fleet Engine powinny używać standardowa Domyślna aplikacja Dane logowania i zbierania danych.

Fleet Engine odbiera też połączenia pochodzące ze środowisk o niskim stopniu zaufania takich jak smartfony i przeglądarki. Aby chronić tylko klucze obiektu tajnego konta usługi dla zaufanych środowisk, mają za zadanie wygenerować backendy podpisane tokeny sieciowe JSON (JWT) z dodatkowymi deklaracjami specyficznymi dla Fleet Engine które mogą zostać udostępnione w niezaufanych środowiskach, takich jak telefony komórkowe.

Zasady projektowania uwierzytelniania

Proces uwierzytelniania Fleet Engine obejmuje poniższe zasady projektowania.

Role uprawnień definiują zbiór uprawnień do zasobów dozwolonych dla podmiotu zabezpieczeń. Na przykład parametr Użytkownicy z rolą Administrator mogą robić wszystko, co jest związane z ustawieniem domyślnym aplikacji. dane logowania, a rola niezaufanego kierowcy* może być aktualizowana tylko lokalizacji pojazdu i tylko do uwierzytelniania za pomocą tokenów JWT. autoryzacji.
W przypadku niezaufanych środowisk deklaracja JWT jeszcze bardziej ogranicza encje, które rozmówca może działać. Mogą to być pojazdy dostawcze lub zadania do wykonywania określonych zadań.
Twój kod działający w środowisku o niskim poziomie zaufania musi najpierw wywołać działającego w zaufanym środowisku, aby wydać token JWT.
Fleet Engine wykonuje te kontrole zabezpieczeń wywołań interfejsu API dla zasób:
1. Podmiot wywołujący ma odpowiednie uprawnienia (przez rolę przypisanie) dla działania na zasobie.
2. W przypadku ról użytkowników bez uprawnień administracyjnych deklaracja JWT przekazana w żądaniu musi zawierać parametr uprawnień wymaganych do korzystania z zasobu.

Proces uwierzytelniania

Poniższy diagram sekwencji przedstawia szczegóły procesu uwierzytelniania.

Administrator floty tworzy konta usługi.
Administrator floty przypisuje do kont usługi określone role uprawnień.
Administrator floty konfiguruje backend z kontami usługi oraz domyślne dane uwierzytelniające aplikacji.
Aplikacja kliencka wysyła żądanie tokena JWT od backendu klienta. Osoba zgłaszająca może może to być aplikacja sterownika, aplikacja klienta lub aplikacja do monitorowania.
Backend klienta podpisuje i wydaje token JWT dla odpowiedniej usługi koncie. Aplikacja kliencka otrzymuje token JWT.
Aplikacja kliencka używa tokena JWT do łączenia się z Fleet Engine w celu odczytu lub modyfikacji w zależności od ról uprawnień przypisanych do nich podczas konfiguracji.

Schemat sekwencji uwierzytelniania

Konfigurowanie projektu Cloud

Aby skonfigurować projekt w chmurze, najpierw go utwórz, a potem tworzyć konta usługi.

Aby utworzyć projekt Google Cloud:

Utwórz projekt Google Cloud za pomocą konsoli Google Cloud.
W panelu interfejsów API i usług włącz Interfejs API Local Rides i Deliveries.

Konta usługi i Role uprawnień

Konto usługi to specjalne konto, które jest używane przez aplikację, a nie osobę. Zwykle konto usługi jest używane do tworzenia tokenów JWT, które przyznają różne i zestawy uprawnień w zależności od roli. Aby zmniejszyć możliwość nadużyć Możesz utworzyć wiele kont usługi, każde z minimalnym zestawem ról wymagane ().

Rozwiązanie Last Mile Fleet Solution wykorzystuje te role:

Rola	Opis
Użytkownik zaufanego sterownika Fleet Engine Delivery `roles/fleetengine.deliveryTrustedDriver`	Przyznaje uprawnienia do tworzenia i aktualizowania pojazdów dostawy i zadań w tym aktualizowanie lokalizacji pojazdu dostawy i stanu zadania lub wyniku. Tokeny wygenerowane przez konto usługi z tą rolą są zwykle używane z urządzenia mobilnego kierowcy lub z serwerów backendu.
Użytkownik niezaufanego sterownika Fleet Engine Delivery `roles/fleetengine.deliveryUntrustedDriver`	Przyznaje uprawnienia do aktualizowania lokalizacji pojazdu dostawy. Wygenerowane tokeny przez konto usługi z tą rolą są zwykle używane w ramach dostarczania urządzeń mobilnych sterowników.
Użytkownik indywidualny Fleet Engine Delivery `roles/fleetengine.deliveryConsumer`	Przyznaje uprawnienia do wyszukiwania zadań za pomocą identyfikatora śledzenia, oraz odczytywanie, ale nie aktualizowanie informacji o zadaniu. Wygenerowane tokeny dla konta usługi z tą rolą są zwykle używane z poziomu dostarczania przeglądarki konsumenta.
Administrator Fleet Engine Delivery `roles/fleetengine.deliveryAdmin`	Przyznaje uprawnienia do odczytu i zapisu zasobów dostarczania. Dyrektorzy z tą rolą nie muszą używać tokenów JWT. Zamiast tego powinna używać interfejsu Application Domyślne dane logowania. Niestandardowe żądania JWT są ignorowane. Ta rola powinna być ograniczona do zaufanych środowisk (backend klienta).
~~Superużytkownik Fleet Engine Delivery~~ (WYCOFANY) `roles/fleetengine.deliverySuperUser`	Przyznaje uprawnienia wszystkim interfejsom API pojazdów dostawczych i zadań. Wygenerowane tokeny przez konto usługi z tą rolą są zwykle używane z backendu serwerów.
Odczytujący informacje o flocie w usłudze Fleet Engine Delivery `roles/fleetengine.deliveryFleetReader`	Przyznaje uprawnienia do odczytu pojazdów dostawczych i zadań oraz do wyszukiwania za pomocą identyfikatora śledzenia. Tokeny wygenerowane przez konto usługi z tym kodem są zwykle używane w przeglądarce internetowej operatora floty dostarczającej.

Organizacje, które dostarczają kurierom urządzenia zarządzane przez korporacyjny dział IT może korzystać z elastyczności zapewnianej przez Fleet Engine rolę zaufanego sterownika i wybranie integracji niektórych lub wszystkich funkcji Fleet Engine. interakcje w aplikacji mobilnej.

Organizacje obsługujące zasady dotyczące posiadania własnego urządzenia powinny włączyć bezpieczeństwa roli użytkownika niezaufanego sterownika Fleet Engine i polegają wyłącznie na za pomocą aplikacji mobilnej do przesyłania aktualizacji lokalizacji pojazdu do Fleet Engine. Wszystkie pozostałe interakcje powinny pochodzić z serwerów backendu klienta.

Pakiety sterowników i pakietów SDK dla klientów indywidualnych opierają się na tych standardowych rolach. Można jednak tworzyć role niestandardowe. który pozwala połączyć dowolny zestaw uprawnień. Pakiety SDK sterowników i klientów będą wyświetlać komunikaty o błędach, gdy brakuje wymaganych uprawnień. Dlatego zdecydowanie zalecamy korzystając ze standardowego zestawu ról przedstawionych powyżej zamiast ról niestandardowych.

Tworzenie konta usługi

Konto usługi możesz utworzyć za pomocą IAM & Admin > Service Accounts w konsoli Google Cloud. Z listy Rola wybierz Fleet Engine i przypisz jedną z ról do konta usługi. Jest dobra aby wskazać konto powiązane z daną rolą. Na przykład nadaj kontu usługi rozpoznawalną nazwę.

Jeśli dla wygody musisz wygenerować tokeny JWT dla niezaufanych klientów, dodaj użytkowników z rolą twórcy tokenów konta usługi umożliwia tworzenie tokenów za pomocą narzędzi wiersza poleceń gcloud.

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

Gdzie my-user@example.com to adres e-mail używany do uwierzytelnić przy użyciu gcloud (gcloud auth list --format='value(account)').

Biblioteka uwierzytelniania Fleet Engine

Fleet Engine używa tokenów JWT do ograniczania dostępu do interfejsów Fleet Engine API w niezaufanych punktach w różnych środowiskach. Biblioteka uwierzytelniania Fleet Engine, dostępna od GitHub – upraszcza tworzenia tokenów JWT Fleet Engine i ich bezpiecznego podpisywania.

Biblioteka zapewnia te korzyści:

Upraszcza proces tworzenia tokenów Fleet Engine.
Zapewnia mechanizmy podpisywania tokenami inne niż pliki danych logowania (np. podszywa się pod konto usługi).

Tworzenie tokena internetowego JSON (JWT) na potrzeby autoryzacji

Jeśli nie używasz biblioteki uwierzytelniania Fleet Engine, tokeny JWT muszą być utworzone bezpośrednio w bazie kodu. Aby to zrobić, musisz mieć Omówienie tokenów JWT i ich związku z Fleet Engine. Dlatego Zdecydowanie zalecamy skorzystanie z biblioteki uwierzytelniania Fleet Engine.

Tokeny JWT w Fleet Engine zapewniają uwierzytelnianie krótkotrwałe i zapewniać, że urządzenia mogą modyfikować pojazdy lub zadania tylko w przypadku: do których ma upoważnienie. Tokeny JWT zawierają nagłówek i sekcję deklaracji. Sekcja nagłówka zawiera takie informacje jak: klucz prywatny do użycia (uzyskany z kont usługi) i szyfrowanie algorytmem bezpieczeństwa. Sekcja dotycząca roszczeń zawiera takie informacje jak: czas utworzenia tokena, czas życia tokena i usługi, z których on korzysta zgłaszania praw do informacji o dostępie i innych informacji dotyczących upoważnienia w zakresie ograniczonym dostęp; np. identyfikator pojazdu dostawy.

Sekcja nagłówka JWT zawiera te pola:

Pole	Opis
`alg`	Algorytm, który ma być używany. „RS256”.
`typ`	Typ tokena. JWT.
`kid`	Identyfikator klucza prywatnego konta usługi. Tę wartość znajdziesz w polu `private_key_id` pliku JSON konta usługi. Pamiętaj, aby użyć klucza z konta usługi o odpowiednim poziomie uprawnień.

Sekcja deklaracji JWT zawiera te pola:

Pole	Opis
`iss`	Adres e-mail konta usługi.
`sub`	Adres e-mail konta usługi.
`aud`	Twoje konto usługi to SERVICE_NAME, w tym przypadku https://fleetengine.googleapis.com/
`iat`	Sygnatura czasowa określająca, kiedy token został utworzony, wyrażony w sekundach. od godz. 00:00:00 czasu UTC, 1 stycznia 1970 r. Odczekaj 10 minut na zniekształcenie. Jeśli sygnatura czasowa jest zbyt odległa w przeszłości lub w przyszłości, serwer może zgłosić błąd.
`exp`	Sygnatura czasowa wygaśnięcia tokenu podana w sekundach od godz. 00:00:00 czasu UTC, 1 stycznia 1970 r. Żądanie nie powiedzie się, jeśli sygnatura czasowa to za więcej niż godzinę.
`authorization`	W zależności od przypadku użycia może zawierać „deliveryvehicleid”, „trackingid”, „taskid” lub „taskids”.

Tworzenie tokena JWT oznacza podpisanie go. Instrukcje i przykłady kodu dotyczące tworzenia i podpisywania tokena JWT znajdziesz tutaj Autoryzacja konta usługi bez protokołu OAuth. Następnie możesz dołączyć wygenerowany token do wywołań gRPC lub innych używanych metod aby uzyskać dostęp do Fleet Engine.

Żądania JWT

Last Mile Fleet Solution korzysta z prywatnych roszczeń. Używanie deklaracji prywatnych zapewnia, że tylko autoryzowani klienci mogą uzyskać dostęp do własnych danych. Jeśli na przykład Twój backend wystawi token internetowy JSON dla urządzenia mobilnego kierowcy, token ten powinien zawierają roszczenie deliveryvehicleid z wartością dostawy danego kierowcy. identyfikatora pojazdu. Następnie, w zależności od roli kierowcy, tokeny umożliwiają dostęp tylko identyfikator konkretnego pojazdu, a nie dowolny inny identyfikator pojazdu.

Usługa Last Mile Fleet Solution używa następujących deklaracji prywatnych:

deliveryvehicleid – należy używać w przypadku wywoływania interfejsów API wysyłanych do konkretnego pojazdu.
taskid – należy używać do wywoływania interfejsów API dla poszczególnych zadań.
taskids – użyj przy dzwonieniu pod numer BatchCreateTasksAPI. To roszczenie musi zostać w postaci tablicy, przy czym tablica powinna zawierać wszystkie identyfikatory zadań niezbędne do i wypełnić tę prośbę. Nie dodawaj wartości delivervehicleid, trackingid ani Roszczenia: taskid.
trackingid – należy używać w przypadku wywoływania funkcji GetTaskTrackingInfoAPI. Deklaracja musi zgodne z identyfikatorem śledzenia w żądaniu. Nie uwzględniaj wartości delivervehicleid, Roszczenia: taskid lub taskids.

Token musi też zawierać odpowiednią deklarację przy wywoływaniu interfejsów API z serwera backendu, ale możesz użyć specjalnej wartości gwiazdki („*”) w przypadku roszczeń deliveryvehicleid, taskid i trackingid. Gwiazdka („*”) może być również użyty w roszczeniu taskids, ale musi to być jedyny element w tablicy.

Jeśli chcesz utworzyć i podpisać plik JSON bezpośrednio jako nośnik tokenów, a nie używając tokenów dostępu OAuth 2.0, zapoznaj się z instrukcjami dla Autoryzacja konta usługi bez protokołu OAuth znajdziesz w dokumentacji Identity Developer.

Mechanizm dołączania tokena do wywołania gRPC zależy od języka i strukturę rozmowy. Mechanizm określania tokena do wywołania HTTP jest dołączenie nagłówka autoryzacji z tokenem okaziciela , której wartością jest token, zgodnie z uwagami dotyczącymi autoryzacji dla osób fizycznych śledzenie przesyłki lub skuteczność floty i przypadków użycia.

Poniższy przykład pokazuje token operacji na zadanie z poziomu serwer backendu:

    {
      "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": "*"
       }
    }

Poniższy przykład pokazuje token operacji zbiorczego tworzenia zadań na Twoim serwer backendu:

    {
      "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": ["*"]
       }
    }

Poniższy przykład pokazuje token operacji na pojazd w ramach dostawy z Twój serwer backendu:

    {
      "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": "*"
       }
    }

Poniższy przykład przedstawia token dla klientów-użytkowników:

    {
      "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"
       }
    }

Poniższy przykład przedstawia token aplikacji kierowcy:

    {
      "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"
       }
    }

W polu kid w nagłówku podaj prywatne dane konta usługi identyfikator klucza. Tę wartość znajdziesz w polu private_key_id na stronie plik JSON konta usługi.
W polach iss i sub podaj adres e-mail konta usługi. Tę wartość znajdziesz w polu client_email na koncie usługi Plik JSON.
W polu aud wpisz https://SERVICE_NAME/.
W polu iat podaj sygnaturę czasową utworzenia tokena, w sekundach, które upłynęły od godz. 00:00:00 czasu UTC, 1 stycznia 1970 r. Odczekaj 10 minut. dla zniekształcenia. Jeśli sygnatura czasowa przypada w zbyt odległej przeszłości lub przyszłości, serwer może zgłosić błąd.
W polu exp podaj sygnaturę czasową wygaśnięcia tokena, w sekundach od 00:00:00 czasu UTC, 1 stycznia 1970 r. Zalecana wartość to iat + 3600.

Podczas podpisywania tokena, który ma zostać przekazany do urządzenia mobilnego lub użytkownika, upewnij się, aby użyć pliku danych logowania w roli Kierowca dostarczania lub Konsument. W przeciwnym razie urządzenie mobilne lub użytkownik może zmieniać lub wyświetlać nie powinny mieć dostępu do tych informacji.