Autenticación y Autorización

Autenticación

Ilustrado en el siguiente diagrama de flujo, se describe la secuencia de pasos a seguir para autenticarse frente al sistema: Diagrama de flujo

1. Primer paso

Realizar una petición al servicio "/authentication/login" para loguearse, enviando las credenciales (usuario y password). Si la respuesta es exitosa, se obtiene el Token de acceso.

Importante: no es necesario consumir este servicio previamente cada vez que se vaya a consumir un servicio de la Web API, basta con hacerlo sólo una vez. Eventualmente, sí se deberá volver a realizar nuevamente el Login, y así obtener un nuevo Token, debido a alguna de las siguientes dos circunstancias:

  • Se consumió el servicio "/authentication/logout"
  • O bien se expiró el tiempo de validez del Token.

    Como toda sesión de usuario, tiene un período que caduca tras determinado tiempo, y cuando esto sucede, el Token también caduca y deja de ser válido.

2. Segundo paso

Realizar una petición al servicio "/accounts/tenants" para obtener información de a qué bases de datos (“tenants”) se tiene concecido el permiso para poder trabajar con ellas. A este servicio - y cualquier otro - se debe presentar el Token.

Aclaración: el Identificador del Tenant o Base de Datos nunca cambiará, por lo que en realidad basta con consultar este servicio una única vez para obtener este dato.

Para mayor información sobre este flujo, revisar la documentación detallada.

3. Tercer paso (ejemplo)

A modo de ejemplo, en la ilustración se ve el consumo al servicio "/employees", pero pudo haber sido cualquier otro. La idea es graficar que - una vez obtenido un Token y sabiendo el Identificador del Tenant al cual se desea conectar -, ya se está en condiciones de consumir cualquier servicio, siempre enviando a éstos dos conjunto a la petición.


Autorización

Una vez autenticado, ya se tiene un Token de acceso y por lo tal se pueden consumir el resto de los servicios, pero esto no significa necesariamente que se tenga permisos para todos. Cada servicio tiene sus propias restricciones de seguridad, establecida según “roles”, de modo tal que si el usuario con el que se realizó el Login no tiene los roles que un servicio requiere, la petición fallará, acusando una denegación en la respuesta justamente debido a esto.

Ir arriba ↑