Skip to main content
For SAML sign-in problems, first compare the entity ID, sign-on URL, certificate, and attribute mappings with the current values shown by Biqli. Confirm that the user is assigned to the application in the identity provider. For SCIM problems, verify the base URL, token, directory assignment, and provider provisioning logs. A successful test connection does not guarantee that every user is assigned for synchronization. Avoid locking out every administrator while testing enforcement. Keep one authorized recovery path, follow the provider-specific guide, and share correlation IDs or timestamps with support instead of certificates, tokens, or passwords.

​
SAML checklist

  • The user is assigned to the provider application.
  • Entity ID, reply or assertion URL, and sign-on values match Biqli exactly.
  • The current signing certificate is active and not expired.
  • Required email and identity attributes use the expected claim names.
  • Provider and Biqli clocks are accurate enough for assertion validity.

​
SCIM checklist

  • The base URL and bearer token come from the current Biqli configuration.
  • Provisioning is enabled for the intended users or groups.
  • The provider log shows whether create, update, or deactivate failed.
  • A previous account with the same identity is not causing a conflict.
  • Token rotation was completed on both sides.
Test one change at a time and record the exact UTC timestamp, user identifier, provider request or correlation ID, and Biqli result. Redact assertions and tokens before sharing diagnostic output. If enforcement caused a lockout, use the recovery administrator rather than repeatedly changing entity or certificate values without a controlled test.