Subscribers: Seguridad y Claves

Firma del suscriptor

Todas las peticiones 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 Events Hub y el suscriptor) que se envía durante el registro del suscriptor (vea sobre el envío abajo).

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

Header:

{
  "typ": "JWT",
  "alg": "HS256"
}

Payload:

{
  "iss": "staging",
  "sub": "7f08e914-3e64-4acb-9a1e-d21f9cbabcba",
  "jti": "266dd6d0-4f21-4191-aa05-2d9833fd8eee",
  "c_hash": "0d320d3ab6b8165bc347c1ffabbe1bfd6dbe1b436df23131a8f855f35834c2cc",
  "iat": 1603894744
}

en que:

  • iss es el customerName;

  • sub es el subscriberId;

  • jti es el transactionId;

  • c_hash es el contenido del cuerpo en SHA-256; y

  • iat es el timestamp del envío, utilizando la zona horaria UTC.

Clave de firma

Una clave de conocimiento mutuo debe ser informada al crear un suscriptor en Events Hub (consulte acerca de 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.

subscribers create security
Si la clave no se envía en el plazo de tiempo, se puede hacer clic en el icono icon refresh (que aparecerá en la pantalla) para reiniciar el conteo del tiempo. Una vez validada, la clave se almacena de forma segura y no se puede recuperar.

Token JWT

El suscriptor siempre recibirá la firma en un header de petición identificado por x-CLIENTE-webhooks-signature — con el contenido transmitido en Base64 — tanto si lo utiliza como si no para la verificación o si opta por utilizar los mecanismos de seguridad disponibles a continuación en este documento. Es decir, Events Hub siempre transmitirá la firma en las peticiones a los suscriptores, como en este ejemplo de header:

{
  "Content-Type": "application/json",
  "x-sensedia-webhooks-signature": "Y2E4MWNiMTYtNDNlNC0zZTk2LWFhZWEtNDg2MWU3NzkxZGM3"
}

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

// Validar firma JWT

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>
public static Claims decodeJWT(String jwt, byte[] subscriberKey) {
    //This line will throw an exception if it is not a signed JWS (as expected)
    Claims claims = Jwts.parser().setSigningKey(subscriberKey).parseClaimsJws(jwt).getBody();
    return claims;
}
La clave subscriberKey del código anterior es la clave mutua enviada por una petición POST descrita anteriormente.

Opciones de tokens de seguridad

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

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

En ambos casos, el suscriptor también dependerá de la clave de firma para validar y asegurar la petición. Si el token está configurado para ser traficado en el header, tanto la firma como el token estarán presentes (el token bajo el nombre que está configurado por el usuario, que en el siguiente ejemplo es security-token):

{
  "x-sensedia-webhooks-signature": "ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKSVV6STFOaUo5LmV5SnBjM01pT2lKemRHRm5hVzVuSWl3aWMzVmlJam9pTW1JMFlUVTJZV0V0WkdVeU55MDBPVEl6TFdFeVltTXRNbVkyTVRBMU0yVmpNamcwSWl3aWFuUnBJam9pWXprNU56UmxNekV0TURRNU1TMDBPREJoTFRrelpUWXRabVJqWlRFek1EaGlNR0V3SWl3aVkxOW9ZWE5vSWpvaVl6bGtNMkZqT0RJMU1UYzFNR1psTWpNd01EQTVPR1ptTVRWaFlUYzJOVEprTVRWbE5UQmpOemxoWXpSaVlqaGhOMlEwWWpobE1URXdOekpqTlRoaVl5SXNJbWxoZENJNk1UWXhPRFF3TlRnMU9YMC56UTVYTnpEaE5ZdU5DTVd1a0ktckZxeTkzbFFoYnRXalc2ZDNpT3dlUV9B",
  "security-token": "YWJjZGVmZmYtYXNkYXNkLWFzZC12c2JkZmRnZGYtNG1hc2Rkd2V1Z3VkYQ"
}
Solo puede configurar un token por suscriptor.

Token estático

Cuando el suscriptor elige recibir peticiones agregando un token estático (que no caduca), el token puede registrarse directamente en Events Hub. Por lo tanto, un valor de token debe ser informado y se traficará en todas las peticiones.

Vale la pena señalar que este es el enfoque más simple y que incurre en menos recursos y codificación desde el lado del suscriptor (en comparación con el token dinámico). Sin embargo, es más susceptible a los ataques (como un simple ataque de repetición, por ejemplo).

El token debe configurarse en el paso SECURITY de registro o edición de suscriptores a través de los siguientes campos:

  • Type: tipo do token (elegir Static).

  • Location: donde se debe pasar el token en la petición (opciones: header o query param).

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

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

    subscribers create security static

Token dinámico

El token dinámico proporciona mayor seguridad en el tráfico de mensajes entre Events Hub y los suscriptores en comparación con el token estático. El token dinámico tiene un período de caducidad y está completamente administrado por el suscriptor.

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

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

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

La interfaz debe recibir:

Header:

{
  "content-type": "application/json",
  "x-CLIENTE-webhooks-signature": "xxxxxxx"
}

Body:

{
  "type": "token"
}

La interfaz debe responder:

Header:

{
  "content-type": "application/json"
}

Body:

{
  "access_token": "<Token de acceso (hash en SHA-256 y Base64)>",
  "expires_in": "<Tiempo de caducidad del token en segundos>"
}

El token debe configurarse en el paso SECURITY de registro o edición de suscriptores a través de los siguientes campos:

  • Type: tipo do token (elegir Dynamic).

  • Location: donde se debe pasar el token en la petición (opciones: header o query param).

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

  • URL OAuth: URL para generar el valor del token.

    subscribers create security dynamic

No hay actualización de los tokens dinámicos registrados. Los tokens se reutilizan durante el tiempo definido por el usuario.
Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]