> For the complete documentation index, see [llms.txt](https://docs-v3.toucantoco.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-v3.toucantoco.com/welcome/technical-resources/security/application-security.md). # Application Security ## Authentication Toucan Toco allows users to authenticate in two different ways: * By using their own list of accounts with usernames and passwords * By leveraging your organization's SSO (Single Sign-On) SSO can be configured using [SAML2](https://en.wikipedia.org/wiki/SAML_2.0) or [OpenID Connect (OIDC)](https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_\(OIDC\)) authentication protocols. ### Local Accounts Toucan has its own database of users. Basic administrative and viewer accounts are provided when the server is deployed. #### Password Policy We force users to respect the following password policy when creating or modifying their passwords: * Password's length must be more than 8 characters. * Password mustn't contain the user name. * Password mustn't be present in a list of common passwords (e.g. `1233456789` or `quertyuiop`). #### Password Storage Toucan never stores the passwords in plain text, nor encrypted, nor encoded. We follow the OWASP recommendations: * The passwords are hashed and stored using the [Argon2](https://en.wikipedia.org/wiki/Argon2) hashing algorithmn winner of the 2015 [Password Hashing Competition](https://en.wikipedia.org/wiki/Password_Hashing_Competition), resiting both side-channel and GPU-based attacks. * Each password gets a per-user random salt (stored alongside the hash and iteration count in the credential data). * When the hashing algorithm (or any parameter) is updated, we force users to update their password. ### Anti-bruteforce Mechanism We provide multiple layer of protection against brute-force attacks: * **Brute-force protection log-based**: We use [Crowdsec](https://www.crowdsec.net/) to prevent SSH or HTTP [brute-force attacks](https://en.wikipedia.org/wiki/Brute-force_attack) on all our servers. * [**Web Application Firewall**](https://en.wikipedia.org/wiki/Web_application_firewall): Using the same solution, by analysing incoming requests, we can also prevent attacks to ever reach our API endpoints. * **IP Reputation system**: Using the same solution, we prevent known [botnets](https://en.wikipedia.org/wiki/Botnet) to attack our API endpoints, and challenge possible attackers to prove they are not a bot. * **Applicative brute-force protection**: The authentication layer itself has brute force protection on its own using **rate limiting** and by **locking accounts** after too many failed attempts. We have further mechanisms in our infrastructure to prevent [denial of service attacks](https://en.wikipedia.org/wiki/Denial-of-service_attack). ### Multi-factor Authentication We provide these mechanisms: * Time-based one-time password (TOTP) * WebAuthn/Passkey * Recovery codes We can also provide SMS 2FA, but it's not recommended for production usage, and you'll need to contact the sales team. ### Single Sign On (SSO) #### OpenID Connect Toucan can act as an OIDC Client, allowing users to connect using your Identity Provider (IdP). We use the Authorization Code Flow with PKCE (Proof Key for Code Exchange) to authenticate users. We need the following configuration fields to be able to use your IdP: * The Client ID: Also known as the Username, is used by our identity provider to fetch access tokens from your IdP. * The Client Secret: Also known as the Password, is used by our identity provider to fetch access tokens from your IdP. * Other credentials method can be supported such as signed JWT assertion. * The Discovery URL: A document containing information about your IdP, such as: * The issuer: The identifier of your IdP. * The authorization endpoint: The login page of your IdP. * The token endpoint: The endpoint to fetch access tokens from your IdP. * The user info endpoint: The endpoint to fetch user information from your IdP. * The JWKS endpoint: The endpoint to fetch public keys from your IdP, to validate JWT. * The supported scopes: The scopes supported by your IdP. Toucan will request `openid email`. * The button text: The text to be displayed on the login button. If the Discovery URL is not provided, you must provide the information manually. We'll then provide the **Redirect URI** (also known as Callback URI) which must be whitelisted on your IdP. #### SAML2 Toucan can act as a Service Provider (SP), allowing users to connect using your Identity Provider(IdP). We use the SAML2.0 protocol to authenticate users with these settings: * Redirect binding for the authentication request. * Post binding for the authentication response. * Required signed authentication response. We need the following configuration fields to be able to use your IdP: * The Metadata URL: A document containing information about your IdP, such as: * The IdP Entity ID: The identifier of your IdP. * The authentication endpoint for the "Redirect" binding: The login page of your IdP. * The public certificate used to verify the signed authentication response. * The button text: The text to be displayed on the login button. If the Metadata URL is not provided, you must provide the information manually. We'll then provide the **SP Entity ID** and the **Assertion Consumer URL** (also known as Redirect/Callback URI) which must be whitelisted on your IdP. #### Additional features We also support the following features, upon request: * [Back-channel logout](https://openid.net/specs/openid-connect-backchannel-1_0.html): Propagate the logout from the IdP to the clients. * Post-login redirect URI: reach a specific page in Toucan after login. * [Post-logout redirect URI (RP Initiated Logout)](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout): Propagate the logout from the client to the IdP. * IdP Default Redirect: Hide the login page and redirect the user to the IdP automatically. * Force re-authentication upon reaching the login page. * SSO Permissions Provisioning. ### Session Management Toucan uses a session token stored in a cookie to persist the session. The active session last 24h, and can be refreshed until one month. Upon expiration, the user will be asked to log in again. An account page is available to users to manage their session (they can see active sessions on which device they are logged in, and log out of them). ## Account administration and permissions management ### User Management Admistrators has access to a panel allowing: * Review of the accounts and their privileges * Modification of accounts (privileges, password, etc.) * Deletion of accounts ### Access Control Permissions follow the RBAC (Role Based Access Control) model: * **User-specific permissions**: Users can have permissions to resources. * **Group-based permissions**: Groups can have permissions to resources. Users can be assigned to one or multiple groups. * **Multiple level of permissions for each resource**: Permissions of a user for a small-app can be "none", "viewer", "validator", or "editor". A user can be "admin", and will have access to all the resources of the small-app. More details in [user management](/administration/managing-users/users.md). Permissions allow users to configure: * Access a small-app. * Visiblity of stories and dashboards. * Access to data through filters and template variables. ## Audit Logs and Monitoring Every user's action on the Toucan platform is logged such as: * Loading of new data. * Processing of data. * Releasing new versions of data to users. * Successful and failed login attempts. * Access token generation, Session creation. Depending on the level of importance of the logs, the retention period can be between 30 days and 1 year. Anything related to authentication will be stored for 1 year. ## Data security Every commnucation between services and clients are encrypted in transit using TLS, or by using an encrypted private network using packet encapsulation. Every data stored in Keycloak is encrypted at-rest on a S3 using SSE-S3 (or its equivalent). Data stored in databases use block devices which are encrypted at-rest. The keys used for encryption are stored by our cloud providers. Every database requires a credential, and every service uses its own credentials, which has different privileges. ## Additional documents Upon request, we can provide additional documents to help you understand the security of the platform (including incident response, etc.). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs-v3.toucantoco.com/welcome/technical-resources/security/application-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.