Overview

ClinSpark supports integration with SAML 2 SSO providers. Support for this functionality is enabled per environment, as a system feature, which impacts all users of the system. The enabling or disabling of SSO functionality is controlled by superadmin users.

Configuration of SSO varies depending upon the provider. Our documentation covers how ClinSpark can be configured to work with the providers which to date we have successfully integrated with.

Other SAML providers should work as well, and this documentation will grow as we encounter customer requests for additional providers.

Environments

The ClinSpark portion of the configuration currently must be configured by IQVIA Support, and requesting this should be done via a Service Desk Ticket.

Note that this must be done for each ClinSpark instance:

• ClinSpark typically has 2 instances per environment (MAIN and TEST).

• Each instance has a different URL, requiring new configuration to be done by the customers site IT team. This would include environments covering Sandbox Test/Main, VAL Test/Main, PROD Test/Main, etc.

• The customer site IT team may want to configure all TEST instances to a TEST SSO IdP, and PROD instances to a PROD SSO IdP, resulting in different IdP login & IdP Logout URL.

Typical Workflow

IQVIA Support collaborates with each Customer and site IT team for the setup of SSO. Typically, the following happens:

1. The Customer creates a Service Desk Ticket, per instance, per environment (!). Usually, this can be one of the sandbox environments (Main or Test), but might be production as well. IQVIA suggests to start with only one instance (e.g., Sandbox Test) to first verify all details and workflow before rolling out over other instances & environments.

   Please provide:

   • Which type of IdP your organization works with. Most common are Microsoft’s ADFS and Azure AD (see separate pages below this help article).

   • Provide the base URL (https://instance.clinspark.com)

   • Once SSO is enabled, users which have ‘SSO Disabled’ set to ‘No’ in their user profile won’t be able to login until SSO is fully functional. Please indicate which user need to (temporarily) have ‘SSO Disabled’ set to ‘yes’. Usually, this is an admin that will work with IQVIA support for the duration of the SSO configuration.

2. IQVIA support will:

   • Provisionally enable SSO (to generate the SSO metadata). This will use temporary IdP login- and logout URL as well as temporary IdP certificate, since we need to get that from the Site’s IT team later on.

   • Disabled SSO for the desired users

   • Provide an URL to the metadata XML, which is necessary for the Site’s IT team to complete the SSO configuration. This URL usually has the form of https://instance.clinspark.com/sso/metadata

3. The Customer will then work with the Site’s IT team to have the application instance added to their IdP. Depending on the IdP (see separate pages below this help article) they should at least be able to provide IdP Login- and Logout URL as well as the IdP certificate, together with all necessary other IdP settings for IQVIA to complete the configuration.

4. IQVIA Support will update the configuration, and work with the Customer to test the configuration with a first test - user.

Notes

• Be sure to test electronic signatures after enabling SSO. Signatures delegate verification of credentials to the Identity Provider (IdP). Support for this requires that ‘forceauthn’ is enabled on the IdP. IQVIA support does not provide support for IdP configuration, you will need to review the documentation for the IdP to see how this can be enabled if it is not on by default.

• The Password Reset functionality is not relevant to SSO - enabled accounts, as this only controls passwords controlled by ClinSpark

• The following ‘User Details’ settings are not relevant to SSO - enabled accounts: ‘Password’ (and confirmation), ‘Password Can Expire’, ‘Password Expire Date’ and ‘Two Factor Authentication’.

Abbreviations