2. Seguridad¶

Trak.e's security scheme is based on Oauth2 and supports two flows:

• Resource Owner Password Credentials for Trak.e Web.
• Client Credentials for applications and third-party services.

2.1 Resource Owner Password Credentials Flow¶

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token.

This flow may be used to obtain an access token using a username and a password.

A POST request must be made to the /auth/login endpoint with an x-www-form-encoded body containing the username and password and specifying grant_type=password.

2.2 Client Credentials¶

This flow can be used to obtain an access token from a pair of client credentials, typically when a third-party application needs access to trak.e resources. A POST request must be made to the /auth/login endpoint with an x-www-form-encoded body containing the client_id and client_secret and specifying grant_type=client_credentials.

2.3 Access token¶

Upon successful login the application will respond with an access token that can be used to access trak.e protected resources for which the user/client is authorized. This token acces is temporal. In addition, the access token is invalidated if the user makes a new successful login.

2.4 Refresh token¶

The refresh token is used to obtain access tokens when the latter has expired or been invalidated. The refresh token is sent by the app on successful login. To get a new access token from a refresh token, you must make a POST request to /auth/login reporting the refresh token and specifying grant_type=refresh_token.

2.5 User¶

Each user has the following properties

• Full name
• username: max length: 100 characters.
• email.
• password.
• Scopes (roles): the scope list for this user. A user can have one or more scopes.
• Permissions: they are used to restrict access permissions on a user level on a granular way.

2.5.1 Blocked users¶

Trak.e offers the possibility to block users leaving them unable to access the application or using the API. Users are also blocked after 3 failed login attempts. Users may be unblocked by a Security Administrator.

2.6 Clients¶

Each client has the folling properties:

• Name (50 characters or less)
• Description (250 characters or less)
• Scopes (roles): the scope list for applications and services using this authorization. A client can have one or more scopes.
• Permissions: they are used to restrict access permissions on a client level on a granular way.

Trak.e will generate and save a client_id and a client_secret to be used as client credentials.

Each entity can define as many clients as they deem necessary, which will allow them to keep different applications authorized under their own terms.

2.7 Permissions¶

Each trak.e resource has associated a set of specific permissions that must be obtained in order to execute actions on those resources.

Generally, they are of the form {service}_{resource}:{action} where action is one of the following:

• add: Add a new resource of this type
• update: Update a resource of this type
• fetch: Fetch a resource of this type given its identifier.
• search: Search for resources of this type, possibly with a query.
• delete: Delete a resource of this type given its identifier.

2.8 Scopes (roles)¶

To simplify the assignment of permissions to users/clients, scopes may be defined to group a specific set of permissions. Trak.e offers a series of predefined scopes that may be mosified to follow the need of each entity. In addition, new scopes may be defined as necessary. The predefined scopes in trak.e are:

The operators and supervisors

Default operators and supervisors can access the same functionalities within Trak.e. The different roles are also used to handle the possible transitions of the state of a file or alert or access to them.

For example, if its required that a digital profile is first checked by and operator and then approved by a supervisor, it can be set up with a specific digital profile workflow. More information on this topic on Digital Profiles.

The same happens if we want certain alerts to be treated and closed by a specific scope. More information on this topic on Alerts.

2.9 Scope permission restriction¶

In addition to scopes, trak.e allows defining specific permissions for each user or client regardless of the role. These permissions are and additional restriction on the general permissions granted by the scope. These permissions may be positive or negative:

• A positive permission for a resource allows the user/client to execute that action - regardless of the scope they may have.
• A negative permission for a resource forbids the user/client to execute that action - regardless of the scope they may have.

2.10 IP Filters¶

In addition, trak.e allows each entity to define a set of IP addresses or ranges to restrict the access to the platform.

For example:

10.0.0.0-10.255.255.255 # ip range
10.0.0.0/8 # ip range
10.0.0.1 # specific ip address.

2.11 Password policy¶

Trake imposes the following password policy:

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

2.12 Password Validity Period¶

The users password will expire on the user's first login and then periodically. This period of validity of the password has a default value of one year and can be updated by a security administrator.

2.13 Audit of access events¶

All platform access events to the platform are audited, both for users and clients, and are accesibles on the trak.e frontend and via API for analysis or integration into monitoring tools.

The events have the following shape:

[
    {
        "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"
    }
]

The audited access events are the following:

• invalid_ip: Attempt to login from an invalid IP.
• missing_credentials: Attempt to login without credentials.
• login: Successful login.
• logout: Successful logout.
• invalid_credentials: Attempt to login with invalid credentials.
• invalid_sso: Attempt to login with invalid SSO.

2.14 Resources¶

2.15 API Documentation¶

API