Authentication & roles

OIDC sign-in and role-based access.

Access to the BARRY admin UI is protected by OpenID Connect (OIDC) with role-based access control. There is no local user table — users and their roles are managed entirely in your identity provider.

How login works

The runtime uses the Backend-for-Frontend (BFF) pattern:

• The browser SPA never sees access tokens.
• The server runs the OIDC authorization-code flow and issues a secure, http-only session cookie.
• Signing out clears the cookie and triggers the provider's end-session endpoint.

In practice this is invisible to users: visiting the UI redirects you to your identity provider to sign in, then back into the app.

Identity providers

The runtime ships with two providers wired in; exactly one is active per server, selected by configuration at startup:

• Keycloak / generic OIDC — the default. Self-hosted alongside the runtime, or pointed at any standards-compliant OIDC provider (Authentik, Janssen, Auth0, …). Setup: Identity Provider: Keycloak / OIDC.
• Microsoft Entra ID — the configurable alternative. Setup: Identity Provider: Microsoft Entra ID.

Switching providers is an administrator action — change the Auth:Provider setting and restart the server. It cannot be done from the UI, and running both providers at once is not supported.

The three roles

Every user is mapped to one of three roles in the identity provider. The runtime reads the role from the user's token on sign-in.

• Admin — full control: register clients, manage transports and all templates, change runtime settings, manage events.
• Operator — operate clients and trigger transports, but no access to settings.
• Viewer — read-only access to clients, transports, and run history.

Roles are hierarchical in the backend: an Admin satisfies any Operator or Viewer check, and an Operator satisfies any Viewer check. You assign a user a single role; you do not need to compose them.

What a user with no role sees

A user who authenticates successfully but has no BARRY role assigned signs in, but the application shows an Access denied page (the server returns no role for them). To fix it, assign the user a role in your identity provider — see the provider-specific chapter.

Managing users

The Settings → Users & roles page surfaces the active provider and a deep link to its admin console, because user and role management happens in the provider, not in BARRY. See Runtime Settings & Administration.

Machine authentication

Beyond UI login, the runtime can authenticate itself to external storage and warehouse systems. Most destinations use Managed Identity or a service principal directly. For Keycloak-centric deployments, a Keycloak service account can also be exchanged for cloud credentials (Workload Identity Federation for Azure, web-identity for S3). See the machine-auth section of Identity Provider: Keycloak / OIDC.