SSO instructions

Steps to onboard a new customer for SSO configuration.

Follow these steps to get onboarded for SSO:

1. The organization’s IT department formally requests Single Sign-On (SSO) integration with QIAGEN Digital Insights (QDI) through QDI Customer Support. QDI Customer Support then provides the requirements for SAML-based SSO integration. The <NameID> is a required element in the SAML authentication response, which must also include the following claims: email address, first name, and last name.

2. QDI Customer Support provides the organization’s IT department with a list of SSO-supported products licensed to the organization, along with the domains whitelisted under those licenses and the users covered by them. Based on this user list, QDI Support notifies the IT department if any inconsistencies are found in the username portion of the email addresses, as these could potentially lead to failed SSO logins.

3. The organization’s IT department confirms which domains use the same identity provider. Only domains that share a common identity provider can be included in a single SSO configuration. If a license involves multiple identity providers, a separate SSO integration must be set up for each one.

4. When an organization has a license for multiple SSO-supported products, QDI Customer Support informs the license administrator(s) that SSO integration applies to all products collectively; it cannot be enabled for only a subset of these products. However, SSO can be deactivated on a per-user basis if needed.

5. The organization's license administrator(s) confirm the QDI products covered in the SSO integration.

6. QDI Customer Support registers a representative from the organization’s IT team as the SSO administrator. This administrator is responsible for configuring the SSO integration through the SSO Configuration page in the QDI Admin Tool. To streamline the setup, the organization's IT team is encouraged to share the Identity Provider (IdP) metadata XML with the QDI Customer Support for validation. The Service Provider (SP) metadata XML can be downloaded directly from the SSO Configuration page.

7. After the SSO configuration is completed, the organization’s IT team informs internal users about the implementation, schedules the switchover to SSO at a time that avoids disrupting ongoing analyses, and provides ongoing support for authentication-related issues.

How to use login with SSO.

Please visit this

Frequently Asked Questions

Q - Which are the supported protocols to implement SSO?
A – Our implementation supports Service Provider-Initiated SAML v2 Single Sign-On.

Q - Is SSO available for all QIAGEN Digital Insights applications?
A – No. SSO is available for Ingenuity Pathway Analysis, QIAGEN Clinical Insights Interpret, QIAGEN Clinical Insights Interpret Translational, and applications hosted in the My QIAGEN Digital Insights Portal (HGMD, Human Somatic Mutation Database, COSMIC, Biomedical Knowledge Base, ANNOVAR, Genome Trax, and OmicSoft Programatic Interface).

Q - Can I turn on SSO for product A but not for product B?
A – No. Users have one login for all QDI-hosted products. SSO replaces the QIAGEN Digital Insights identity store with the customer's identity store. When SSO is turned on on the user's account, it is the only login option for all QDI-hosted products.

Q – My institution has multiple licenses. Can some licenses be exempt from SSO?
A – No. This is an all-or-nothing SSO implementation.

Q - Can the license administrator add/remove users from SSO?
A – Optional enabling/disabling SSO on the user level can be done by license administrators if they are provided an SSO administrator license. Without that additional license, they cannot select the option to turn on SSO for a new user they are adding to their license. SSO administrators can add/remove users from SSO at any time.

Q - Do we need to purchase a license before implementing SSO?
A - (From a technical standpoint) No. Integration can be done before purchasing a license. But when someone from their organization logs in to an SSO-supported application, a license-related error will be triggered.

Q - Is there an extra licensing cost for SSO?
A - No.

Q - Is auto user provisioning available with QIAGEN Digital Insights SSO?
A – Yes. However, it is recommended for site-wide (i.e., unlimited) application licenses.

Q – Who is responsible for user authentication issues?
A – The person from the organization's local IT department who acts as SSO admin for their organization, managing the users for a given domain, is responsible for user authentication issues. The QIAGEN Digital Insights Customer Support team supports IT contacts/SSO admins with SSO questions.

Q – Will SSO continue to work when a QIAGEN Digital Insights product license has expired?
A – Yes. If the license has expired, after SSO authentication, the user will get a message “You do not have a license for this product.” If SSO for QIAGEN Digital Insights products is no longer required and should be turned off, please send an email to ts-bioinformatics@qiagen.com.

Q – Can we self-configure the domain or re-upload XML, or enable/disable SSO?
A – Yes. This is done on the SSO Configuration page in the QDI Admin Tool.

Q – Will IP address restrictions on the license be enforced?
A – (This question applies to particular QIAGEN Digital Insights products that have IP address restrictions on the license.) Yes. IP address restriction is part of user authorization and will be enforced. When working remotely, users are advised to use their institution's VPN, whose gateway IP is part of the white-listed institutional IP addresses.

Q – Can individual user accounts be exempt from SSO?
A – Yes.

Q – Can we continue to use the QIAGEN Digital Insights Admin Tool?
A – Yes. There is no change.

Q – Can different SSO configurations be provided for the same domain in situations where QDI products are hosted on different data centers located in different countries?
A – Yes. SSO configuration is QDI data center-specific. In this situation, for each QDI data center applicable, one SSO configuration is set up for all domains whitelisted on the license that share the same IdP.

Q – Should the Service Provider certificate be asserted?
A – Yes, we advise asserting the certificate. Certificate assertions should only be disabled during configuration or upon renewal.

Q - Why am I getting a message that my user account could not be found in the system after logging in via SSO?
A - This occurred because automatic license provisioning is not enabled in your SSO configuration. Please contact your license administrator to have your account added to the site license.

Q - Which SAML/Identity Provider do you use?
A - We do not have a recommended SAML/Identity Provider. SSO integrations have, for example, been made with Okta, Google, and Azure.

Q - Will the SAML Authentication request be encrypted, and should the SAML response be encrypted?
A - Yes.

Q - Can encryption be turned off during development to debug?
A - No. Log files can be used/provided for troubleshooting.

Q - Do you support metadata exchange (SP sends metadata to IdP, IdP creates a connection, IdP sends metadata, SP imports metadata, turn testers loose)?
A - Yes. The SP metadata can be downloaded from the self-serve SSO configuration page on the QDI Admin Tool, or QDI Customer Support can share the download link via email. There is no automatic discovery between IdP and SP; the setup is manual.

Q - Is IdP-initiated SSO required, or can you support SP-initiated SSO?
A - QDI’s SSO implementation currently only supports SP-initiated SSO.

Q - What attributes are required, and what is the SAML_Subject? The Employee username, employee ID, something else?
A - The <NameId> is a required attribute in the SAML 2.0 response, as well as the email address, first name, and last name of the authenticated user. The NameId is the SAML subject, usually the email address.

Q - Is the application integrated with AD? Do users use their network credentials or something else to log in?
A - AD is a supported identity provider. Users will log in using their institutional email addresses that are also their registered account user names in the respective QDI applications that they have licenses for. For SSO to work, the institutional email address format must be the same for all users, e.g., not a mix of <userid>@domain.com for some and <firstname>.<lastname>@domain.com for the rest from the same organization.

Q - If you SSO the application, what happens to existing user accounts? Are they merged or something else?
A - The existing user account stays the same, provided that the username is already in the SSO-supported format. If the user account is not in the supported format and an alternative SSO-supported format exists (in the customer’s IdP), the QDI Licensing team can rename on UMA the current one to the SSO-supported format. (In the worst case, if the user account is not in the QDI-supported format and there’s no alternative SSO-supported format, then that particular user can stay non-SSO, i.e., continue to use QDI two-factor authentication.)

Q - What is the user experience, with SSO enabled, for a user who’s not set up in the application yet?
A - That user will be able to log in but will see an error page saying that he/she is not authorized to use the application. Or, if automatic provisioning has been turned on on their SSO configuration, that user will be automatically created in UMA, added to the license, and the application will proceed to load. (The first two transparent steps are one-offs.)

Q - Do users access the application via a public/shared/training type workstation that they are not personally logged into?
A - Workstation type has no impact on application access. User must be able to authenticate to SSO on the workstation.

Q - Do users require the ability to log in with different credentials for test/developer/admin access?
A - No. Only the SSO-supported credentials that exist in their IdP can be used.

Q - Do you have any MFA requirements?
A - MFA is an optional layer of security that is up to the customer to integrate with QDI SSO to implement. It’s not something QDI requires.

Q - What should the user log-out experience look like?
A - Just a normal exit from the application. Not much to expect.

Q - Do we need a log-out button?
A - No. The application’s log-out button is the only thing needed.

Q - Are you receiving any kind of feed of users' information from CCF? If so, what is the purpose of it, and how will SSO via SAML affect that (or vice-versa)?
A - We are not sure what this question means, if it refers to something like whether the SP is getting user data(attributes or metadata) directly from the CCF(?? Something like central customer/corporate directory/federation) outside the SAML assertion itself, then the answer is no, the only exchange of information is from the SAML assertions.

Q - Are there any scripts or programs that access the application using a userid/PW?
A - QCII is moving away from the API calls with user and password and replacing these with the OAuth device code flow, where the end user does the browser authentication.

Q - Is SSO enabled in your Test/Staging environment?
A - SSO is only available under the production (and beta) environment. There is no staging environment to test SSO integration.

Q - If this is internally hosted, do you have your certificate(s) set up?
A - Yes.

SSO known limitations

When SSO is turned ON, users once logged in, will not be able to login as someone else from their private computer.

Workaround: logout from own IDP and delete all cookies from browser for ingenuity.com.

SSO work flows that require special attention

When SSO is turned ON for a domain, but account auto-provisioning is turned OFF, any new account trying to login in our system will get a message stating that the account could not be found in the system.

When SSO is turned OFF for a user already logged in, he/she will receive a message saying that “SSO login is disabled for your user, please go back and login with QIAGEN credentials upon session expiration“.