Subscribers - Seguridad y Claves

Firma del suscriptor

Todas las solicitudes realizadas a los suscriptores de eventos están firmadas por un mecanismo que permite a los suscriptores verificar el origen del mensaje.
La firma es un token generado por Sensedia Events Hub a partir de una clave de conocimiento mutuo (entre el Events Hub y el suscriptor) que se envía durante el registro de suscriptores (vea sobre el envío abajo).

La firma generada será un JWT (JSON Web Token) con el algoritmo HS256 (HMAC con SHA-256), realizada con los siguientes valores:

Campos:

• iss: el customerName.

• sub: el subscriberId.

• jti: el transactionId.

• c_hash: el contenido del cuerpo en SHA-256.

• iat: el timestamp del envío en la zona horaria UTC.

Clave de firma

Una clave de conocimiento mutuo debe ser informada al crear un suscriptor en el Events Hub (vea sobre la creación de suscriptores aquí).
La suscripción a eventos solo es posible después de insertar la clave en el campo Key y hacer clic en VALIDATE KEY.

NOTE

Si la clave no se informa dentro del tiempo, haga clic en el ícono (que aparecerá en la pantalla) para reiniciar la cuenta del tiempo.
Una vez validada, la clave se almacena de forma segura y no puede ser recuperada.

Token JWT

El suscriptor siempre recibirá la firma en un header de solicitud identificado por x-CLIENTE-webhooks-signature, siendo el contenido transmitido siempre en Base64 (independientemente de si lo utiliza o no para verificación o si opta por utilizar mecanismos de seguridad disponibles más adelante en este documento).
Es decir, el Events Hub siempre transmitirá la firma en las solicitudes a los suscriptores, como en este ejemplo de header:

El usuario puede validar la firma JWT en su código. En el ejemplo a continuación, usamos Java:

Opciones de tokens de seguridad

Además de la firma, que siempre se transmite, el Events Hub también ofrece la opción de enviar un token para requisitos de seguridad de los receptores de eventos.

Después de que el suscriptor haya registrado su clave mutua para la generación de la firma, puede optar por recibir sus solicitudes con la adición de un token. Hay dos opciones de token: estático y dinámico (siendo que el primero no expira y el segundo sí). Ambos deben ser tokens hash en formato SHA-256 y en Base64.

En ambos casos, el suscriptor también contará con la clave de firma para la validación y garantía de la solicitud. Si el token se configura para ser transmitido en el header, tanto la firma como el token estarán presentes (el token bajo el nombre configurado por el usuario, que en el ejemplo a continuación es security-token):

NOTE

Usted puede configurar solo un token por suscriptor.

Token estático

Al optar por recibir sus solicitudes añadiendo un token estático (que no expira), este puede ser registrado directamente en el Events Hub.
Es necesario informar el valor del token que será transmitido en todas las solicitudes.

Cabe destacar que este es el enfoque más simple y que requiere menos recursos y codificación por parte del suscriptor (en comparación con el token dinámico). Sin embargo, es más susceptible a ataques (como un simple ataque de repetición, por ejemplo).

El token debe configurarse en la etapa SECURITY de registro o edición de un suscriptor, a través de los siguientes campos:

• Type: tipo de token (elegir Static).

• Location: dónde se debe pasar el token en la solicitud (opciones: header o query param).

• Name: nombre con el que se pasará el valor del token.

• Token SHA-256: valor del token. Si lo desea, puede generar un token aleatorio mediante el ícono .

Token dinámico

El token dinámico ofrece mayor seguridad en el tráfico de mensajes entre el Events Hub y los suscriptores en comparación con el token estático.
El token dinámico tiene un período de expiración y es totalmente gestionado por el suscriptor.

Cuando se utilizan tokens dinámicos, el suscriptor deberá disponer de más recursos y asumirá gran parte de la responsabilidad del uptime del ecosistema.
Esto se debe a que el Events Hub dependerá completamente del suscriptor para obtener los tokens, lo que puede causar la no recepción de mensajes.
Sin embargo, el dinamismo del mecanismo dificulta posibles ataques, configurándose como una opción más segura.

Optando por este enfoque, el suscriptor necesariamente deberá proporcionar una interfaz para que el Events Hub obtenga el token.
Esta interfaz deberá proveer un HTTP POST que será responsable de generar los tokens.

NOTE

En este enfoque, el suscriptor siempre debe validar la firma que también será transmitida en la solicitud de token por el Events Hub.

Solicitud del token:

Respuesta del token:

El token debe configurarse en la etapa SECURITY de registro o edición de un suscriptor, a través de los siguientes campos:

• Type: tipo de token (elegir Dynamic).

• Location: dónde se debe pasar el token en la solicitud (opciones: header o query param).

• Name: nombre con el que se pasará el valor del token.

• URL OAuth: URL de generación del valor del token.

NOTE

No hay refresh de los tokens dinámicos registrados. Los tokens se reutilizan durante el tiempo definido por el usuario.