Please use the information provided in the From ZenQMS... section to complete your SAML configuration. Once completed, you may send the metadata URL or file to ZenQMS for verification.
(IdP = identity provider, SP = service provider)
From ZenQMS (SP) for client (IdP) configuration
You can make use of one of our pre-configured app gallery entries for various SSO services (e.g., Azure AD, Okta, OneLogin), import the attached metadata files for the sandbox and production environments, or manually configure the following details:
- 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"
- Assertion Consumer Service (ACS) URL
- In production, this will be “https://sso.zenqms.com/SAML/AssertionConsumerService”.
- In the "sandbox" environment, this will be "https://sso-sandbox.zenqms.com/SAML/AssertionConsumerService".
- In the test environment, this will be "https://sso-test.zenqms.com/SAML/AssertionConsumerService".
- (optional) SP Certificate file
- We can provide this if SAML requests need to be signed (Please confirm if you need requests to be signed). The signing certificate can also be found in the metadata files noted above.
Electronic Signature Options
For electronic signatures within the application (e.g., approving documents, completing training), you have the following options:
- PIN number -- this is the default method. The first time users attempt to sign something, they are emailed a PIN number that is valid for the duration of the current session until they're logged out.
- SAML re-authentication -- when signing, users are redirected back to the identity provider login screen and then back into ZenQMS once authenticated. This is simple to configure on our end and made possible via the SAML ForceAuthn attribute. While many do, not all SAML 2.0 compliant backends support this attribute.
- LDAP -- a bit more difficult to configure and not commonly available, but a more familiar workflow for users. In order for this method to be supported, our servers must be able to reach the LDAP servers over the internet. See below for further details.
Additional information required for LDAP e-signatures
- Hostname or IP Address
- Port Number
- Authentication Type (e.g. Basic)
- 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):
- Search Base DN (e.g. "DC=phakepharma,DC=com", the path from which all user accounts can be queried).
- DN and password of an account authorized to query the user's email address (needed only if users cannot query their own account).
- Query filter for returning only the relevant data containing the user's email address (e.g. "(objectClass=inetOrgPerson)" or "(cn=*)").
- 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".
- 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: 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206
- Sandbox and Test: 220.127.116.11