Give each person the access they need

Authentication establishes which user is signing in, through a local account or a supported external identity system. Authorization determines which projects and actions that Semaphore user can access. Enabling SSO does not by itself assign the correct operating role. Design the two together: confirm identity linking, add the intended project membership, and test the actual actions available to a representative account before delegating an operational task.

The built-in Task Runner role can run every template in its project. To delegate only selected jobs, use an Enterprise custom role with grants on the chosen Task Templates and Workflows and no project-wide run permission. Permissions from all assigned roles add together, so a broader role held alongside it can still let the person run other templates.

Yes. An Enterprise custom role combines project-wide permissions with grants on individual objects. Leave the project-wide permissions off and add only the Task Templates and Workflows the role is for, choosing view, run or edit on each, plus approve on a Workflow. A global role is defined once and reused across projects; a project role stays inside the project that created it. Users can hold several roles and their permissions are additive, so review the complete set when restricting access to sensitive automation.

Individual-object granularity applies to Task Templates and Workflows. Do not assume a project-wide permission to manage inventories, repositories, variable groups, or Key Store entries can be narrowed to one of those objects. Use project boundaries and the available role model deliberately when separating operational responsibilities. If your access design depends on another kind of resource-level restriction, verify that exact requirement before relying on it in production.

The documented authentication options are local accounts, LDAP and Active Directory, OpenID Connect, and JWT passed from a trusted reverse proxy, with availability shown in the current plan comparison. An externally authenticated user still has a Semaphore user record and needs the intended project access. Check provider identifiers and account-linking behaviour before changing an existing setup. Do not assume that enabling an identity provider automatically maps all directory groups to the roles your authorization design requires.

Maintain a tested local administrative recovery path alongside the external authentication configuration. Document who owns it, where the required credentials are held, and how access is exercised during an outage. Test the process before an incident rather than discovering that every administrator depends on the same unavailable provider. After recovery, inspect the relevant account and project access so temporary operational changes do not become unintended permanent permissions.

Yes. The built-in Task Runner role can run project templates while leaving other resources read-only. For access to selected jobs, use an Enterprise custom role with grants on those Task Templates and Workflows. Check all roles assigned to the member, because permissions are additive. A prepared Task Template keeps the execution setup available for the team.

The Guest role gives read-only project access. A guest can inspect project information and task results without running tasks or changing settings. Add the person to the appropriate project team and review their other roles as well. A broader role assigned alongside Guest can grant additional permissions.

Enterprise group mappings associate an OIDC provider group with a role in a Semaphore project. Configure the groups claim in the provider and add a mapping for the intended project and role. Semaphore refreshes these assignments when the person signs in through that provider, so changes are applied at the next sign-in rather than immediately to an existing session.

Yes. Enable TOTP in the server configuration so users can enrol an authenticator app for their local account and enter its time-based code after the password. Enrolment produces a recovery code for the sign-in where the authenticator is unavailable. Enabling the option does not force every account to enrol, so treat adoption as a process. The same configuration area sets an absolute session limit, which ends a session after a fixed lifetime regardless of activity.