Skip to main content
Version: Current

Access control

Access control (Administration > Access control in the Designer's menu) is where an administrator decides who may do what: which scenarios a person may see, edit or deploy, who may call a deployed service, who may administer access itself. It is made of roles, principals and the bindings between them, with an access review and an audit log on top. Everything there is managed in the Designer; nothing has to be edited in a file.

Managing access needs the RBAC.Manage action. The built-in Admin role grants everything, present and future, and an administrator holds it; the audit log can also be read with RBAC.ViewAuditLog alone.

Roles​

A role is a named set of actions and a scope. Actions are named after what they allow - Scenario.View, Scenario.Edit, Scenario.Deploy, Scenario.Stop, Scenario.Test, Scenario.Create, Scenario.Archive, Scenario.Delete, Scenario.ViewLiveData and the like - and the scope says in which scenario categories they apply: All current and future categories or Specific categories. Global actions, such as RBAC.Manage, have no category.

Two actions are granted on the resources themselves rather than on categories, each with its own scope inside the role:

  • Scenario.Invoke - calling a deployed request-response scenario. Granted on chosen scenarios, or on whole categories (all of them, or a list);
  • MCP.Use - calling the tools of an MCP server. Granted on chosen servers.

The role editor offers the scenarios you may see that are not archived, and every MCP server. The grant follows the scenario or server, not its name: a rename does not move it, and when the scenario or server is deleted the editor flags the grant as pointing at nothing, which creating one with the same name later does not revive.

Roles are created, cloned and edited under Roles. A role grants nothing by itself until it is bound to a principal.

Principals​

A principal is whoever a role can be bound to. There are three kinds:

  • a local user - a person signing in with a login and a password kept by Nussknacker. Created under Principals with Local user: a login, a password you set or let the Designer generate (shown once), and the roles to grant;
  • a service account - a machine client: a CI pipeline, an integration, an MCP client, nu-cli on a server. It has no password and signs in only with its API tokens. Created under Principals with Service account: a name and the roles to grant; it can do nothing until it has a token;
  • an IdP group - stands for everyone an identity provider (OpenID Connect, OAuth2) reports with one of the group values it recognises. An installation that signs people in through an identity provider grants access this way, without a local account per person: a person holds the roles bound to every group their sign-in carries.

Role bindings​

A binding grants a role to a principal, optionally until a date: an expired binding grants nothing and the Effective permissions panel on the principal's page shows what the principal holds right now, including the roles granted on named resources or categories. A principal that holds the Admin role has full access regardless of its other bindings.

Access review​

Access review answers the question the other way round: for a category, who may do what in it - every principal with a role that reaches the category, with the actions they hold.

Audit log​

Every change made in Access control - a role created or edited, a binding added, removed or expired, a principal created or deactivated, an API token issued or revoked - is recorded with who made it and when, and can be read under Audit log.

See also​

  • API tokens - credentials for nu-cli, scripts, CI and other machine clients.