Thanks for your feedback!
EDIT
Encrypt
Este interceptor tiene como objetivo cifrar y descifrar el contenido de una llamada para que la información pueda viajar con mayor confidencialidad e integridad, es decir, mayor seguridad.
Cuando se van a enviar datos confidenciales en el cuerpo de una petición, el interceptor cifra esos datos con una clave AES a la que sólo el usuario y el gateway tienen acceso.
Para que el proceso funcione, debe registrarse la clave AES. Al recibir una petición, el gateway comprueba primero si la clave registrada es válida y, de ser así, reenvía el mensaje normalmente.
Registro de la clave AES en el gateway
Cuando usted utiliza el interceptor Encrypt, su socio necesita ajustar su aplicación para usar la criptografía.
Vamos a dar un paso a paso para habilitar el uso del interceptor Encrypt.
1. Existencia de la clave AES
En primer lugar, es necesario que el socio tenga en su poder una clave AES (128 bits, o 16 bytes, AES/CFB/NoPadding).
Ella tendrá que ser encriptada (lo que llamamos a lo largo de este documento como «generación de la clave AES»).
2. Obtención de clave pública desde el gateway
Para cifrar la clave AES, usted primero debe obtener la clave pública del gateway.
Para ello, debe realizar una operación GET para el recurso /security/keys:
curl -X GET https://environmentURL/security/keys
Si su entorno tiene la API Crypto, utilice el siguiente endpoint en lugar del curl anterior: https://environmentURL/api-crypto/api/v1/keys/public.
|
3. Criptografía de la clave AES
Ahora, es necesario utilizar la clave pública para cifrar la clave AES.
Para ello, debe ejecutar el script de su preferencia, introduciendo la clave pública (puede descargar ejemplos de script justo después de esto paso a paso).
La devolución debe ser la clave AES cifrada.
4. Envío de la clave cifrada y del ID
Ahora que la clave ya está cifrada, es necesario enviarla a través de una operación POST al recurso /security/keys.
Junto con la clave, debe enviar un ID.
Este debería ser el cuerpo:
{
"id":"key_id",
"type":"AES",
"key":"clave_cifrada"
}Como en el punto 2, se debe hacer un curl:
curl -X POST http://envonrimentURL/security/keys -d '{ "id": "key_id", "type": "AES", "key": "clave_cifrada"}'
Si hay la API Crypto en el entorno, utilice este endpoint: https://environmentURL/api-crypto/api/v1/keys/public.
|
| El "key_id" es un contenido que se puede configurar según sea necesario, puede ser el client ID de la aplicación, el access token o una combinación de ambos. Solo se puede crear una clave por ID. Si un usuario usa client ID para generar una clave, solamente puede hacerlo una vez con ese client ID Pero será posible generar otra clave usando el access token como identificador y una más usando la combinación de client ID y access token como ID. |
La siguiente imagen representa el proceso de generación de la clave AES:
Con los pasos seguidos, la criptografía funcionará. Para ello, el socio deberá cifrar el payload de la petición con esta clave AES, y solo el gateway podrá descifrarlo. Si el usuario coloca el interceptor en el flujo de respuesta (response), el gateway cifra el payload y el socio debe descifrar más tarde.
Configuración del interceptor en el Manager
Para configurar el interceptor Encrypt, introduzca un ID Header Name (nombre que se agregará al header de la petición con el ID registrado en el POST anterior).
La opción Tokens will also be encrypted, cuando se seleccione, cifrará los headers definidos en los interceptores Access Token Metric, Client ID Metric, Access Token Validation, Client ID Validation y OAuth.
Flujo
Este interceptor se puede insertar tanto en el flujo de petición (request) como en la respuesta (response), como se ve en la imagen de abajo. Es aconsejable que permanezca siempre al principio del flujo, antes que cualquier otro interceptor.
| Cuando se introduce en el flujo de respuesta, el ID Header Name debe ser el mismo que se utiliza en el flujo de petición y la opción para cifrar tokens no estará disponible. |
Llamadas con criptografía
Ahora, cuando su socio hace una llamada, ella debe estar cifrada con una clave AES. En este caso, la petición se descifrará cuando se ejecute el interceptor.
Si el interceptor de criptografía está en el flujo de respuesta, su socio tendrá que descifrarla.
La siguiente imagen ilustra el proceso.
Validación de token de acceso cifrado y/o client ID
En el interceptor Client ID Secret Encoded Validation, existe la posibilidad de validar un access token y/o client ID cifrados. Para ello, debe informar que vendrán cifrados y notificar a sus socios para que envíen los valores del access token y/o client ID cifrados.
Share your suggestions with us!
Click here and then [+ Submit idea]