SSO
Single sign-on connections let members sign in through the identity provider of the enterprise instead of a Soln password.
Open Account Center, then select SSO.
New connections are enabled as soon as they are saved.
For the DingTalk, Feishu, and WeCom plugins, installation creates the corresponding SSO connection. Use the callback and entry URLs shown by the plugin rather than manually creating a duplicate connection. See Enterprise Identity Plugins and the provider guides for DingTalk, Feishu, and WeCom. WeCom authorized sign-in can also add a missing plugin member binding.
Before You Start
- You need an identity provider administrator who can create an application, read its metadata, and register the Soln service provider values
- You need the enterprise email address of the members; the email claim or attribute must match a member of this space
- Keep the Soln connection dialog open while you register values on the identity provider side, because the callback URL and the service provider values are shown there
Set Up An OpenID Connect Connection
- In the identity provider, register a web application and note its issuer address, client ID, and client secret
- In Soln click + next to the SSO menu entry to create a connection. Keep the dialog open
- In the identity provider, set the redirect URI to the Authorization callback URL shown in the Soln dialog
- In Soln enter the connection name, the connection code (lowercase letters, digits,
_,-), the issuer address, the client ID, and the client secret. The code and the identity protocol cannot be changed later - Choose the token authentication method that matches the client registered in the identity provider: Client Secret Basic, Client Secret Post, or public client without a secret
- Keep the scopes
openid,profile, andemail, then map the claims to the names the identity provider actually returns. The defaults aresub,email,email_verified, andname - Choose the email trust policy: require the email verified claim to be
true, or trust the email returned by the provider. The verified claim is only read in the first case - Save the connection, then open the Launch URL from the connection list to start a workspace sign-in and check that the sign-in lands on the expected member
OpenID Connect Defaults
| Field | Default | Other options |
|---|---|---|
| Issuer address | – | The issuer URL of the identity provider, for example https://identity.example.com |
| Token authentication method | Client Secret Basic | Client Secret Post, or public client without a secret |
| Scopes | openid, profile, email | The same three scopes |
| Claim mappings | sub, email, email_verified, name | Any claim name the identity provider returns |
| Email trust policy | Require the email verified claim to be true | Trust the email returned by the provider |
| Authorization callback URL | Shown read-only by Soln | Register it as a redirect URI in the identity provider |
Set Up A SAML 2.0 Connection
- In the identity provider, create a SAML application. You need the service provider values from step 3 first, so start with the connection in Soln
- In Soln click + next to the SSO menu entry, choose SAML 2.0, and provide the identity provider metadata, either as a metadata URL or as metadata XML
- In the identity provider, register the values that the Soln dialog shows under the service provider configuration: SP Entity ID, ACS URL, SLO URL, and the SP certificate
- In Soln configure the request binding, the signature and digest algorithm, the NameID format, the signature and encryption requirements, IdP-initiated login, the authentication context and its comparison, the accepted clock skew, and the maximum assertion age
- Fill the SAML attribute mappings with the attribute names the identity provider returns for the user identifier, email, and name
- Save the connection, then open the Launch URL to verify the sign-in
- Replace the SP certificate with the rotation steps below when it must be renewed
SAML 2.0 Defaults
| Field | Default | Notes |
|---|---|---|
| Metadata source | URL | Metadata URL or metadata XML |
| Request binding | HTTP-Redirect | HTTP-POST |
| Signature algorithm | sha256 | sha512 |
| Digest algorithm | sha256 | sha512 |
| Require signed assertions | On | Turn off only when the identity provider cannot sign assertions |
| Require signed responses | On | Turn off only when the identity provider cannot sign responses |
| Require encrypted assertions | Off | Enable when the identity provider must encrypt assertions; the identity provider needs the SP certificate |
| Allow IdP-initiated login | On | Turn off to accept only sign-ins started from Soln |
| Force re-authentication | Off | Enable to ask the identity provider for authentication on every sign-in |
| NameID format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress | Any NameID format the identity provider supports |
| Authentication context | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport | Removed when "do not send authentication context requirements" is enabled |
| Context comparison | exact | minimum, maximum, better |
| Accepted clock skew | 120 seconds | Raise it when the identity provider clock drifts |
| Maximum assertion age | 5 minutes | Rejects older assertions |
| Attribute mappings | nameID, email, displayName | Must match the attributes the identity provider actually sends |
Values To Register On The Identity Provider
| Soln value | Identity provider field |
|---|---|
| SP Entity ID | Audience URI / SP Entity ID |
| ACS URL | ACS URL / Reply URL / Assertion Consumer Service URL |
| SLO URL | Single logout URL |
| SP certificate fingerprint | Signing or encryption certificate of the service provider |
| Authorization callback URL (OpenID Connect only) | Redirect URI / Callback URL |
Identity providers name these fields differently; register the values from the Soln dialog under the matching concept.
Verify The Connection
- Open the Launch URL of the connection, or share
.../auth/start?sso=enterprise&provider=<connection code>(or&launch=<launch URL>) with the members who should use this connection - Sign in with a real enterprise account and confirm that the sign-in lands on the matching member instead of creating a new one
- Check User Login Activity: the new session appears with its sign-in method, IP address, and device
Troubleshooting
| Symptom | What to check |
|---|---|
| Assertion signature validation fails | Identity provider metadata and certificate, the signature and digest algorithm, and whether signed assertions or responses are required |
| The identity provider signs in, but Soln rejects the result | The attribute mappings and NameID format must match what the identity provider sends |
| The email is reported as unverified | The email trust policy and the verified claim: with the default policy the claim must be true in the ID token |
| Sign-in fails with a time error | The clock difference between the identity provider and Soln; raise the accepted clock skew |
| Encrypted assertions cannot be decrypted | The certificate rotation was not completed: let the identity provider reload the SP metadata, then activate the pending certificate |
| The redirect URI is rejected | Copy the exact callback URL from the Soln dialog into the redirect URIs of the identity provider |
Connection List
| Column | Description |
|---|---|
| Connection | Connection name |
| Protocol | OpenID Connect or SAML 2.0 |
| Launch URL | Address that starts the workspace sign-in with this connection: the runtime origin plus /auth/start?sso=enterprise&launch=<launch URL> |
| Status | Enabled or disabled |
| Updated at | Time the connection was last changed |
Search matches the connection name, code, issuer address, and client ID. Row actions are Edit and More, which contains the certificate actions and Delete; deleting a connection also deletes the external identity bindings it created.
Create Or Edit A Connection
Common fields:
| Field | Description |
|---|---|
| Connection name / code | Display name and stable code of the connection |
| Identity protocol | OpenID Connect or SAML 2.0 |
OpenID Connect fields:
| Field | Description |
|---|---|
| Issuer address / Client ID / Client Secret | Credentials of the registered application at the identity provider. Leaving the secret empty keeps the current one |
| Token authentication method | Client secret basic (default), client secret post, or public client without a secret |
| Scopes | Scopes requested during sign-in: openid, profile, and email, selected by default |
| Claim mappings | Claims that provide the user identifier, email, and name |
| Email trust policy | Either require the email verified claim to be true in the ID token (default), or trust the email returned by the provider |
The default claim mappings are sub for the user identifier, email, email_verified, and name. The email verified claim is only read when the trust policy requires it.
SAML 2.0 fields:
| Field | Description |
|---|---|
| Identity provider metadata | Required. Metadata URL with a valid URL, or the metadata XML |
| Request binding | Required. HTTP-Redirect or HTTP-POST |
| Signature and digest algorithm | Required. Algorithms used for signing and digesting requests |
| NameID format | Optional identifier format expected by the identity provider |
| Signature and encryption requirements | Require signed assertions, signed responses, or encrypted assertions |
| Identity provider initiated login | Allows sign-in started by the identity provider |
| Force re-authentication | Requests authentication on every sign-in |
| Authentication context | Required unless "do not send authentication context requirements" is enabled; it also sets how the comparison is evaluated |
| Clock skew and assertion age | Required. Accepted time difference and maximum assertion lifetime |
| Attribute mappings | Required. SAML attributes that provide the user identifier, email, and name |
Service provider configuration shows the SP Entity ID, ACS URL, SLO URL, the active SP certificate SHA-256 fingerprint, and the certificate expiry time, plus the pending and previous certificate fingerprints when a rotation is in progress. These values are given to the identity provider.
SP Certificate Rotation
Each step asks for confirmation first.
- Generate pending certificate publishes a new SP certificate to the metadata. Let the identity provider read the new metadata before continuing
- Activate pending certificate starts using the new certificate for signing and encryption while the previous one stays available for verification. Only activate after the identity provider has synchronized the latest SP metadata
- Retire previous certificate removes the previous certificate from the metadata. Do it only after the identity provider uses the current certificate steadily; assertions still encrypted with the previous certificate can no longer be decrypted
Deleting a connection also deletes the external identity bindings it created.