Company sign-in with OIDC

Connect your company's identity provider so users can sign in to RMON with their company account. You need a super administrator account, permission to register an OpenID Connect application with the provider, and an RMON subscription that includes company sign-in. See plans for availability.

Prepare the identity provider

Keep a working local administrator session open while configuring and testing company sign-in.
Have the installation administrator set RMON_PUBLIC_URL to the HTTPS address users open, for example https://rmon.example.com, and apply the environment change to the web service.
Register an OpenID Connect application for RMON with the provider. Obtain its Client ID, Client secret when required, and Discovery URL.
Allow the authorization-code sign-in flow. Arrange for the provider to return a stable subject, email address, email verification status and the groups needed for access mapping.
Allow RMON to reach the provider's discovery, token and signing-key endpoints over HTTPS. Users' browsers must also be able to reach the provider and the public RMON address.

The callback is specific to the provider's RMON slug. With slug company and the example public address, it is https://rmon.example.com/oidc/company/callback. Register the exact Callback URL displayed after saving the provider in RMON. Changing the slug or public address requires updating the registered callback.

Add the provider to RMON

Open Admin area → OIDC → Add.
Enter a unique Slug, such as company, and a Login button label, such as Company account.
Enter the supplied Client ID, Client secret and Discovery URL. Use the actual discovery address supplied by the provider administrator.
Keep Scopes as openid email profile unless the provider requires additional scopes. openid is required; requesting a scope alone does not guarantee that the provider includes the corresponding claims.
Under Advanced endpoints and claims, review the claim names below and set Allowed email domains, for example example.com.
Choose the user access options below. Leave Enabled off during preparation, then click Save provider. Reopen the provider to copy its Callback URL into the identity provider.

Field	Default	Use
Subject claim	`sub`	A stable user identity issued by the provider.
Email claim	`email`	Used for domain checks, creating users and linking existing accounts.
Username claim	`preferred_username`	Used to name a newly created RMON account.
Groups claim	`groups`	The company group names used by mappings. A nested claim can use a dotted path, such as `realm_access.roles`, when that matches the provider's actual response.

Require verified email checks email_verified. Have the provider include this claim for verified users. Domain entries contain domain names without @; list each allowed domain explicitly. Leaving the domain list empty applies no email-domain restriction.

When discovery is unavailable, fill in Issuer, Authorization endpoint, Token endpoint and JWKS URI from the provider's configuration. Add a UserInfo endpoint only when needed. When editing an existing provider, an empty Client secret field keeps the saved secret; paste a replacement to rotate it.

Choose how users get access

Option	Behavior
Auto-create users	Allows a first sign-in to create an RMON account when no matching account exists. It is disabled by default. Creating an account requires an email claim.
Link existing users by email	Connects a first company sign-in to the existing RMON account with that email. Keep email verification enabled and review existing email addresses before using it.
Default group / Default role	Give newly created users access when there are no active mappings or Sync mapped groups is disabled. Choose a limited starting role, such as guest. These defaults do not reset an existing user's roles.
Sync mapped groups	Applies active company-group mappings during sign-in. Use the next section to define which groups receive which roles.
Remove missing mapped groups	During sign-in, removes membership in groups covered by active mappings when the user no longer matches them. Other memberships are retained. Leave it off until the mappings and group claims have been tested.

For a controlled first test, create an ordinary RMON user with the intended email and group membership, leave Auto-create users off, and enable Link existing users by email and Require verified email. Later, enable automatic creation if company users should be able to join without individual provisioning.

If an account with the email already exists while linking is disabled, RMON rejects the first sign-in instead of creating a duplicate. Duplicate local email addresses also prevent automatic linking. A disabled local account cannot sign in through OIDC.

Example: give the operations team editor access

Create an RMON group named Operations under Admin area → Groups.
Have the provider administrator include rmon-operators in the test user's Groups claim. For example, {"groups": ["rmon-operators"]} matches a Groups claim of groups.
In the provider's row, open Manage group mappings → New mapping.
Set External group to rmon-operators, RMON group to Operations and Role to editor. Leave Priority at 100, enable Active, then click Save mapping.
Enable Sync mapped groups on the provider and save. If the test user does not already have an RMON account, enable Auto-create users as well.

Group names are matched without regard to letter case. Avoid overlapping mappings that assign different roles in the same RMON group. With active mappings and synchronization enabled, do not rely on Default group as a fallback for a new user whose company groups match none of them. The user needs an assigned RMON group to complete sign-in.

Membership synchronization happens when the user signs in. Removing a company group is not an immediate revocation of an already open RMON session. Follow your access-removal procedure and review session settings and RMON memberships.

Test before enabling team access

Verify the registered callback, enable the provider in RMON and save.
In a private browser window, open RMON and select the Company account sign-in button.
Sign in as the ordinary test user. Confirm the expected Current group and verify that the user can perform the intended actions with the assigned role.
Test an account that should be denied and confirm it receives no unintended access.
When using group synchronization, change the test user's company membership, sign out and sign in again, then verify the resulting RMON access.

Keep local administrator access available for recovery. Disabling the provider removes it as a company sign-in option; it does not delete existing RMON users. Repeat the sign-in test after rotating the client secret, changing claims or changing the public address.

Resolve sign-in errors

Symptom	What to check
No company sign-in button	Confirm that the provider is enabled, its settings are saved and company sign-in is available for your subscription.
Callback or redirect mismatch	Compare the complete displayed Callback URL with the provider registration, including HTTPS, hostname and slug.
State or nonce error	Start a fresh sign-in from the RMON login page in the same browser. Avoid reusing an old callback URL; check cookies and the configured public address if the failure repeats.
Discovery, token or signing-key error	Check the Discovery URL or explicit endpoints, Client ID/secret, certificate trust and connectivity from RMON.
Email missing, unverified or domain denied	Check Email claim, the provider's `email_verified` value and Allowed email domains.
No linked user or email conflict	Review Auto-create users, Link existing users by email, duplicate email addresses and whether the local account is enabled.
No group assigned or an unexpected role	Compare the returned Groups claim with active mappings, then review existing RMON memberships and the synchronization options.

Use the log guide to locate the failure. When requesting support, include the error name and time while omitting passwords, client secrets, tokens and full identity claims.