SAML 2.0 SSO

SAML 2.0 lets the enterprise identity provider (IdP) authenticate users for QwenWork. Both sides establish trust: QwenWork provides service-provider (SP) information, and the IdP provides identity metadata. Register the SP information in the identity platform before importing its metadata into QwenWork.

​

Register QwenWork with the IdP

1. Open Users → Authentication → SSO login, add a SAML2 provider, and enter a name.
2. Create and continue to generate SP information. Copy Assertion Consumer Service URL, which receives sign-in results, and Audience URI, which identifies the service. Download metadata and the signing certificate if needed.
3. Create a SAML app in the identity platform and register the reply URL and service ID. Import the downloaded metadata where supported.
4. Assign the allowed users and obtain the IdP Metadata URL, metadata file, or manual Entity ID, SSO URL, and signing certificate.

Admin console: SP information and identity-provider configuration.

​

Import IdP information

Choose a metadata file, Metadata URL, or manual entry under provider credentials. Check the imported IdP identifier, sign-in address, and signing certificate. Request binding controls transport; SAML request signing and its algorithm control how QwenWork signs requests. Match the IdP requirements.

​

Set signatures and user attributes

QwenWork always verifies IdP signatures. With Require Assertion signature enabled, the assertion must carry a valid signature. Otherwise, a valid Response or Assertion signature is accepted.

1. Check NameIDFormat, response binding, signature KeyName, and whether SP metadata is signed.
2. Map external user ID from NameID or the actual returned Attribute Name.
3. Map name and other identity fields using actual attribute names. Plain names, URIs, and OIDs are supported; FriendlyName and XML paths are not.
4. Keep ID and name and at least one of email, phone, employee number, or account. Changing the ID source may change account association; existing users are not migrated or merged automatically.
5. Choose automatic creation, its default department, and optional seat assignment.

Advanced settings include reauthentication, login hints, encrypted assertions, clock skew, and authentication context. Change them when required by the IdP. Supply either AuthnContext ClassRefs or DeclRefs, not both. After SP Entity ID or protocol changes, save, download fresh SP materials, and update the IdP trust configuration.

​

Save, enable, and verify

1. Save the configuration and optionally validate metadata and certificates.
2. Enable the provider and SSO sign-in.
3. Sign in with an assigned ordinary user and check the account, name, and identity profile.

For signature failures, check certificate validity and both sides' signature requirements. For association failures, check actual NameID or Attribute values. Configuration validation does not verify actual sign-in or user creation.

​

Existing users and deleted records

SSO matches current users by external user ID only. A conflict-free match keeps the existing profile and sync source. Returned account, email, phone, or employee-number values conflicting with another user reject sign-in. Unmatched IDs follow automatic creation. An ID present only in deleted history does not restore the old QID. Sign-in fails with automatic creation off. With it on and conflict-free data, a new user and QID use the current returned profile, default department, and seat policy. Old roles, passwords, seats, and departments are not inherited; history remains. Return to: Users / Authentication / Authentication overview.