Setup and configuration - Enterprise SSO

What this integration does

Enterprise SSO lets people sign in to DockRay through their company's OpenID Connect identity provider - one login instead of a separate panel password. For a subscriber account this is a paid plan component (custom_sso); Dock staff get a separate platform configuration, set up only by a superadmin, which costs nothing, since Dock does not buy its own plan component from itself. The integration never creates accounts - it only logs in an existing user from the correct scope.

What to prepare with the identity provider

• an OpenID Connect application using the Authorization Code flow with PKCE,
• the openid, profile and email scopes,
• a public HTTPS discovery address - discovery and every endpoint must be publicly reachable, private and reserved addresses are rejected,
• a provider that returns a confirmed e-mail address (email_verified) - without it, login fails regardless of everything else being configured correctly.

Configuring it in DockRay

In Settings → Enterprise SSO, enter a connection name, an organisation identifier (globally unique, going straight into the login address), the issuer address, and the Client ID and Client Secret. A superadmin configures the platform connection for Dock staff here; a subscriber account's owner or admin configures a connection strictly for their own account - two separate scopes, never one shared screen with a toggle.

The return address at the provider

At the identity provider, enter this exact Redirect URI:

https://dockray.io/sso/{identifier}/callback

where {identifier} is the organisation identifier entered in DockRay. The general login screen /sso asks precisely for that identifier - the e-mail domain does not select the connection, since one account can use several mail domains at once.

The first test

Save the configuration and sign in with a company account that has a counterpart in DockRay (the same, confirmed e-mail address). On the first login DockRay finds the user by e-mail and permanently binds them to the pair of configuration + sub returned by the provider; every later login relies on that identifier, not the e-mail address. If the account has the second factor switched on, the panel will ask for it exactly as it would after a password login.