View a markdown version of this page

General/Custom Requisitos de autorización para los desarrolladores de conectores - Integraciones gestionadas para AWS IoT Device Management

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

General/Custom Requisitos de autorización para los desarrolladores de conectores

La autorización general permite que tu conector utilice credenciales (como claves de API, tokens o username/password combinaciones) en lugar de tokens de usuario de OAuth 2.0. A diferencia de OAuth 2.0, que proporciona autorización a nivel de usuario mediante la vinculación de cuentas, la Autorización General permite que un único conjunto de credenciales controle los dispositivos de varios usuarios finales.

nota

En esta documentación, la autorización personalizada se denomina autorización general. Ambos términos describen el mismo mecanismo de autorización. En las siguientes secciones, utilizamos la palabra «Autorización general» por motivos de coherencia.

En esta sección se explica cómo implementar la compatibilidad con la autorización general en su AWS Lambda función de conector. Si es un cliente que está configurando la autorización general para un conector existente, consulteGeneral/Custom Requisitos de autorización.

¿Qué es la autorización general?

La autorización general es cualquier mecanismo de autorización ajeno a OAuth que permite a su conector realizar autorizaciones en plataformas de terceros utilizando las credenciales del cliente. Con la autorización general, Managed Integrations delega la administración de credenciales en su conector y un único conjunto de credenciales puede controlar los dispositivos de varios usuarios finales.

Esto resulta útil en situaciones en las que tiene una relación comercial con el proveedor del dispositivo y necesita administrar los dispositivos a escala sin flujos de autorización de usuarios individuales.

Cuándo usar la autorización general

Considere la posibilidad de implementar el soporte de autorización general en su conector cuando:

  • La plataforma de terceros no es compatible con OAuth 2.0

  • La plataforma de terceros proporciona material de autorización personalizado, como claves de API o credenciales, que pueden residir en AWS Secrets Manager

  • Debe administrar los dispositivos a escala sin flujos de autorización de usuarios individuales

nota

Su conector puede implementar ambos tipos de autorización en paralelo, lo que proporciona compatibilidad con diversos marcos de autorización.

Cómo se usa la Autorización General AWS Secrets Manager

AWS Secrets Manager es un servicio de almacenamiento secreto que protege las credenciales confidenciales, como las claves de API y los tokens. Los secretos se cifran mediante AWS Key Management Service claves. Para obtener más información, consulte la Guía del usuario de AWS Secrets Manager.

Para la autorización general, los clientes almacenan las credenciales de autorización en Secrets Manager y otorgan permiso a su conector C2C para acceder a estos secretos. Cuando las integraciones gestionadas invocan tu conector, proporcionan el ARN de Secrets Manager y el ID de versión en el encabezado de la solicitud. El conector recupera el valor secreto y lo utiliza para autorizar con la plataforma de terceros.

Este enfoque garantiza que las integraciones gestionadas nunca gestionen directamente las credenciales a largo plazo. Su conector mantiene un control total sobre la administración de credenciales y la generación de tokens, lo que hace que la solución se pueda extender a cualquier mecanismo de autorización compatible con su plataforma de terceros.

importante

Managed Integrations no accede ni administra las credenciales almacenadas en las del cliente. AWS Secrets Manager Su conector tiene el control total sobre la recuperación, el análisis y el uso de las credenciales.

importante

Le recomendamos que no registre credenciales o tokens confidenciales en ningún registro. Sin embargo, si se almacenan en registros, le recomendamos que utilice las políticas de protección de datos de los CloudWatch registros para ocultar los símbolos de los registros. Para obtener más información, consulte Ayuda para proteger los datos de registro confidenciales con el enmascaramiento.

Formato de solicitud de autorización general

Cuando Managed Integrations invoca tu conector para una asociación de cuentas de autorización general, el encabezado de la solicitud contiene una AWS Secrets Manager referencia en lugar de un token de OAuth. La estructura de la solicitud es coherente en todas las operaciones del conector (AWS.ActivateUser,AWS.DiscoverDevices, AWS.SendCommand y). AWS.DeactivateUser

ejemplo Ejemplo: solicitud de autorización general
{ "header": { "auth": { "secretsManager": { "arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key-AbCdEf", "versionId": "a1b2c3d4-5678-90ab-cdef-1234567890ab" }, "type": "GeneralAuthorization" } }, "payload": { "operationName": "AWS.DiscoverDevices", "operationVersion": "1.0", "connectorId": "Your-Connector-Id", ... } }
ejemplo Ejemplo: solicitud de OAuth 2.0 (a modo de comparación)
{ "header": { "auth": { "token": "ashriu32yr97feqy7afsaf", "type": "OAuth2.0" } }, "payload": { "operationName": "AWS.DiscoverDevices", "operationVersion": "1.0", "connectorId": "Your-Connector-Id", ... } }
nota

El conector debe gestionar ambos formatos de solicitud. Marque el auth.type campo para determinar qué método de autorización usar para cada solicitud.

Flujo de trabajo de autorización general

Cuando su conector reciba una solicitud de autorización general, siga este flujo de trabajo:

  • Compruebe el tipo de autorización: compruebe el auth.type campo del encabezado de la solicitud para determinar si la solicitud utiliza la autorización general

  • Referencia de Extract Secrets Manager: extrae el AWS Secrets Manager ARN y el ID de versión del objeto auth.secretsManager

  • Recuperar el secreto: llama a la AWS Secrets Manager GetSecretValue API con el ARN y el ID de versión proporcionados

  • Analice las credenciales: analice el valor secreto para extraer las credenciales de autorización (el formato depende de los requisitos de la plataforma de terceros)

  • Genere tokens (si es necesario): si es necesario, utilice las credenciales para generar un token de acceso o realice los pasos de autorización adicionales requeridos por la plataforma de terceros

  • Autorizar las llamadas a la API: utilice las credenciales o el token generado para autorizar las llamadas a la API a la plataforma de terceros

  • Operación de proceso: procese la operación del conector (AWS.DiscoverDevicesAWS.SendCommand,, etc.) mediante la conexión autorizada

nota

Su conector es responsable de toda la administración de credenciales, incluida la generación de los tokens, la actualización y la gestión de errores. Managed Integrations solo proporciona la referencia al secreto; no administra las credenciales en sí mismas.

Permisos Lambda para GeneralAuthorization

Su función de ejecución de Connector Lambda debe tener permiso para recuperar datos secretos del cliente. AWS Secrets Manager Añada los siguientes permisos a su política de funciones de ejecución de Lambda:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:*:*:secret:*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager.*.amazonaws.com" } } } ] }

Explicación de permisos

  • secretsmanager:GetSecretValue- Permite que su Lambda recupere valores secretos

  • kms:Decrypt- Necesario porque los secretos se cifran mediante claves AWS Key Management Service

nota

La política de ejemplo permite el acceso a cualquier secreto. En producción, debe restringir el Resource campo solo a los secretos que necesite su conector. Sin embargo, dado que los clientes crean sus propios secretos, es posible que tengas que usar un comodín o documentar la convención de nomenclatura que deben seguir los clientes.

El cliente también le concederá a Lambda permiso para acceder a su secreto específico a través de la política de recursos del secreto.