2. Seguridad¶

El esquema de seguridad de Trak.e está basado en Oauth2 y soporta dos flujos:

• Resource Owner Password Credentials para Trak.e Web.
• Client Credentials para aplicaciones y servicios de terceros.

2.1 Flujo Resource Owner Password Credentials¶

El flujo Resource Owner Password Credentials (i.e., usuario y contraseña) puede ser usado direcatamente como una concesion de autorización para obtener un token de acceso.

Este flujo puede ser usado para obtener un token de acceso a partir de un usuario y contraseña. Se debe hacer un POST request al endpoint /auth/login con un body x-www-form-encoded conteniendo el usuario y contraseña y especificando grant_type=password.

2.2 Client Credentials¶

Este flujo puede ser usado para obtener un token de acceso a partir de un juego de credenciales cliente, típicamente cuando una aplicación cliente necesita acceso a los recursos de trak.e. Se debe hacer un POST request al endpoint /auth/login con un body x-www-form-encoded conteniendo el client_id y el client_secret y especificando grant_type=client_credentials.

2.3 Token de acceso¶

Al realizar un login exitoso la aplicación responderá con un token de acceso que puede ser usado para acceder a los recursos protegidos de trak.e para los que el usuario/cliente este autorizado. El token de acceso es temporal. Además el token de acceso se invalida si el usuario hace un nuevo login exitoso.

2.4 Token de actualización¶

El token de actualización es utilizado para obtener tokens de acceso cuando este ha expirado o ha sido invalidado. El token de actualización es informado por la aplicación en un login exitoso. Para obtener un nuevo token de acceso a partir de un token de actualización, se debe hacer un POST request a /auth/login informando el token de actualización y especificando grant_type=refresh_token.

2.5 Usuarios¶

Cada usuario tiene las siguientes propiedades

• Nombre completo.
• Nombre de usuario: longitud máxima 100 de carácteres.
• Correo electrónico.
• Contraseña (password).
• Roles: la lista de roles que posee este usuario. Un usuario puede tener uno o más roles.
• Permisos: se utilizan para restringir los permisos de acceso de los usuarios en forma más granular.

2.5.1 Usuarios bloqueados¶

Trak.e ofrece la posibilidad de bloquear usuarios, volviendolos inusables para acceder la aplicación o usar la API. Los usuarios tambien son bloqueados luego de tres intentos fallidos de login. Los usuarios pueden ser desloqueados por un Administrador de seguridad.

2.6 Clientes¶

Cada cliente lleva las siguientes propiedades:

• Nombre (50 caracteres o menos)
• Descripción (250 caracteres o menos)
• Roles: la lista de roles que poseen las aplicaciones y servicios de terceros que utilicen esta autorización. Cada cliente puede tener uno o más roles.
• Permisos: se utilizan para restringir los permisos de acceso de los usuarios en forma más granular.

Trak.e generará y guardará un client_id y un client_secret para que funcionen como credenciales de cliente.

Cada entidad puede definir tantos clientes como crea necesario, lo cuál le permitirá mantener distintas aplicaciones autorizadas bajo sus propios términos.

2.7 Permisos¶

Cada recurso en trak.e tiene asociado un conjunto permisos específicos con los que hay que contar para poder ejecutar acciones sobre esos recursos.

En general, estos permisos tienen la forma {service}_{resource}:{action}, donde action es uno de los siguientes:

• add: Alta de un nuevo recurso de este tipo.
• update: Actualización de recursos de este tipo.
• fetch: Recupero de un recurso específico de este tipo.
• search: Recupero de recursos de este tipo, posiblemente filtrando.
• delete: Borrado de recursos de este tipo.

2.8 Roles¶

Para simplificar la asignación de permisos a usuarios, se pueden definir roles que agrupen un conjunto especifico de permisos. Trak.e ofrece una serie de roles predefinidos que pueden ser modificados para seguir la necesidad de cada entidad. Adicionalmente, se pueden definir nuevos roles segun sea necesario. Los roles predefinidos en trak.e son los siguientes:

Los operadores y supervisores por defecto pueden acceder a las mismas funcionalidades dentro de Trak.e. Los distintos roles también se usan para manejar las posibles transiciones del estado de un legajo o alerta o acceso a los mismos.

Por ejemplo si queremos que un legajo lo revise un rol determinado y lo apruebe otro lo podemos configurar con un workflow de legajos específico. Más información en Legajos.

Lo mismo si queremos que determinadas alertas los pueda tratar y cerrar determinados roles. Mas información en Alertas.

2.9 Restricción de permisos sobre rol¶

Adicionalmente a los roles, trak.e permite definir permisos específicos para cada usuario o cliente independientemente del rol. Estos permisos son una restricción adicional sobre los permisos generales otorgados por el rol. Estos permisos pueden ser positivos o negativos:

• Un permiso positivo para un recurso permite que el usuario/cliente ejecute dicha acción - independientemente del rol que pueda tener.
• Un permiso negativo para un recurso prohibe que el usuario/cliente ejecute dicha acción - independientemente del rol que pueda tener.

2.10 Filtro por IP¶

Trak.e además permite a cada tenant (cliente Trak.e) definir un conjunto de IP o rango para restringir el acceso a la plataforma.

Ejemplos:

10.0.0.0-10.255.255.255 # rango de ip
10.0.0.0/8 # rango de ip
10.0.0.1 # ip específico

2.11 Política de passwords¶

Trake impone la siguiente política de contraseñas:

length=8,         # min length: 8
uppercase=1,      # need min. 1 uppercase letters
numbers=1,        # need min. 1 digits
special=1,        # need min. 1 special characters
strength=0.66,    # need min. 66% strength

2.12 Plazo de validez de la contraseña¶

La contraseña de los usuarios se expiran en el primer login del usuario y luego periódicamente. Este periodo de validez de la password tiene como valor por defecto un año y puede ser actualizado por un administrador de seguridad.

2.13 Auditoría de eventos de acceso¶

Todos los eventos de acceso a la plataforma se encuentran auditados, tantos de usuarios como clientes, y accesibles vía API para análisis o integración en herramientas de monitoreo.

Los eventos son de la forma:

[
    {
        "created_at": 0,
        "modified_at": 0,
        "created_by": "string",
        "modified_by": "string",
        "version": 0,
        "user": "string",
        "status": true,
        "ip": "string",
        "event": "invalid_ip",
        "ts": "2022-05-13T11:52:28.959945",
        "id": "5f85f36d6dfecacc68428a46"
    }
]

Los eventos de acceso registrados son los siguientes:

• invalid_ip: IP inválida.
• missing_credentials: Intento de login sin credenciales.
• login: Inicio de sesión.
• logout: Cierre de sesión.
• invalid_credentials: Intento de login con credenciales inválidas.
• invalid_sso: Ingreso con SSO inválido.

2.14 Recursos¶

2.15 Documentación API¶

API