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 kontekście integracji z Fleet Engine.

Funkcje udostępniane przez usługę Last Mile Fleet Solution możesz konfigurować za pomocą konsoli Google Cloud. Pakiety SDK Fleet Engine wymagają użycia tokenów sieciowych JSON (JWT), które zostały podpisane przez odpowiednie konto usługi.

Przegląd

Backendy klienta dokonujące uwierzytelniania i autoryzacji we Fleet Engine powinny używać standardowych mechanizmów domyślnych danych logowania aplikacji.

Fleet Engine odbiera też połączenia pochodzące ze środowisk o niskim stopniu zaufania, takich jak smartfony i przeglądarki. Aby chronić tajne klucze konta usługi, które są odpowiednie tylko w zaufanych środowiskach, backendy klientów muszą generować podpisane tokeny sieciowe JSON (JWT) z dodatkowymi deklaracjami specyficznymi dla Fleet Engine, które można następnie wydawać do niezaufanych środowisk, takich jak telefony komórkowe.

Zasady projektowania uwierzytelniania

Proces uwierzytelniania Fleet Engine obejmuje poniższe zasady projektowania.

Role uprawnień określają zbiór uprawnień dotyczących zasobów dozwolonych dla podmiotu zabezpieczeń. Na przykład role administratora mogą wykonywać wszystkie czynności z domyślnymi danymi uwierzytelniającymi aplikacji, podczas gdy rola niezaufanego kierowcy* może aktualizować lokalizację pojazdu, a jedynie używać tokenów JWT do uwierzytelniania i autoryzacji.
W przypadku niezaufanych środowisk deklaracja JWT jeszcze bardziej ogranicza encje, na których wywołujący 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ć swój kod działający w zaufanym środowisku, aby wysłać token JWT.
Fleet Engine wykonuje te kontrole zabezpieczeń wywołań interfejsu API zasobu:
1. Podmiot zabezpieczeń wywołujący ma odpowiednie uprawnienia (poprzez przypisanie roli) do wykonania działania na zasobie.
2. W przypadku ról użytkowników bez uprawnień administracyjnych żądania JWT przekazywane w żądaniu zapewniają niezbędne uprawnienia do 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 przy użyciu kont usługi i domyślnych danych logowania aplikacji.
Aplikacja kliencka wysyła żądanie tokena JWT od backendu klienta. Może to być aplikacja sterownika, aplikacja konsumenta lub aplikacja do monitorowania.
Backend klienta podpisuje i wydaje token JWT dla odpowiedniego konta usługi. Aplikacja kliencka otrzymuje token JWT.
Aplikacja kliencka używa tokena JWT, aby połączyć się z Fleet Engine i odczytywać lub modyfikować dane w zależności od ról uprawnień przypisanych do niej podczas konfiguracji.

Schemat sekwencji uwierzytelniania

Konfigurowanie projektu Cloud

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

Aby utworzyć projekt Google Cloud:

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

Konta usługi i role uprawnień

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

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 do aktualizowania lokalizacji pojazdu dostawy i stanu lub wyniku zadania. Tokeny wygenerowane przez konto usługi z tą rolą są zwykle używane z urządzeń mobilnych kierowcy lub z serwerów backendu.
Użytkownik niezaufanego sterownika Fleet Engine Delivery `roles/fleetengine.deliveryUntrustedDriver`	Przyznaje uprawnienia do aktualizowania lokalizacji pojazdu dostawy. Tokeny generowane przez konto usługi z tą rolą są zwykle używane z urządzeń mobilnych dostawcy.
Użytkownik klienta Fleet Engine Delivery `roles/fleetengine.deliveryConsumer`	Przyznaje uprawnienia do wyszukiwania zadań przy użyciu identyfikatora śledzenia oraz do odczytu informacji o zadaniach, ale nie do ich aktualizowania. Tokeny wygenerowane przez konto usługi z tą rolą są zwykle używane w przeglądarce konsumenta dostawcy.
Administrator Fleet Engine Delivery `roles/fleetengine.deliveryAdmin`	Przyznaje uprawnienia do odczytu i zapisu zasobów dostarczania. Podmioty zabezpieczeń z tą rolą nie muszą używać tokenów JWT i powinny używać domyślnych danych logowania aplikacji. Niestandardowe żądania JWT są ignorowane. Ta rola powinna być ograniczona do zaufanych środowisk (backendu klienta).
~~Superużytkownik Fleet Engine Delivery~~ (WYCOFANY) `roles/fleetengine.deliverySuperUser`	Przyznaje uprawnienia wszystkim interfejsom API pojazdów dostawczych i zadań. Tokeny wygenerowane przez konto usługi z tą rolą są zwykle używane z serwerów backendu.
Odczytujący informacje o flocie w usłudze Fleet Engine Delivery `roles/fleetengine.deliveryFleetReader`	Przyznaje uprawnienia do odczytu pojazdów dostawy i zadań oraz do wyszukiwania zadań za pomocą identyfikatora śledzenia. Tokeny wygenerowane przez konto usługi z tą rolą są zwykle używane przez przeglądarkę internetową operatora floty dostarczającej.

Organizacje, które dysponują urządzeniami zarządzanymi przez firmowe działy IT, mogą korzystać z elastyczności, jaką zapewnia rola zaufanego kierowcy w Fleet Engine, i zdecydować się na zintegrowanie niektórych lub wszystkich interakcji Fleet Engine z aplikacją mobilną.

Organizacje obsługujące zasady dotyczące posiadania własnego urządzenia powinny wybrać bezpieczeństwo roli użytkownika niezaufanego sterownika w Fleet Engine i polegać na aplikacji mobilnej wyłącznie do wysyłania aktualizacji lokalizacji pojazdu do Fleet Engine. Wszystkie inne 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 utworzyć role niestandardowe, które umożliwiają połączenie dowolnego zestawu uprawnień. Gdy brakuje wymaganego uprawnienia, pakiety SDK sterowników i klientów będą wyświetlać komunikaty o błędach. Dlatego zdecydowanie zalecamy korzystanie ze standardowego zestawu ról przedstawionych powyżej zamiast ról niestandardowych.

Tworzenie konta usługi

Konto usługi możesz utworzyć na karcie IAM & Admin > Service Accounts w konsoli Google Cloud. Z listy Rola wybierz Fleet Engine i przypisz jedną z ról do konta usługi. Warto wskazać konto powiązane z poszczególnymi rolami. Na przykład nadaj kontu usługi rozpoznawalną nazwę.

Jeśli musisz tworzyć tokeny JWT dla niezaufanych klientów, możesz dodać użytkowników do roli twórcy tokenów konta usługi, aby mogli tworzyć tokeny 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 uwierzytelniania w gcloud (gcloud auth list --format='value(account)').

Biblioteka uwierzytelniania Fleet Engine

Fleet Engine używa tokenów JWT, aby ograniczyć dostęp do interfejsów Fleet Engine API w niezaufanych środowiskach. Biblioteka uwierzytelniania Fleet Engine, dostępna w GitHubie, upraszcza tworzenie tokenów JWT Fleet Engine i bezpieczne ich podpisywanie.

Biblioteka zapewnia te korzyści:

Upraszcza proces tworzenia tokenów Fleet Engine.
Udostępnia mechanizmy podpisywania tokenów inne niż korzystające z plików danych logowania (np. podszywanie 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ć tworzone bezpośrednio w bazie kodu. Wymaga to dogłębnej wiedzy o tokenach JWT i ich związku z Fleet Engine. Dlatego Zdecydowanie zalecamy skorzystanie z biblioteki uwierzytelniania Fleet Engine.

We Fleet Engine tokeny JWT pozwalają na uwierzytelnianie przez krótki czas i sprawiają, że urządzenia mogą modyfikować wyłącznie pojazdy lub zadania, do których są uprawnione. Tokeny JWT zawierają nagłówek i sekcję deklaracji. Sekcja nagłówka zawiera informacje takie jak klucz prywatny do użycia (uzyskany z kont usługi) i algorytm szyfrowania. Sekcja deklaracji zawiera informacje takie jak czas utworzenia tokena, czas życia tokena, usługi, do których token odbiera dostęp, i inne informacje dotyczące autoryzacji w zakresie ograniczonego dostępu, 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.
dziecko	Identyfikator klucza prywatnego konta usługi. Tę wartość znajdziesz w polu `private_key_id` w 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.
zast.	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żona w sekundach, które upłynęły od 00:00:00 czasu UTC, 1 stycznia 1970 r. Odczekaj 10 minut na zniekształcenie. Jeśli sygnatura czasowa przypada w zbyt odległej przeszłości lub w przyszłości, serwer może zgłosić błąd.
exp	Sygnatura czasowa wygaśnięcia tokena podana w sekundach, które upłynęły od 00:00:00 czasu UTC, 1 stycznia 1970 r. Żądanie nie zostanie zrealizowane, jeśli sygnatura czasowa będzie wybiegać więcej niż godzinę w przyszłość.
autoryzacja	W zależności od przypadku użycia może zawierać parametr „deliveryvehicleid”, „trackingid”, „taskid” lub „taskids”.

Tworzenie tokena JWT oznacza podpisanie go. Instrukcje i przykłady kodu umożliwiające tworzenie i podpisywanie tokena JWT znajdziesz w artykule Autoryzacja konta usługi bez OAuth. Następnie możesz dołączyć wygenerowany token do wywołań gRPC lub innych metod używanych do uzyskiwania dostępu do Fleet Engine.

Żądania JWT

Last Mile Fleet Solution korzysta z prywatnych roszczeń. Użycie deklaracji prywatnych gwarantuje, że tylko autoryzowani klienci mają dostęp do własnych danych. Jeśli na przykład Twój backend wyda token internetowy JSON dla urządzenia mobilnego kierowcy, token ten powinien zawierać deklarację deliveryvehicleid z wartością identyfikatora pojazdu dostawy danego kierowcy. Następnie, w zależności od roli kierowcy, tokeny umożliwiają dostęp tylko w przypadku konkretnego identyfikatora pojazdu dostarczanego, a nie dowolnego innego identyfikatora 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. Deklaracja musi mieć postać tablicy i powinna zawierać wszystkie identyfikatory zadań niezbędne do wykonania żądania. Nie dodawaj roszczeń typu delivervehicleid, trackingid ani taskid.
trackingid – należy używać w przypadku wywoływania funkcji GetTaskTrackingInfoAPI. Deklaracja musi odpowiadać identyfikatorowi śledzenia w żądaniu. Nie uwzględniaj roszczeń delivervehicleid, taskid ani taskids.

Token musi też zawierać odpowiednią deklarację, gdy wywołujesz interfejsy API z serwera backendu, ale w przypadku żądań deliveryvehicleid, taskid i trackingid możesz użyć specjalnej wartości gwiazdki („*”). Gwiazdki („*”) można też użyć w deklaracji taskids, ale musi ona być jedynym elementem tablicy.

Jeśli chcesz utworzyć i podpisać plik JSON bezpośrednio jako nośnik tokenów, zamiast używać tokenów dostępu OAuth 2.0, zapoznaj się z instrukcjami uwierzytelniania konta usługi bez OAuth w dokumentacji Identity Developer.

Mechanizm dołączania tokena do wywołania gRPC zależy od języka i platformy użytej do wywołania. Mechanizmem określania tokena dla wywołania HTTP jest dołączenie nagłówka autoryzacji z tokenem okaziciela, którego wartością jest token, zgodnie z uwagami do autoryzacji dla poszczególnych przypadków użycia śledzenia przesyłek lub wydajności floty.

Poniższy przykład pokazuje token z serwera backendu dla operacji wykonywanej na poziomie zadania:

    {
      "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 tworzenia zadań wsadowych na serwerze 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 pojazdach z serwera 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 identyfikator klucza prywatnego konta usługi. Tę wartość znajdziesz w polu private_key_id w pliku JSON konta usługi.
W polach iss i sub podaj adres e-mail konta usługi. Tę wartość znajdziesz w polu client_email w pliku JSON konta usługi.
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. Zaczekaj 10 minut. Jeśli sygnatura czasowa przypada w zbyt odległej przeszłości lub w 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.

Podpisując token, który ma być przekazany do urządzenia mobilnego lub użytkownika, pamiętaj, aby użyć pliku danych logowania w roli Kierowca dostarczania lub Konsument. W przeciwnym razie urządzenie mobilne lub użytkownik będzie mogło zmieniać lub wyświetlać informacje, do których nie powinien mieć dostępu.