Skip to main content

Roles, Permissions & SSO

Enterprise teams get three fixed roles and a small set of specific permissions you can grant or deny on top of them — deliberately, instead of a large matrix of role names to memorize. This page explains how that model works and how to connect your identity provider so your team can sign in with SSO.

Three Roles, Not a Role Catalog

Every team member has exactly one of three roles: Owner, Admin, or Member. That's the whole list — Skillsmith doesn't let you invent custom role names, because a small, fixed set of roles is easier for your team to reason about and easier for you to audit later. Each team has exactly one Owner, who can't be removed or locked out (someone always has to be able to fix a misconfiguration), and any number of Admins and Members.

Role What it means
Owner Full control of the team, including billing. Exactly one per team, always.
Admin Manages team membership and, by default, can approve or deprecate private-registry skills.
Member Everyday team access — install and use shared skills, view the private registry — without admin-level actions.

Permissions: Widen or Narrow a Role Without a New Role Name

On top of the three roles, an Admin can grant or deny four specific permissions to individual team members. This is what lets you express something like "a reviewer who isn't a full Admin" or "a read-only teammate" without Skillsmith having to add role names like ReadOnly or Manager to the product. A broader role already includes everything a narrower one can do — Admin already covers everything Member can — so you reach those in-between shapes by taking a Member and adjusting exactly the permission that matters, not by picking a different role:

  • Want a trusted Member who can approve registry submissions without making them a full Admin? Grant that one Member registry:approve.
  • Want a teammate who can only browse and install, never publish or approve anything? Leave them as a Member and don't grant anything further — that's the read-only shape by default.
Permission What it lets you do Default
registry:approve Approve a pending private-registry skill submission Owner, Admin
registry:deprecate Mark an approved private-registry skill version deprecated Owner, Admin
team:manage_rbac Grant or deny these permissions to other team members Owner
team:manage_sso Configure SSO/SAML for the team (see below) Owner

Two rules keep this predictable. First, an explicit deny always wins over an allow — if an Admin is denied registry:approve for some reason, that denial holds even though Admins get it by default. Second, the Owner role can never be narrowed — you can't accidentally (or deliberately) strip the Owner's own access, which is what guarantees a team can never lock itself out entirely.

Roles and permission grants are configured through the Skillsmith MCP tools in your AI coding assistant, or the CLI — ask your assistant to show your team's current roles, or to grant or revoke one of the four permissions above for a teammate, and it resolves to the underlying RBAC management tools. See MCP Server for how tools are wired up, or CLI Reference for the equivalent commands.

Setting Up SSO

SSO lets your team sign in with your company's own identity provider (Okta, Azure AD, Google Workspace, or any SAML/OIDC IdP) instead of a Skillsmith password. It's self-service on Enterprise — an Owner or Admin with team:manage_sso sets it up directly, no onboarding engagement required. Setup has four steps:

  1. Claim your domain. Tell Skillsmith which email domain your team signs in with (for example, yourcompany.com).
  2. Verify it with a DNS record. Skillsmith gives you a TXT record to add to your domain's DNS. Once it's added, verification confirms you actually control the domain — this is what stops anyone else from claiming a domain they don't own. Verification is re-checked periodically to make sure the record hasn't been removed.
  3. Register your identity provider. Provide your IdP's SAML metadata (or the equivalent OIDC details) so Skillsmith knows how to redirect your team's sign-ins to it.
  4. Sign in. Team members go to www.skillsmith.app/login, choose Sign in with SSO, and enter their work email or domain. Skillsmith looks up your team's identity provider by domain and redirects them there to authenticate.

If SSO isn't set up for your domain yet, the sign-in page will say so and offer email/password sign-in as a fallback. If SSO was set up but is temporarily unavailable (for example, the domain verification lapsed), the sign-in page tells you that too, and points you to your team's admin rather than leaving you guessing.

Related Documentation