SSO Data Request Form

Please send this information to with copying your key account administrators.  We will coordinate launch date for sandbox and go-live for production thereafter.

(IdP = identity provider, SP = service provider)

From the member/client for entry into ZenQMS:

  1. IdP Entity ID
  2. IdP Certificate file
    • For ADFS: In the ADFS 2.0 MMC snap-in select the certificates node and double click the token-signing certificate to view it. Click the 'Details' tab then 'Copy to File'. Save the certificate in DER format.
  3. IdP login URL (e.g.
  4. The Subject Name ID in the SAML response must be set to the user's email address or the email address must be included as an attribute. If the email address is included as an attribute, we need the name of that attribute.

From ZenQMS for member/client configuration (please confirm if this is what you expect from us):

  1. SP Entity ID
    • In production, this will be “urn:zenqms:SSO”
    • In the "sandbox" environment, this will be "urn:zenqms:SSOSandbox"
    • In the "Test" environment, this will be "urn:zenqms:SSOTest"
  2. Assertion Consumer Service (ACS) URL
    • In production, this will be “”.
    • In the "sandbox" environment, this will be "".
    • In the test environment, this will be "".
  3. (optional) SP Certificate file
    • We can provide this if SAML requests need to be signed (Please confirm if you need requests to be signed)

For Signatures using SAML 2.0 Force Authentication/Re-auth

If you have a SAML 2.0 compliant IdP/backend AND it supports the force authentication/re-auth ('ForceAuthn') attribute in the SAML2 Core spec please let us know if this is the case, since it would allow you users to log in and verify electronic signatures with the same login/password combo (e.g. no PIN required).  

For LDAP configured for e-signatures, this is the additional information we would need for that:

Basic Information

  1. Hostname or IP Address
  2. Port Number
  3. Authentication Type (e.g. Basic)
  4. Distinguished Name Pattern for Binding - If the username entered is insufficient detail for binding to the LDAP server, the DN pattern to use with the username entered (e.g. "uid=<username>,ou=Users,dc=phakepharma,dc=com")

For LDAP Queries (to verify that the email address of the credentials supplied match the email address in our system)

  1. Search Base DN (e.g. "DC=phakepharma,DC=com", the path from which all user accounts can be queried).
  2. DN and password of an account authorized to query the user's email address (needed only if users cannot query their own account).
  3. Query filter for returning only the relevant data containing the user's email address (e.g. "(objectClass=inetOrgPerson)" or "(cn=*)").
  4. List of username attributes that might be entered by users for authenticating/binding.  For Active Directory this is usually "userPrincipalName" and "sAMAccountName".  For other LDAP servers, this is often "uid".
  5. Name of the email address attribute returned by the query (e.g. "mail").

If you need to open firewall access to our servers to accommodate LDAP requests, these are the IP addresses we currently use for our environments:

  • Production:,,,,,
  • Sandbox and Test:

Azure AD/Office 362 SSO Users:

You will need to use the tutorial found here to add it to your account and then send us the metadata URL so we can extract the signing cert and other info we need.

OneLogin and other preconfigured IdP apps

ZenQMS Supports other 3rd party IdP preconfigured SSO apps.  Please let us know if you can't find ZenQMS in the application list of the tool you are using and we will investigate.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.