Skip to content
Documentation: Identity providers

Identity providers

Signing in with your company's identity provider: how it fits together, adding and testing a provider, and giving workspace roles from its groups.

Describes Ronne AI Marketplace 0.4.0.

How it fits together

Ronne can let people sign in with your company's identity provider (OpenID Connect): Google Workspace, Microsoft Entra ID, Okta, Keycloak, authentik, Auth0, or any other that publishes a discovery document. Root sets it up under Admin › Settings › Authentication, in the browser: nothing to type on the server.

  1. Add a provider from its preset, register Ronne at the provider with the redirect URI the form shows, and bring back the values it asks for (Adding a provider).
  2. Test it: Test connection, then Test sign-in with your own account at the provider. Nothing changes until it's on.
  3. Turn it on. The sign-in page shows Continue with <name>.

When someone signs in with it, Ronne decides who they are, in this order:

  • The provider must say the email is verified; otherwise they're refused.
  • A disabled account is refused.
  • Someone who signed in with this provider before is that same account, even if their email changed at the provider.
  • Otherwise, an account with this exact email is linked, and signed in, if the provider links by email and the email's domain is one it lists (root's account too). Their password keeps working too.
  • Otherwise, if the email's domain is one the provider lists, a new account is created: a user in global, with a personal workspace and no password, never root.
  • Anyone else is refused, with a message to ask root.

Then the provider's groups are applied, and the session lasts 24 hours at most and ends when the browser closes, so someone disabled at the provider normally loses access within a day. To cut someone off at once, disable their account in Ronne: that ends their sessions and tokens. With SCIM, the provider does it at its next sync. Two-factor sign-in isn't asked: the provider asks for its own second step. Root decides whether others may still use a password (Password sign-in), and root can always sign in with one (Lockout).

Adding a provider

Under Admin › Settings › Authentication › Identity providers, choose Add provider, then your provider's card. The form fills in what the preset knows, and beside it (under it on a phone) are the steps to follow at the provider. Each preset has its own guide below.

  • Provider id: 3 to 32 lowercase letters, digits and dashes, starting and ending with a letter or digit. It's in the redirect URI, so it can't be changed later.
  • The redirect URI, https://ronne.example.com/api/auth/sso/callback/<id>: register it at the provider exactly as shown, with Copy. The provider sends people back to this address after they sign in, and only to an address registered with it, which is why it must match: it's built from the instance's public address (PUBLIC_URL) and the id.
  • Display name, on the sign-in button; the issuer URL (exactly as the provider's discovery document says it, a trailing slash included; the preset builds it from the pieces it asks for), the client ID and the client secret, and the scopes (openid email profile, plus a groups scope some providers need).
  • The client secret is stored encrypted and never shown again: the form says Secret saved, with Replace.
  • Who may sign in: the email domains this provider signs in, and whether to link existing accounts by verified email. A new address in those domains gets an account on its first sign-in; an existing account with one is linked if linking is on. An account in another domain is never linked, so a provider can't take over an address it doesn't own. Empty: only accounts already linked sign in.
  • Groups: the groups claim and the group mappings (Groups and workspace roles).

Then, on the provider's page:

  1. Test connection checks the provider's discovery document, that it names the issuer you typed, and its keys, and says what it found.
  2. Test sign-in opens the provider in a new tab: sign in there with your own account. Back on the page, Ronne shows what it received (the email and whether it's verified, the name, the groups) and what a real sign-in would do with it (sign in, link, create, or refuse, and which workspace roles change). It changes nothing.
  3. Turn on needs a passing Test sign-in, by you, of the settings as they are now. Changing the issuer, the client, the secret or the scopes later turns it off until it passes again.

The panel shows each provider's state: Off, Tested, On, or Failing (its last test failed, three sign-ins in a row failed, or its secret can't be read after a restore), and when someone last signed in with it. Turn off stops sign-ins with it; links and group memberships stay. Delete removes it: accounts linked to it stay and can still use a password if they have one, and the workspace roles its groups gave are removed (in global, they go back to user). Every change is in the audit log.

Usual mistakes, with every provider: a redirect URI that differs by a slash or http/https; an issuer without the trailing slash its document has (or with one it hasn't); an email the provider doesn't mark verified; and a groups claim the application doesn't send. Test sign-in shows each.

Groups and workspace roles

A provider can give workspace roles from its groups. On the provider's form, set the groups claim (usually groups; the preset knows), then add rows: group → workspace → role (user, moderator or admin). A group is written exactly as the provider sends it, letter case included.

At every sign-in with the provider:

  • Each mapped group the person is in gives its workspace at least the mapped role. Two groups giving one workspace give the higher role.
  • A role a group gave goes when the person leaves the group (or drops to what another group still gives), at their next sign-in. Deleting the last mapping does the same.
  • A membership someone set by hand is never changed, even to raise it. Once someone changes a membership a group gave (in Members), it's theirs: groups leave it alone.
  • In global, which nobody leaves, a group can raise the plain user role everyone has; when the group goes, it goes back to user.
  • Root is never changed by groups, and groups never make anyone root.
  • A missing groups claim changes nothing. Entra leaves it out past 200 groups: assign only the groups Ronne maps to the application.
  • A mapping whose workspace was deleted is skipped, and the form warns about it. Personal workspaces can't be mapped.

Each change is in the audit log as a member change, marked as the provider's. Test sign-in lists the changes your own groups would make.