Users and roles

This page describes how to invite your colleagues, which roles to give them, how to limit their scope and how their access is protected.

Inviting a user

Inviting requires the create:users permission.

1. Open "Settings", tab "Users & Access", sub-tab "Users".
2. In the "Team Members" card, click "Invite User".
3. Enter the "Email", choose the role to grant, then click "Send Invitation".
4. The person receives an email, written in English, with a link valid for 7 days.
5. The link opens the "Join Ctadel" page, which recalls the granted role. The person fills in their "Full name", chooses a "Password" of at least 12 characters and clicks "Create my account". They can then sign in.

An invitation to an address that already has an account is refused. Sending a new invitation to the same address cancels the previous one.

The "Pending Invitations" card lists the invitations not yet accepted, with their author ("invited by ...") and their deadline ("expires in 6d") or their "Expired" state. Two actions: "Resend invitation" (a new link, again valid 7 days; permission create:users) and "Cancel invitation" (permission delete:users).

Roles and permissions

A role is a set of permissions and a scope. Three system roles exist when the instance is created; they can be neither renamed nor deleted, but their permissions can be edited ("System role - you can edit permissions but not rename it").

Role	Scope	Permissions
Global Admin	All projects	All
Global SecurityEngineer	All projects	Every read; updating findings and resources; creating and updating policies; starting scans; saved queries; comments; ignore rules. No users, roles, settings or SSO.
Global Viewer	All projects	Read-only

The first administrator account of the instance holds "Global Admin". A person holding several roles picks the one in use from the user menu, entry "Switch Role".

Creating a role

From the "Roles" sub-tab (permission create:roles; read:roles to view), the "Create Role" button opens a form:

• "Name" and "Description".
• "Project scope": "All projects (global)" or a selection of projects.
• "Folders": one or more folders; the role then grants access to every account in the subtree, including those added later. Left empty, only the project scope applies.
• "Permissions", grouped by domain: "Resources", "Issues", "Policies", "Scans", "Users", "Roles", "Settings", "Graph", "Saved Queries", with the actions "Read", "Create", "Update", "Delete". The other permissions (comments, ignore rules, reading by finding type, SSO) are shown under their raw key, for example read:findings:cspm or manage:sso.
• The "Copy ..." buttons take the permissions of a system role as a starting point.

The read:issues permission grants reading of every finding type. For a role that must see only part of the findings, tick the wanted read:findings:<type> permissions instead (CSPM, vulnerabilities, toxic combinations, DSPM, secrets, IaC, KSPM, HCR, CDR).

A role can only be deleted when nobody holds it; reassign the users first.

Restricting a user to projects

The scope belongs to the role, not to the user. To limit a person:

1. Create a role whose "Project scope" or "Folders" cover only what they must see.
2. In "Team Members", open "Edit Assignments" on their account.
3. Under "Role Assignments", add or remove roles with "Add Assignment"; each line shows its scope: "Global", "Folder-scoped" or "N projects".
4. Click "Save Assignments".

A person holding only scoped roles sees only those projects; the project selector at the top of the application is limited to them. Permissions are re-read on every request: a removed role takes effect without signing in again. Removing the "Global Admin" role from the last person holding it is refused.

Assignments created by single sign-on are marked as SSO-managed and re-applied at every sign-in; see Single sign-on.

Deleting an account

There is no temporary suspension. Two options:

• Remove all of their roles: the account stays, shown with "No role", and can no longer read anything.
• "Delete" the account (permission delete:users), after confirmation: "Are you sure you want to delete this user? This action cannot be undone." The last "Global Admin" cannot be deleted.

Sign-in code

Password sign-in takes two steps on /login.

1. "Email" and "Password". The server checks the pair without opening a session.
2. A 6-digit code is sent to the account address ("A 6-digit code has been sent to ..."). The person types it under "Verification Code". The session is created only after this check.

The code is valid for 10 minutes; at the fifth wrong attempt it is cancelled and a new one must be requested with "Resend code". Sending is limited to 5 codes per 5 minutes, per address and per IP address; each new send cancels the previous codes. This code cannot be turned off per user. People who sign in through SSO skip this step: their identity provider authenticates them.

Password policy

• At least 12 characters, when the account is created and when the password is reset. No other composition rule.
• Passwords are stored hashed (bcrypt).
• "Forgot password?" on /login sends a link valid for 24 hours when the address matches a password account. The answer is the same in every case. Limit: 5 requests per 15 minutes per IP address, 5 per hour per address.
• A new password invalidates the sessions opened with the old one.

Session lifetime

The session is a signed token stored in an httpOnly cookie. Its lifetime is set by Ctadel when your instance is configured: 12 hours by default, between 1 and 168 hours on request. It cannot be changed from the interface. When it expires, the person signs in again with their password and a new code.

On every request, the roles of the session are re-read: a removed role takes effect without signing in again.

Limitations

• No temporary suspension of an account: remove the roles or delete it.
• The second factor is a code sent by email. No authenticator application (TOTP), no hardware key, no per-user opt-out.
• The password policy is limited to length. No expiry, no history, no password change from the application once signed in: the only path is "Forgot password?".
• The invitation email is sent in English whatever the language of the instance; the later emails (welcome, code, reset) follow the user's language.
• No account lockout after repeated failures; protection relies on rate limits per IP address and per email address.
• Google or GitHub sign-in, mentioned in the text of the "Require SSO sign-in" card, is not enabled on a customer instance.
• The read:findings:aispm permission appears in the role form but has no effect: AI-SPM findings can only be read with read:issues.
• No SCIM provisioning; SSO accounts are created at first sign-in (see Single sign-on).