User and authentication model

A high level of protection must be assured of your data. We put great emphasis on security, and ensure that data is protected at all times. As part of that, our user management is based on a solid, well-tested user concept.

The first question we have to answer when talking about security is: “What is a user?”. Having a clear picture in mind is important to understand the big picture.

There are three basic types of user authentication:

• Case A: “Database user” equals “application user”
• Case B: “Database user” is mapped to a “login user”
• Case C: “Database user” is mapped to single-sign on users

In the first case, life is fairly simple: You can log into an application using the same name and password as your database user. For many basic applications, this is perfectly fine.

However, sometimes (Case B) you are facing the situation that various “login users” should point to the same database role.

Here’s an example: jane@example.com and jack@example.com are both fulfilling the role of “bookkeeper”. We definitely want to separate the logins, but behind the scenes, they have the same permissions. In small companies, this is usually the default way of handling things.

To map login names to database users, you use the CYPEX admin panel to achieve the proper configuration.

Case C is the most “enterprise-ready” way of handling user authentication. CYPEX connects to external directories and identity providers for single sign-on — see SSO → LDAP for directory/Active Directory authentication and its three role-mapping modes, and SSO → OIDC setup guide for federating login to Google, Microsoft, or any generic OIDC provider. There are a variety of ways to connect to single-sign on systems: First of all, you can use PostgreSQL onboard, which means using authentication and the “Case A”-style.

Depending on your infrastructure, various levels of complexity and customization of the authentication module might be required.

In general, it’s always advisable to strongly focus on database-side permissions. In particular, PostgreSQL Row-Level-Security has proven to be a valuable asset in real-world applications.

It makes sense to change passwords on a regular basis. In this section you’ll learn how to perform such a task and which features are supported by CYPEX:

The first thing to look at is how to change your own password. To do that, click on the user profile icon on the right side of the panel. A small overlay will appear and a click on the “SETTINGS” button opens the “change password” form.

To change the password, type in the “New Password” field.

The new password will be active instantly. However, active sessions will not be terminated unless a user proactively logs out. As long as the JWT (= JavaScript Web Token) is valid, users can continue working normally.

Changing passwords as admin for other users

In addition to changing your own password, administrators can also change other users’ passwords. Open Access Control → Users in the admin panel to see the list of users:

The pen icon opens the form for changing the password. A password change does not close sessions that are already open; the affected user keeps working until their access token expires (15 minutes by default) and the next token renewal re-checks the account:

The same “Edit User” form also lets administrators review the user’s organization memberships:

and inspect the account’s read-only details, such as user ID, username, role, and status:

Passwords for integrated users are hashed with bcrypt and validated against the policy stored in cypex.t_config under the key password_policy. The shipped default is deliberately permissive — minLength 4 with no character-class requirements — so tighten it before going live:

1
2
3

UPDATE cypex.t_config
SET value = '{"minLength": 12, "minUppercase": 1, "minLowercase": 1, "minNumbers": 1, "minSpecial": 1}'
WHERE key = 'password_policy';

The policy is read on each password change, so a new value applies to the next change without a restart. It governs passwords CYPEX manages; passwords held in PostgreSQL itself or in an external directory are governed by that system’s own rules.

• SSO → LDAP — directory/Active Directory authentication, role-mapping modes, and coexistence with local auth and OIDC.
• SSO → OIDC setup guide — federated login via Google, Microsoft, or any generic OIDC provider.
• Roles & Capabilities — the role each user maps to, and what it permits.
• Capabilities vs Data Scope — how a user’s role (capabilities) and organization membership (data scope) combine to decide what they can do and which rows they see.
• Organizations — the multi-tenant data boundary a user is mapped into.