Self Service Single Sign On Quick Start Guide
Overview
Welcome to Single Sign On Self Service. In the following pages you will find important definitions and guidance to support and maintain your SSO relationship with HireVue.
Note: This is a new feature for HireVue customers and is subject to change as we strive to improve the service over time. This document, and related usage documents will be updated to reflect those changes. That said, we will start with this Quick Start Guide (QSG, because we all love acronyms!).
The purpose of this document is twofold:
- Provide administrators with an introduction to the self service single sign-on (SS-SSO) feature within HireVue.
- Provide administrators with basic guidance for SS-SSO use to enable management of single sign-on components within HireVue.
We will be reviewing the configuration options related to the SP-Initiated SAML authentication workflow. If you happen to be in an IdP-Initiated auth workflow, we will have that documentation available soon, in the meantime feel free to reach out to HireVue support for assistance.
Definitions
HireVue leverages a mostly standard implementation of SAML for processing logons with SSO. We say ‘mostly’ because we extend the functionality of our solution to support certificate rotations. More on that later. First, let’s get some key HireVue SSO settings and terms defined.
- SAML2.0 - The version of SSO that we support at HireVue. We adhere to the SAMLv2 Core Specification
- SP - Service Provider. In this case, HireVue is the SP, providing service through an application.
- IdP - Identity Provider. The IdP is responsible for providing and verifying the identity of anyone trying to login to a service or account. The IdP provides a source of authority that HireVue can validate against. Note: HireVue SSO does not support the use of multiple IdPs per account. IDP+HV=1:1.
- SP-initiated SSO - HireVue’s preferred and recommended SAML authentication workflow. This means when the user attempts to go to any URL in HireVue, HireVue will pass them back to the IdP for authentication. Note: HireVue mobile apps require SP-initiated SAML to work correctly.
- IdP-Initiated SSO - This SAML flow will not work with HireVue’s mobile Apps, provides a poorer user experience, and is not recommended. The user starts at an IdP launch page and then enters HireVue and lands at the home page. App ‘galleries’ that have multiple click-to-launch icons for example, use an IdP-initiated SAML flow.
- NameID - This is the SAML Subject Attribute that specifies the principal that is the subject of the statements in the SAML assertion. The identity provider specifies the user name or the identity of the authenticated user through the NameID
- Single Logout (SLO) - This is supported by HireVue, and used for logging users out of the HireVue app (and ending the current session) and can be configured to log out of the IdP as well.
- SSO Binding - HireVue supports SAML bindings to transport data during the sign-on process. We prefer HTTP-POST, but can support HTTP-REDIRECT HireVue does not support HTTP-ARTIFACT bindings.
- Default Role - This is the basic role assigned to auto-provisioned users created by HireVue upon successful login via SSO. This role has no additional permissions associated with it until action is taken by the account admins.
- IdP Entity ID - This setting specifies the Identity Provider, and is a unique identifier. For example, in Azure SSO the IdP Entity ID is https://sts.windows.net/<TenantIDGUID>/ where <TenantIDGUID> is the tenant ID of the Azure AD tenant.
- IdP POST Url - Also known as the login URL, this is the destination for user login authnRequest at the IdP. For Example, in ADFS SSO, this would be https://<domain>/adfs/ls
- Certificate - SAML requires certificates, mainly and most importantly for signing communications during the login process. For SSO, we use the IdP signing certificate. HireVue accepts X.509 certificate entries. See Certificates section for more information, later in this guide.
- SAML Metadata - A SAML metadata document describes a SAML deployment such as a SAML identity provider (IdP) or a SAML service provider (SP). Deployments share metadata to establish a baseline of trust and interoperability.
Getting Started
To use Single Sign On Self Service, your HireVue account must have 2 things:
- At least 1 subdomain specified e.g. customername.hirevue.com
- SSO enabled on the account
When these two criteria are met, we can allow access to self service for managing your SSO configuration. If you need to enable SSO for the first time on your HireVue account, contact support for assistance.
Customers can access Single Sign On Self Service through the HireVue application by selecting Integrations from the menu under the admin name in the upper right corner of the page:
Our SSO Self Service feature is broken into 4 sections, allowing settings to be defined for Service Provider, Identity Provider, SAML Authentication, and Single Logout. We have also included a link to the HireVue account metadata.
The first section has 4 toggle switches, the most important one is enabling SAML authentication.
You can choose to enable showing the SAML NameID, encrypted assertions in SAML responses, or blocking of disabled SSO users. These settings are part of the Core SAML2.0 specification and specific to certain conditions within your configuration. They do not need to be changed unless your scenario calls for them to be used.
Moving on. There are settings for the SSO Binding and Default Role in this section as well. The SSO binding defaults to HTTP POST, but can be changed to HTTP ReDirect. HTTP POST is the preferred method.
The Default Role setting applies to users that are auto-provisioned by the SSO workflow. By default, these users are granted the basic role of Evaluator (recommended). Auto-provisioned users can also be assigned to Team Member or Team Admin roles.
The next section is for Identity Provider (IdP) Configuration settings. The HireVue preferred and default authentication workflow is SP-Initiated, however we do support IdP-Initiated authentication workflows.
A sample SP-Initiated authentication configuration is displayed in the image below. Populate the required fields for (1) IdP Entity, (2) IdP POST URL, and the (3) IdP signing X.509 certificate provided in Base64 format as appropriate for your use case.
Note: When the IdP-Initiated toggle is switched to the ON position, the IdP POST URL field changes to accept the IdP Redirect URL value. This is only used for IdP Initiated SAML authentication workflows.
The last 2 settings in this section, Suppress certificate info in SAML requests and Use self-signed certificate are situational and should only be changed for specific use cases.
Certificates
This seems like a great time to talk about certificates and their role in SSO. For SP-Initiated SAML Authentication HireVue uses signing certificates from the Identity Provider (IdP).
The identity provider uses a certificate to verify the source of its communications to HireVue (referred to as a token-signing certificate). The identity provider’s public certificate needs to be imported into the HireVue application, and the easiest approach is to review the metadata provided by the identity provider, as it includes configuration information as well as certificates.
When configuring the identity provider in SSO Self Service, copy and import the public certificate manually into the HireVue SSO Admin IdP section.
Note: In addition to the signing certificate, the identity provider may optionally also use a separate token encryption certificate. You don't need to import this certificate into the IdP info section.
At the beginning of this document, we mentioned the extended functionality for managing certificate rotations in HireVue. We do so through settings applied by our platform based on certificate status and decisions made by the parties involved.
There are 4 authnRequest signing certificate settings maintained by HireVue for SAML SSO:
-
Current Certificate Dynamic
- This setting indicates that IF a new certificate exists, the service will attempt to use that certificate for signing authnRequests. If the new certificate fails, the service will revert to the existing certificate for signing. If the new certificate is accepted by the IDP, this setting will automatically advance to New Certificate Dynamic.
-
Current Certificate Static
- This setting indicates that this is the only certificate that will be used for signing. If 2 or more certificates exist this setting forces the existing (oldest) certificate to be used for signing authnRequests. This setting ensures that a known good certificate is used.
-
New Certificate Dynamic
- This setting indicates that the certificate being used has been promoted, superseding an existing (older, about to expire, etc) certificate. When multiple certificates are active, HireVue will only use the newest certificate for signing authnRequests.
-
New Certificate Static
- This setting indicates that this is the only certificate that will be used for signing. When multiple certificates exist, HireVue will always use this NEW certificate for signing authnRequests.
We will use this information in the next section, configuring the Service Provider.
There are 4 elements in the Service Provider setup section that we want to call out. (1) is the Custom SP Entity ID. Leave this field blank to use the default ID (recommended). (2) is the encryption used for signing. By default HireVue will use RSA-SHA256. (3) is the Active Certificate setting for the SP (HireVue). This setting utilizes the configuration outlined in the previous section. By default, the setting is Current Certificate Dynamic. HireVue will attempt to use the current certificate as the active signing certificate. If more than 1 certificate exists, HireVue will attempt to use the newest certificate. If that fails, it will revert to the next oldest certificate. (4) is the metadata link for your HireVue account. This information is handy for identifying the SP to the IdP. The HireVue metadata contains the X.509 signing certificate that you will need for your organization’s IdP configuration.
The final section to review is Single Logout (SLO). To use Single Logout, turn the Enable Single Logout (SLO) switch to ON, enter the SLO Consumption URL and choose the SLO Binding type. Not all SSO configurations use SLO, so only enable if yours does!
Save your configuration by clicking the Save button at the bottom of the page. This button will only become active if changes to existing fields have been made. Upon save, you will be prompted with an “Are you sure” dialogue:
If you need to review changes before submitting, you can dismiss this dialogue by clicking No and the configuration will not be saved. However, this process will not undo the entries made during this session and you can review your settings. Once you validate the settings you can Save and say Yes to the confirmation dialogue. Your configuration changes will then be active. Remember to test with an SSO user. Please review this document, which goes over Display Packages and Manual Video Assessment Packages, and this Create Calendar Integration Tech guide.