Skip to content

Authentication

SeaTable Server Enterprise Edition (SeaTable) supports multiple authentication types.

The default authentication type is authentication against the local user database (with or without two-factor authentication).

Additionally, SeaTable supports the following external authentication types:

Finally, users can also authenticate using JWT, which may be interesting for some special use cases.

Username

SeaTable assigns every user a unique username, regardless of the authentication type used. The username serves as a key to link the different SQL database tables.

The username looks like this: b7bd00e840a14b748ce2bffdf409488b@auth.local The corresponding regular expression is ^[a-f0-9]{32}(@auth.local)$. The part of the username in front of the @-sign is a random value. If a user account is deleted and recreated with exactly the same details, the new username will be different from the previous one.

The username is generated when the account is created. The time at which SeaTable creates the account in the database depends on the authentication type:

  • Local user database: when the administrator registers the user or when the user self-registers
  • LDAP Auth, OAuth, and SAML: when the user logs in for the first time
  • LDAP Sync: when the sync job runs for the first time after the corresponding modification in the LDAP directory

One username - multiple names

For historical reasons, the SQL database tables use non-uniform names for username. In some tables, username is simply user. In some others, it goes by the name of email or virtual_id. Despite the inconsistent naming, it is always the same object. In the SeaTable Manual, only username is used unless reference is made to a specific table column.

Database Structure

SeaTable's databases encompass almost 100 tables. Four of those are relevant for user management and authentication. (Tables related to 2FA are disregarded in this document.)

Database Table
ccnet_db EmailUser
dtable_db profile_profile
dtable_db social_auth_usersocialauth
dtable_db id_in_org_tuple

Note: The table LDAPUsers in ccnet_db is no longer used.

The database tables shown in the following sections are for illustrative purposes only. Yet, they represent a possible system configuration and are internally consistent.

Table EmailUser

The table EmailUser stores all user accounts of a SeaTable Server with the account status and privileges for every user account. Additionally, the table also contains the (hashed) passwords for all users that authenticate directly against SeaTable.

mysql> select email,is_staff,is_active,left(passwd,25) from ccnet_db.EmailUser;
+---------------------------------------------+----------+-----------+---------------------------+
| email                                       | is_staff | is_active | left(passwd,20)           |
+---------------------------------------------+---------------------------+----------+-----------+
| b7bd00e840a14b748ce2bffdf409488b@auth.local |        1 |         1 | PBKDF2SHA256$10000$4cd... |
| 12ae56789f1e4c8d8e1c31415867317c@auth.local |        0 |         1 | PBKDF2SHA256$10000$736... |
| 145504ae043c438cbb55f2afb084d586@auth.local |        0 |         1 | !                         |
| 91e3f171e9214b0cab6418abfb70bc53@auth.local |        0 |         1 | !                         |
| 1a8d6725c4ae40c688b40028fd62c73f@auth.local |        0 |         1 | !                         |
+---------------------------------------------+---------------------------+----------+-----------+

is_staff determines whether the user has system administrator privileges. is_staff accepts only 0 (False) and 1 (True) as values.

is_active determines whether the user is active. Only active users can log into SeaTable. is_active also accepts only 0 (False) and 1 (True) as values.

Users with a password in the local SQL database:

SeaTable stores the passwords in the database as hash values. Every password hash starts with PBKDF2SHA256$10000$ which means that the password was hashed using the PBKDF2SHA256 algorithm and that 10.000 iterations where used (more about PBKDF2 on Wikipedia).

The first two users in the sample table above are users using the default authentication type. The first of the two is system administrator.

External authentication:

A ! instead of a hash value means that the user uses external authentication. The table, however, does not contain the information of which authentication type.

The last three users in the sample table above are users authenticating using either LDAP, OAuth, or SAML.

Table profile_profile

The table profile_profile, as the name indicates, contains profile information for every user in the system such as nickname, interface language, and contact email address. Every record in the table EmailUser has its correspondence in profile_profile.

mysql> select user,nickname,lang_code,contact_email,login_id from dtable_db.profile_profile;
+---------------------------------------------+--------------+-----------+-------------------+----------+
| user                                        | nickname     | lang_code | contact_email     | login_id |
+---------------------------------------------+--------------+-----------+-------------------+----------+
| b7bd00e840a14b748ce2bffdf409488b@auth.local | admin        | en        | admin@seatable.io | NULL     |
| 12ae56789f1e4c8d8e1c31415867317c@auth.local | Test         | en        | test@seatable.io  | NULL     |
| 145504ae043c438cbb55f2afb084d586@auth.local | Hulk         | en        | hulk@seatable.io  | hulk     |
| 91e3f171e9214b0cab6418abfb70bc53@auth.local | Tony Stark   | en        | tony@seatable.io  | tony     |
| 1a8d6725c4ae40c688b40028fd62c73f@auth.local | Steve Rogers | en        | steve@seatable.io | steve    |
+---------------------------------------------+--------------+-----------+----------+-------------------+

nickname is the display name of the user in the web interface of SeaTable.

contact_email is the real email address of the user. SeaTable sends notifications to this address.

login_id is an alternative to the username that the user can use to log in. The login_id can only be set via SeaTable API and not in system administration in SeaTable's web interface.

Three valid combos for default authentication

Users authenticating against the local database can use the following three combinations to login: \1) contact_email + password \2) login_id + password \3) username + password

Table social_auth_usersocialauth

The table social_auth_usersocialauth is critical for external authentication with LDAP, SAML, or OAuth. This table maps the user's SeaTable username to its unique identifiers from the identity providers. Every record in the table EmailUser without a password must have at least one correspondence in this table to be able to log into SeaTable using external authentication.

mysql> select username,provider,uid from dtable_db.social_auth_usersocialauth;
+---------------------------------------------+----------------+--------------------------------------+
| username                                    | provider       | uid                                  |
+---------------------------------------------+----------------+--------------------------------------+
| 145504ae043c438cbb55f2afb084d586@auth.local | OAuth          | 877e1964-5585-4e1a-b069-1951ff79d373 |
| 91e3f171e9214b0cab6418abfb70bc53@auth.local | Authentik-SAML | 28347@authentik                      |
| 1a8d6725c4ae40c688b40028fd62c73f@auth.local | my-ldap        | 39731673920273                       |
+---------------------------------------------+----------------+--------------------------------------+

provider specifies the external authentication used. The name shown in this column is the name specified in the configuration of the external authentication source indtable_web_settings.py.

uid in this table is the unique identifier as communicated by the external authentication service. The uid has to be provided by the external authentication method and allows to match the users from the external service with the users inside SeaTable. This uid must not be changed over the lifetime of the user (despite name, email address, ... changes) If the uid changes, SeaTable considers the user as a new user and creates a new username accordingly.

Table id_in_org_tuple

This table stores the user IDs. Because setting a user ID is optional, this table can be significantly shorter than all the other three tables.

mysql> select * from dtable_db.id_in_org_tuple;
+---------------------------------------------+-----------+--------+
| virtual_id                                  | id_in_org | org_id |
+---------------------------------------------+-----------+--------+
| b7bd00e840a14b748ce2bffdf409488b@auth.local | 21        |     -1 |
| 145504ae043c438cbb55f2afb084d586@auth.local | 222       |     12 |
| 91e3f171e9214b0cab6418abfb70bc53@auth.local | 333AZE    |     34 |
| 1a8d6725c4ae40c688b40028fd62c73f@auth.local | EF_3479   |     -1 |
+---------------------------------------------+-----------+--------+

id_in_org is the ID of the user. The user ID can be an alphanumeric string and must be unique within every team/organization.

org_id is the id of the team/organization which is unique in the system. An org_id value of -1 signifies that the user does not belong to any team/organization.