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,profileandemailscopes, - 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}/callbackwhere {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.