Por el momento, la solución para flotas de último tramo solo está disponible para determinados clientes. Comunícate con Ventas para obtener más información.

Se usó la API de Cloud Translation para traducir esta página.

Autenticación y autorización

En esta sección, se explican los conceptos de autenticación y autorización con respecto a la integración en Fleet Engine.

Puedes configurar las capacidades que proporciona la solución de flota de red de acceso a través de la consola de Google Cloud. SDKs de Fleet Engine requieren el uso de tokens web JSON (JWT) firmados por un los servicios de Cuenta.

Descripción general

Los backends del cliente que se autentican y autorizan en Fleet Engine deben usar estándar predeterminada de la aplicación Credenciales con mecanismos de control de acceso clave.

Fleet Engine también recibe llamadas que se originan en entornos de baja confianza como smartphones y navegadores. Para proteger solo las claves secretas de cuentas de servicio adecuada para entornos de confianza, las necesidades los backends generarán Tokens web JSON (JWT) firmados con reclamaciones adicionales específicas de Fleet Engine que luego se pueden enviar a entornos no confiables, como teléfonos celulares.

Principios del diseño de autenticación

El flujo de autenticación de Fleet Engine incorpora los siguientes principios de diseño.

Los roles de IAM definen un conjunto de permisos sobre los recursos permitidos para una principal. Por ejemplo, el Los roles de Administrador tienen permitido realizar todas las acciones con la Configuración predeterminada de la aplicación Credenciales, mientras que el rol de controlador no confiable* solo puede actualizar la ubicación del vehículo y se restringe a usar JWT para la autenticación y autorización.
Para los entornos que no son de confianza, las reclamaciones de JWT restringen aún más las entidades a las que puede operar el llamador. Pueden ser tareas o vehículos de entrega específicos.
El código que se ejecuta en un entorno de baja confianza primero debe llamar a código que se ejecuta en un entorno de confianza para emitir un JWT.
Fleet Engine realiza los siguientes controles de seguridad en las llamadas a la API para un recurso:
1. La principal que realiza la llamada tiene los permisos adecuados (a través del rol asignación) para la acción en el recurso.
2. Para los roles que no son de administrador, los reclamos de JWT pasados en la solicitud proporcionan el el permiso necesario para el recurso.

Flujo de autenticación

En el siguiente diagrama de secuencias, se muestran los detalles del flujo de autenticación.

El administrador de la flota crea cuentas de servicio.
El administrador de la flota asigna roles específicos de IAM a las cuentas de servicio.
El administrador de la flota configura su backend con las cuentas de servicio y las credenciales predeterminadas de la aplicación.
La app cliente solicita un JWT al backend del cliente. El solicitante podría ser la app de Driver, la app de Consumidores o una app de monitoreo.
El backend del cliente firma y emite un JWT para el servicio correspondiente de servicio predeterminada. La app cliente recibe el JWT.
La app cliente usa el JWT para conectarse a Fleet Engine para leer o modificar en función de los roles de IAM que se le asignaron durante la fase de configuración.

Diagrama de secuencia de autenticación

Configuración del proyecto de Cloud

Para configurar tu proyecto de la nube, primero créalo y, luego, crear cuentas de servicio.

Para crear tu proyecto de Google Cloud, sigue estos pasos:

Crea un proyecto de Google Cloud con la consola de Google Cloud.
Con el panel de APIs y servicios, habilita la API de Local Rides and Deliveries.

Cuentas de servicio y Roles de IAM

Una cuenta de servicio es una tipo de cuenta especial que utiliza una aplicación, en lugar de una persona. Por lo general, se usa una cuenta de servicio para acuñar JWT que otorguen distintos conjuntos de permisos según el rol. Para reducir la posibilidad de abuso puedes crear varias cuentas de servicio, cada una con el conjunto mínimo de roles obligatorio ().

La solución de flota de red de acceso usa los siguientes roles:

Rol	Descripción
Usuario de controlador confiable de entrega de Fleet Engine `roles/fleetengine.deliveryTrustedDriver`	Otorga permiso para crear y actualizar vehículos y tareas de entrega. incluida la actualización de la ubicación del vehículo de entrega y el estado de la tarea o resultado. Tokens emitidos por una cuenta de servicio con este rol se suelen usar desde los dispositivos móviles del repartidor de tus servidores de backend.
Usuario de controlador no confiable de entrega de Fleet Engine `roles/fleetengine.deliveryUntrustedDriver`	Otorga permiso para actualizar la ubicación del vehículo de entrega. Tokens acuñados que una cuenta de servicio con este rol se usan, por lo general, desde tu entrega los dispositivos móviles del conductor.
Usuario consumidor de entrega de Fleet Engine `roles/fleetengine.deliveryConsumer`	Otorga permiso para buscar tareas mediante un ID de seguimiento. y leer, pero no actualizar la información de la tarea. Tokens acuñados por una cuenta de servicio con este rol se suelen usar desde un proveedor de navegador web del consumidor.
Administrador de entrega de Fleet Engine `roles/fleetengine.deliveryAdmin`	Otorga permisos de lectura y escritura para los recursos de entrega. Principales con este rol, no necesitan usar JWT y, en su lugar, deben usar Application Credenciales predeterminadas. Se ignoran las reclamaciones personalizadas de JWT. Este rol debe ser restringidas a entornos de confianza (backend del cliente).
~~Superusuario de entrega de Flet Engine~~ (OBSOLETO) `roles/fleetengine.deliverySuperUser`	Otorga permiso a todas las APIs de vehículos y tareas de entrega. Tokens acuñados que una cuenta de servicio con este rol se usan, por lo general, desde tu backend servidores.
Lector de flota de entrega de Fleet Engine `roles/fleetengine.deliveryFleetReader`	Otorga permiso para leer tareas y vehículos de entrega, y buscar tareas con un ID de seguimiento. Tokens emitidos por una cuenta de servicio con esto se usan normalmente desde el navegador web de un operador de flota de reparto.

Organizaciones que equipan a sus repartidores con dispositivos administrados por la TI corporativa puede aprovechar la flexibilidad que ofrece Fleet Engine Rol de usuario de controlador de confianza y optar por integrar parte de la infraestructura de Fleet Engine o parte de ella las interacciones en la aplicación para dispositivos móviles.

Las organizaciones que admiten las políticas Bring Your Own Device deben optar por la del rol de usuario de controlador no confiable de Fleet Engine y solo depender de para enviar actualizaciones sobre la ubicación de los vehículos a Fleet Engine. Todos los demás de las interacciones deben originarse en los servidores backend del cliente.

Los SDK del controlador y del consumidor se basan en estas funciones estándar. Sin embargo, es posible crear roles personalizados que permiten agrupar un conjunto arbitrario de permisos. Los SDK para consumidores y controladores mostrarán mensajes de error cuando se produzca un falta el permiso necesario. Por eso, recomendamos enfáticamente con el conjunto estándar de roles presentados arriba, en lugar de los roles personalizados.

Crea una cuenta de servicio

Puedes crear una cuenta de servicio con IAM & Admin > Service Accounts en la consola de Google Cloud. En la lista desplegable Rol, selecciona Fleet Engine y asignar uno de los roles a la cuenta de servicio. Es bueno práctica para indicar qué cuenta está asociada con cada rol. Por ejemplo, asigna un nombre significativo a la cuenta de servicio.

Para mayor comodidad, si necesitas acuñar JWT para clientes que no sean de confianza, agregar usuarios con el rol Creador de tokens de cuenta de servicio les permite crear tokens con las herramientas de línea de comandos de gcloud

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

Donde my-user@example.com es el correo electrónico que se usa para autenticar con gcloud (gcloud auth list --format='value(account)').

Biblioteca de autenticación de Fleet Engine

Fleet Engine usa JWT para restringir el acceso a las APIs de Fleet Engine en sitios no confiables entornos de prueba. La biblioteca de autenticación de Fleet Engine, disponible en GitHub, simplifica la construcción de JWT de Fleet Engine y firmarlos de forma segura.

La biblioteca proporciona los siguientes beneficios:

Simplifica el proceso de creación de tokens de Fleet Engine.
Proporciona mecanismos de firma de token distintos del uso de archivos de credenciales (como y suplantará la identidad de una cuenta de servicio).

Crea un token web JSON (JWT) para la autorización

Cuando no se usa la biblioteca de autenticación de Fleet Engine, los JWT deben que puedes crear directamente en tu base de código. Esto requiere que tengas conocimientos comprensión de los JWT y su relación con Fleet Engine. Por eso, Se recomienda encarecidamente aprovechar la biblioteca de autenticación de Fleet Engine.

Dentro de Fleet Engine, los JWT proporcionan autenticación de corta duración y garantizar que los dispositivos solo puedan modificar vehículos o tareas para los que están autorizados. Los JWT contienen un encabezado y una sección de reclamación. La sección de encabezado contiene información como el clave privada para usar (obtenida de las cuentas de servicio) y la encriptación de codificador-decodificador. La sección de reclamos contiene información como el la hora de creación del token, el tiempo de actividad del token, los servicios en los que reclamar acceso y otra información de autorización para reducir el alcance el acceso a los datos; por ejemplo, el ID del vehículo de entrega.

Una sección de encabezado JWT contiene los siguientes campos:

Campo	Descripción
`alg`	El algoritmo que se usará. `RS256`:
`typ`	El tipo de token. “JWT”.
`kid`	El ID de la clave privada de tu cuenta de servicio Puedes encontrar este valor en el campo `private_key_id` del archivo JSON de tu cuenta de servicio. Asegúrate de usar una clave de una cuenta de servicio con el nivel correcto de permisos.

Una sección de reclamaciones de JWT contiene los siguientes campos:

Campo	Descripción
`iss`	La dirección de correo electrónico de tu cuenta de servicio.
`sub`	La dirección de correo electrónico de tu cuenta de servicio.
`aud`	El SERVICE_NAME de tu cuenta de servicio, en este caso https://fleetengine.googleapis.com/
`iat`	La marca de tiempo en la que se creó el token, especificada en segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC. Espera 10 minutos para el sesgo. Si el botón La marca de tiempo corresponde a un pasado muy lejano o, en el futuro, es posible que el servidor informe un error.
`exp`	Es la marca de tiempo en la que vence el token, que se especifica en segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC. La solicitud falla si la marca de tiempo más de una hora en el futuro.
`authorization`	Según el caso de uso, puede contener `deliveryvehicleid`, `trackingid`, `taskid` o `taskids`.

Crear un token JWT hace referencia a firmarlo. Para instrucciones y muestras de código para crear y firmar el JWT, consulta Autorización de cuenta de servicio sin OAuth. Luego, puedes adjuntar un token creado a llamadas de gRPC o a otros métodos usados para acceder a Fleet Engine.

Reclamaciones de JWT

La solución de flota de red de acceso usa reclamaciones privadas. El uso de reclamaciones privadas garantiza que solo los clientes autorizados pueden acceder a sus propios datos. Por ejemplo, cuando tu backend emite un token web JSON para el dispositivo móvil del repartidor, ese token Tener la reclamación deliveryvehicleid con el valor de la entrega de ese conductor el ID del vehículo. Luego, según el rol del conductor, los tokens habilitan el acceso solo para el ID del vehículo de entrega específico y no ningún otro ID arbitrario del vehículo.

La solución de flota de red de acceso usa las siguientes reclamaciones privadas:

deliveryvehicleid: Se usa cuando se llama a las APIs por vehículo de entrega.
taskid: Se usa cuando se llama a las APIs por tarea.
taskids: Se usa cuando se llama a BatchCreateTasksAPI. Esta reclamación debe tener en forma de array, y este debe contener todos los IDs de tarea necesarios para completar la solicitud. No incluyas delivervehicleid, trackingid ni taskid reclamos.
trackingid: Se usa cuando se llama a GetTaskTrackingInfoAPI. El reclamo debe coincida con el ID de seguimiento de la solicitud. No incluyas delivervehicleid, taskid o taskids reclamos.

El token también debe contener la reclamación correspondiente cuando llames a las APIs del servidor de backend, pero puedes usar el valor especial de un asterisco ("*") para reclamos deliveryvehicleid, taskid y trackingid. El asterisco ("*") también se puede usar en la reclamación taskids, pero debe ser el único elemento en el array.

Si quieres crear y firmar un JSON directamente como un portador del token, en lugar de con tokens de acceso de OAuth 2.0, lee las instrucciones para Autorización de cuenta de servicio sin OAuth en la documentación de Identity Developer.

El mecanismo para adjuntar el token a una llamada de gRPC depende del lenguaje y el framework utilizado para hacer la llamada. El mecanismo para especificar un token a una llamada HTTP es incluir un encabezado de autorización con un token del portador cuyo valor es el token, tal como se indica en las notas de autorización para seguimiento del envío o rendimiento de la flota casos de uso.

En el siguiente ejemplo, se muestra un token para una operación por tarea de tu servidor de backend:

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

En el siguiente ejemplo, se muestra un token para una operación de creación de tareas por lotes de tu servidor de backend:

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

En el siguiente ejemplo, se muestra un token para una operación por vehículo de entrega de tu servidor de backend:

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

En el siguiente ejemplo, se muestra un token para clientes usuarios finales:

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

En el siguiente ejemplo, se muestra un token para tu app de controlador:

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

En el campo kid del encabezado, especifica la ubicación privada de tu cuenta de servicio el ID de la clave. Puedes encontrar este valor en el campo private_key_id de tu archivo JSON de la cuenta de servicio.
Para los campos iss y sub, especifica la dirección de correo electrónico de tu cuenta de servicio. Puedes encontrar este valor en el campo client_email de tu cuenta de servicio Archivo JSON.
En el campo aud, especifica https://SERVICE_NAME/.
En el campo iat, especifica la marca de tiempo de cuando se creó el token. en segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970. Espera 10 minutos de sesgos. Si la marca de tiempo es demasiado lejana en el pasado o en el futuro, el el servidor podría informar un error.
En el campo exp, especifica la marca de tiempo de vencimiento del token. en segundos desde el 1 de enero de 1970 a las 00:00:00 UTC. El valor recomendado es iat + 3,600.

Cuando firmes el token que se pasará a un dispositivo móvil o usuario final, asegúrate de que para usar el archivo de credenciales para la función de Conductor de reparto o Consumidor. De lo contrario, el dispositivo móvil o el usuario final podrá modificar o ver información a la que no deberían tener acceso.