Permissions & access¶

Permissions control who can see and change what in Danbyte. Access is grant-based: you give people permission to do things - there are no "deny" rules. A person's access is the sum of everything granted to them directly and through the groups they belong to.

How access is built¶

Three pieces work together:

The four things a permission can allow on a type of object are view, add, change, and delete.

A few extra capability verbs apply to specific types and are never implied by change: connect (on devices - open a Connect launcher or the SSH terminal), reveal (on device credentials, wireless LANs and IPSec profiles - read the referenced secret), subscribe (on notification channels - self-service opt-in/out), view credits (on SLA agreements - see the service credits an agreement owes), set default (on topology views - choose the view Topology opens with for the tenant; tenant admins can without it, and its row limits say which views), and grant superuser (on users - see below). The permission form only offers these on the types that use them.

Granting superuser without being one¶

grant superuser on the user type lets its holder set or clear the Superuser flag on accounts - so a trusted user-admin can promote and demote without holding superuser themselves. The rules keep it contained:

• It counts only on a grant with no tenant scoping. Superuser is global, so a tenant-narrowed grant carrying the verb is ignored.
• On an existing superuser's account, a holder may only flip the flags - password, email, and reset links on superuser targets remain superuser-only, so the verb can revoke without inheriting account takeover.
• Arming grants superuser on an SSO group mapping needs the same verb - the mapping is a superuser grant.
• Every flip of the flag lands in the change log, whoever makes it.

Without the verb (or superuser), the Superuser checkbox isn't shown, and the API silently ignores the flag - fail closed, as before.

Built-in roles¶

Danbyte ships three ready-made groups so you don't have to build common roles by hand. They can't be deleted.

All object types leaves out access management¶

All object types covers every kind of object except Users, Groups and Permissions. A grant reaches those only by naming them, because adding or changing them is administration: whoever may change users, group membership or grants can give themselves anything. Holding change on Users is what makes someone an administrator - it opens the Admin pages and the tenant settings, and the deployment settings too when the grant is not limited to tenants. The Administrator group's grant names the three types; Operator and Read-only do not.

Upgrading to 0.17, where this rule arrived, names the three types on every all-object grant that was an administrator grant:

• one with view, add, change and delete that is limited neither to sites nor by row constraints (a tenant limit is fine - it stays a tenant admin), and is not the built-in Operator or Read-only grant,
• one carrying grant superuser,
• one held only by the Administrator group.

Every other all-object grant loses them: Operator-style, view-only, a site editor's "read all", and a "full control" grant limited to sites or rows - neither limit ever narrowed users, groups and permissions, so its holders would have managed every account. If that would have left nobody able to manage users, the accounts that could get a grant of their own, Kept user management (0.17 upgrade), with the three types and only the verbs each of them had - accounts with different verbs get one grant per set, named with its verbs (Kept user management (0.17 upgrade): view, change). People a custom grant reached come first, the Operator group's members only when nobody else could, and an upgrade note asks you to put your administrators in the Administrator group, then delete those grants. The shared grants stay trimmed, so nobody who joins those groups later inherits user management.

Managing access¶

These pages live under Admin → Access in the sidebar and are only visible to Administrators and anyone else granted change on Users.

Users¶

1. Go to Admin → Access → Users and click Add user.
2. Fill in the username, email, and name.
3. Choose how they get a password - see Inviting people.
4. Set the toggles you need: active, administrator, require two-factor sign-in, and the sign-in source (local account or company directory).
5. Assign one or more groups and the tenants the user may switch between.
6. Save.

Groups¶

1. Go to Admin → Access → Groups and click Add group.
2. Give it a name and an optional description.
3. Save, then attach permissions to it (below).

Built-in groups can be edited but not deleted.

Permissions¶

A permission is where you decide who may do what, and optionally to which rows.

1. Go to Admin → Access → Permissions and click Add permission.
2. Give it a clear name (e.g. "Edit production prefixes").
3. Choose the object types it applies to - pick specific ones, or All object types. All object types leaves out Users, Groups and Permissions; with it ticked, those three are offered on their own, and ticking them makes the grant an administrator grant.
4. Tick the actions you're granting: view, add, change, delete.
5. (Optional) Limit it to certain tenants. A tenant named here also grants access to that tenant: members of the group can switch to it without being added to it on their user page - the grant is the authorisation. Leave empty to cover every tenant the person can reach.

6. (Optional) Limit it to certain sites. This narrows the object types that belong to a site - devices, prefixes, IPs, VLANs, racks, interfaces, and the like - to those sites only. Object types with no site (VRFs, route targets, tags, catalog entries) are unaffected. Leave empty for all sites.

   Shared objects (a prefix or VLAN with no site - e.g. a supernet the whole company allocates from) are readable under a site-scoped grant: they're context everyone needs. They are never writable under one - creating or editing site-less objects is reserved for people whose grant isn't limited to sites. 7. (Optional) Add row constraints to narrow it to matching rows only - for example, only prefixes whose status is active. Without a constraint, the permission covers every row of the chosen types.

   A grant that names Users, Groups or Permissions takes neither a site limit nor row constraints: neither narrows those types, so the save is refused rather than looking narrower than it is. Grant them on their own. 8. Assign the permission to groups and/or users. 9. Save.

Site roles (local IT, in one click)¶

A common need is local IT who runs their own site but shouldn't touch others. Rather than hand-build the grants, open Admin → Access → Permissions and click Site role:

• Site editor - can add, edit, and delete everything in the chosen site(s), and can read everything elsewhere except users, groups and permissions. This is the local-IT recipe: full control of their own site, look-but-don't-touch everywhere else.
• Site viewer - read-only access to the chosen site(s), and nothing outside them. Use this when someone should only see their own site.

Pick the role, the site(s), and the users or groups to grant it to. Danbyte assembles the underlying permissions for you (a site-scoped edit grant plus an unscoped read grant for the editor; a single site-scoped read grant for the viewer). You can fine-tune or delete those permissions afterwards like any other.

An editor reads everything by default (the "see all, edit only mine" model, good for cross-site troubleshooting). Tick "Can only see their own sites" for a strict silo - the read-all grant is dropped and they see nothing outside their sites.

Set it up when you create the user¶

You don't have to make the user first and wire permissions second. The Create user (and Create group) form has a Site-scoped access section: tick it, choose Editor or Viewer, and pick the sites - the same grants are assembled in one step as the account is created. In a tenant with enhanced site separation on, the box is ticked by default (most new accounts there are local IT).

Letting site editors invite their own viewers¶

By default only an administrator can grant site access. If you turn on Settings → General → Let site editors invite their own viewers, a local site editor gains an Invite viewer button on the Access tab of the site(s) they edit. They can grant read-only access to their own site only - nothing wider:

• they can't create new editors (that stays an admin job),
• they can't reach any site they don't already edit,
• they pick from the members of the tenant, and grant to people, not groups.

This is enforced on the server, not just hidden in the UI, so it's safe to hand to local IT in a big multi-site deployment. The toggle is off by default.

What people see¶

The interface mirrors these grants so nobody is offered a button that would only fail:

• Sidebar links hide for sections a person can't view. If a whole section becomes empty, its heading disappears too.
• Add / Edit / Delete buttons hide on list and detail pages when the person lacks the matching grant.
• When a permission is limited by row constraints, Edit and Delete hide on the specific rows that fall outside it.

Picking people outside Admin¶

Some features name people without being user administration: notification subscriptions, script sharing, a site editor's viewer invite, and user or group custom fields. Their pickers list the active accounts that can work in the tenant - the tenant is on their user page, a permission limited to the tenant names them or their group, or they are a superuser - and the groups those accounts are in, for anyone who works with the feature - no permission on users needed. Superusers and deployment admins see every account. The address is shown only to people who may view users. A spreadsheet import resolves person and group cells against the same list for people without a permission on users.

Inviting people¶

When you create a user, choose how they get their password:

• Email an invite (recommended) - the person receives a one-time link to set their own password. You never see or handle their password.
• Set a password - you type an initial password yourself.

Editing an existing user, the same option lets you email a password-reset link.

Invite and reset links, and emailed sign-in codes, go through a tenant's own mail server only for accounts that work in that tenant alone. Those for administrators, and for people in more than one tenant, go through the deployment's mail settings, so a tenant's admin doesn't see them in their relay. If the deployment has no mail server of its own, they use the tenant's instead so they still arrive - set up deployment email to keep them out of tenant relays.

Two-factor sign-in (MFA)¶

You can require a second step at sign-in for any account.

• Turn it on per user with require two-factor sign-in.
• People set up their second factor under their own Preferences → Two-factor authentication, using either an authenticator app (scan a QR code) or a 6-digit code sent to their email.

Company directory (LDAP / Active Directory)¶

Optional and off by default. When an administrator connects your directory under Settings → Directory, people can sign in with their existing company credentials. Their Danbyte group membership is kept in sync from their directory groups every time they sign in, so the directory decides who's in what and Danbyte groups decide what that means. Only directory groups you've explicitly mapped grant anything.

What a directory login receives¶

On every LDAP login the account's Danbyte groups are re-synced from the mapped directory groups, and then:

• Tenants. A group's tenant-scoped grant is tenant access. Those tenants are added to the account's profile at login and the first one becomes the home tenant, so the account lands in the right place and appears in that tenant's user list without an admin editing the record.
• Superuser. Tick Grants superuser on a deployment-directory mapping and members of that directory group become superusers when they sign in - the same switch an SSO mapping has. Arming it needs the grant-superuser permission, it is not offered on a tenant directory, and a login never clears it: revocation stays a manual act on the user.

A permission whose actions include grant_superuser does not make its holders superusers - it lets them promote others. Use the mapping switch for the accounts that should be superusers themselves.

Single sign-on (SSO)¶

Optional and off by default. An administrator adds an identity provider under Settings → Identity providers (SSO) - an OpenID Connect (OIDC) or SAML 2.0 provider such as Entra ID, Okta, or Google Workspace. Each enabled provider appears as a Sign in with… button on the login page. When someone signs in through it, Danbyte reads their email, username, and name from the provider's claims and - if just-in-time provisioning is on - creates their account on first login. With just-in-time provisioning off, only accounts you've already created may sign in.

As with the directory, group access is driven by mappings: match a group the provider asserts (for Entra ID, a group object ID) to a Danbyte group, and only mapped groups grant anything. When you add a provider, register the callback URL shown on its edit screen as the redirect URI at your identity provider.

Related¶

• Change log - who changed what, when.
• Tags & custom fields - extend any object.