Members, roles, invites, and authentication providers

This page covers who can do what inside an organization: memberships, invitations, custom roles, and optional enterprise login configuration.

Memberships

A membership links an account to an organization and assigns roles.

• Removing all roles does not necessarily remove membership — behavior depends on product rules; treat role assignment as the source of capability.
• Members only see projects they have permission to read (project list may filter).

Typical admin tasks

• Invite a colleague by email.
• Assign owner / admin / member style roles (exact names depend on your deployment’s seed roles).
• Revoke access when someone leaves.

Invitations

Invites are pending memberships: a user receives a link or email, accepts, and becomes a member with the pre-assigned roles.

Good practices

• Use least privilege — start with read-only on production projects.
• Separate billing admin from infrastructure admin where possible.

Roles and permission keys

Loopback’s authorization model is resource-scoped:

• Organization resources (billing, domains, bundle repos, notification channels, …).
• Project resources (object storage, project load balancers, DNS zones, monitoring, …).
• Workspace resources (hosts, kubeconfig, Kubernetes API proxy, agent tokens, workspace load balancers, scaling groups, …).

A role is a named collection of allow rules on these permission keys (e.g. project.workspace, project.workspace.host, project.workspace.kubernetes.kubeconf).

Customer-visible effect

• Two “Admin” users might differ if one’s role omits kubeconfig download or host create.
• Custom roles let you model SRE, Finance, Read-only auditor.

Full key list in human language: Access control & permissions.

Authentication providers (organization IdP)

Organizations can configure authentication providers so users sign in to Loopback with corporate IdP (OIDC/SAML patterns depending on product version).

Not the same as Kubernetes OIDC

• Loopback login — access to the Loopback UI/API as a person.
• Kubernetes OIDC — access to kubectl against your cluster’s API server using kubectl oidc-login (configured during cluster provisioning).

You may need both: IdP for the portal, and group claims mapped for cluster RBAC.

Related reading

• Organizations overview
• Security & permissions
• Access & kubeconfig