Page Comparison

Para la autenticación de peticiones en los servicios SIF se utilizan las cabeceras 'Authorization' y timestamp', validando que el contenido de éstas sea correcto en cuanto a estructura de acuerdo el algoritmo definido por el estándar SIF, además se verifica que el contenido de la cabecera 'Authorization' contenga datos válidos para los valores 'appKey' y secretKey verificando que estos valores correspondan con los datos guardados en la BDC.

Authorization: SIF_HMACSHA256 U0lTOk16UTRZV1kxWTJJMlpUY3hOVEV4WVdWbVpESTNNVEF5TWpReFlXTmxPV1V5Tm1Rek1qVTBNMlk0T0RReE1XWmpaR0l3TTJKbE5XWmlNbU5rTnpsaU1RPT0=

timestamp: 2014-09-04T09:22

Cuando recibe una petición POST en el servicio /environments/environment se ejecutan los siguientes pasos para verificar la autenticidad de la petición y crear un token de sesión:

1. Verificar que los headers 'Authorization' y 'timestamp' estén presentes en la petición.
2. Separar el contenido del header 'Authorization' por el caracter ' ' (espacio vacío) de manera que el primer valor corresponda con el método de autenticación y se valida que el método de autenticación sea válido. De momento el único método soportado es 'SIF_HMACSHA256'.
3. Decodificar Base64 el contenido del segundo elemento del header 'Authorization' para obtener los siguientes elementos 'appKey' y una cadena codificada Base64(HMAC SHA 256). Para el header 'Authorization' de ejemplo obtendríamos el siguiente valor:
   • • SIS:MzQ4YWY1Y2I2ZTcxNTExYWVmZDI3MTAyMjQxYWNlOWUyNmQzMjU0M2Y4ODQxMWZjZGIwM2JlNWZiMmNkNzliMQ== 
4. Separar la cadena resultante por el caracter ':', el primer elemento corresponde con el 'appKey' correspondiente al usuario SIF.
5. Realizar un consulta a la BDC para verificar que el 'appKey' existe y corresponde con un usuario SIF válido.
6. Si el 'appKey' existe en BDC entonces se obtiene su secretKey (ejemplo: 's4nt1ll4n4R4') y se utiliza para generar el string codificado hmac_sha256 de la siguiente cadena: 'appKey:timestamp' (ejemplo SIS:2014-09-04T09:22) que para el ejemplo generaría el siguiente string codificado:
   • • 348af5cb6e71511aefd27102241ace9e26d32543f88411fcdb03be5fb2cd79b1
7. Decodificar Base64 el segundo elemento obtenido al separar los elementos como se menciona en el paso 4, para este ejemplo obtenemos el siguiente string:
   • • 348af5cb6e71511aefd27102241ace9e26d32543f88411fcdb03be5fb2cd79b1
8. Por último verificar que los strings obtenidos en los pasos 6 y 7 sean exactamente iguales, lo que indica que la petición es válida y se procede a generar el token de sesión correspondiente codificando en Base64 el 'appKey', en este ejemplo el token de sesión sería:
   1. • U0lT

Una vez que se ha creado un environment válido se deberá utilizar el token de sesión para crear el header 'Authorization' que se enviará en cada petición posterior, en este caso el token de sesión reemplaza al 'appKey' al momento de generar el header 'Authorization'.

Para verificar que las peticiones posteriores a la creación del Environment sean válidas se realiza el mismo proceso que se describe en la creación del Environment, el único cambio es que en el paso 4 después de separar los elementos del 'Authorizarion' por el caracter ':' el primer elemento correspondería con el token de sesión en vez del 'appKey', en este ejemplo obtendríamos 'U0lT' . Entonces se procede a decodificar Base64 el sesión token para obtener el 'appKey' original y así poder realizar la consulta a la BDC para verificar que el 'appKey' es válido.

Los pasos restantes del proceso se realizan de la misma manera que se describe anteriormente, con excepción del paso 8 el cual ya no es requerido en peticiones posteriores a la creación del Environment.

Se deberá realizar un backup de usuarios con rol_id = 62  INTEGRACIÓN  SIS y el usuario MS_R4_PRE  usado para peticiones de SSB a BDC.

http://homol.sistemauno.com/ws/uno_wsx_login.php?