Accessing the Deeper Signals platform via SAML SSO authentication allows seamless login flows for your organization with supported ‘deeplinked’ content access in the form of the Playbooks.
\nWhat is SAML?
\n\n\nSecurity Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP).
\n
This means configuration for SAML must be done in two places: on the side of the Identity Provider (IdP) and at the Service Provider’s end (SP).
\nFollowing are the steps needed to setup SAML between your IdP and the Deeper Signals platform, acting as an SP.
\n1. Setting up with your Identity Provider (IdP)
\n\n\nNOTE An identity provider performs the authentication that the end user is who they say they are and sends that data to the service provider along with the user's access rights for the service.
\n
Check your organization’s IdP which is typically a third party cloud service provider such as Azure AD, Microsoft AD, AWS IAM.
\nWith appropriate admin credentials you can access the section to capture SAML parameters and configure with your Service Provider ( Deeper Signals platform).
\n* Issuer URL - This is a unique identifier of your IdP formatted as URL.
* SSO URL - This is your SSO login page configured with IdP, the starting point of user authentication.
* Authentication certificate - An X.509 digital certificate which is a standard in establishing security between two digital parties.
Make sure that your nameId option is configured to user the users email address as a unique identifier and your NameIDFormat follows this structure:
\nurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\n\nYou should also configure additional attributes to be passed with the SAML request, mainly the user's first and last name. These attributes should be linked to the following keys:
\n- \n
First Name → first_name
\n \nLast Name → last_name
\n \n
Example from Deeper Signals SAML manual setup flow, Step1:
\n2. Setting up with your Service Provider
\n\n\nNOTE A service provider (SP) is a system entity that receives and accepts authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML)
\n
In this SSO scheme Deeper Signals is the Service Provider.
\nOn submitting IdP data in Step 1, fields in Step 2 will be auto populated from where you can then copy URL parameters and paste them back with your IdP’s SAML configuration settings page.
\n* Audience/Entity ID - globally unique name for the SP, in this case a unique URL format.
* ACS Endpoint (URL) - the URL location where the SAML assertion, i.e. authentication response from IdP is sent and user is redirected to.
Example from Deeper Signals SAML manual setup flow, Step 2:
\nNote: ACS validator field needs to be populated when SP initiated SSO is performed.
\nHere are guide videos on setting up SAML SSO for Google Workspace and Microsoft Azure:
\n\n\n3. Setting up Playbooks
\nOptionally, as a final step, you can create Playbooks which allow you to set up authenticated users into custom groups and projects as well as assign them assessments in one step.
\nYou can read more about playbooks 👉 here.
\nOnce a Playbook is created another 2 parameters will be generated to facilitate the authentication process.
\nRelay State (IdP initiated)
a unique parameter functioning as a ‘deep link’
You should set this code as the relay state in you IdP configuration if you want all users using the IdP initiated SSO authentication flow to be put through the playbook you chose
Playbook URL (SP initiated)
Used to start an SP initiated SSO authentication flow
If you don’t want all users using the SAML authentication to be associated with the same playbook you should distribute the Playbook URLs to the specific users as you see fit
As a general rule we recommend setting up a playbook relay state code in your IdP configuration, as users should always have an assessment assigned to them. There are exceptions to this but that can be determined on a case by case basis.
\nHere is a quick video guide on how to do it:
\n\n","auth":{"type":"noauth","isInherited":false},"event":[{"listen":"prerequest","script":{"id":"13573302-dc15-49ba-b933-49035ea0ca10","type":"text/javascript","exec":[""]}},{"listen":"test","script":{"id":"8d7db1d9-436a-42a3-8f65-2e50b4a14491","type":"text/javascript","exec":[""]}}],"_postman_id":"6b830462-d232-4473-a047-64f3d7a7030f"},{"name":"HRIS Data Import","item":[],"id":"99c5bc84-20ef-4458-ad80-f0f4effe0783","description":"The purpose of the HRIS data import file is to add user-data to your Deeper Signals account and continuously update it. The import file can be created and uploaded to a client-side SFTP server and the Deeper Signals application will pull and upload the new latest file at pre-determined intervals. DS will always pull the most recent file and ignore the previous ones. This file is used only when API access cannot be provided by the client.
\nFile format requirements
\nFile Content requirements
\n- \n
- The first column of the file should contain the user email which is the uniqueID for the user across the application. \n
- The second and third column should contain user first_name and last_name. \n
- The first row of the file should be the name of the variable. This name will be used across the app in analytics and filtering sections. For example, if you are sending business unit, name the column Business Unit or whatever you want to display in filter fields, charts and tables for that data. \n
- The second row should describe the data type. There are five types of data: keyword, date, numeric, name, email. \n
- If including hierarchy in the file, there must be a column with the manager’s email address. The column name should be: manager and type should be email. \n
- There is always one row per user. \n
- When providing numeric values, the values must be numeric or a decimal. \n
Template (Sample) File
\nDownload sample file 👉 here.
\n","auth":{"type":"noauth","isInherited":false},"event":[{"listen":"prerequest","script":{"id":"62b805ea-9ef2-4095-829a-3e4bce4a9b33","type":"text/javascript","exec":[""]}},{"listen":"test","script":{"id":"bc650acf-03fa-4f43-aa19-60fc49c7181e","type":"text/javascript","exec":[""]}}],"_postman_id":"99c5bc84-20ef-4458-ad80-f0f4effe0783"},{"name":"SCIM","item":[],"id":"1454f86d-1e80-4ffb-9ebc-7a14776f54e5","description":"Integrating Deeper Signals with your IdP via SCIM simplifies user management by automatically provisioning, updating, and deprovisioning users, ensuring secure and efficient access control.
\nWhat is SCIM?
\nSCIM (System for Cross-domain Identity Management) is an open standard protocol used for automating the exchange of user identity information between identity providers (IdPs) and service providers (SPs). It enables organizations to efficiently manage user provisioning, deprovisioning, and updates across multiple systems, ensuring consistency, security, and compliance in identity management.
\nHow to set up SCIM?
\nCheck your organization’s IdP which is typically a third party cloud service provider such as Azure AD, Google Workspace, AWS IAM.
\nWith appropriate admin credentials you will be able to access integrations in Deeper Signals' platform and create API Key.
\nOnce you have obtained API Key, you can use it for setting up SCIM integration in your's IdP.
\nDeeper Signals SCIM URL:
\nhttps://api.deepersignals.com/api/scim/v2
Required attributes:
\n- \n
userName (user's primary email address)
\n \nfirst name
\n \nlast name
\n \nexternalId (employee id)
\n \nactive status
\n \n
e.g. map of attributes for Microsoft Azure SCIM provisioning:
\n\n\nNOTE: We support user provisioning via SCIM; group provisioning is not supported at this time.
\n
For a clearer understanding, watch the video below for a step-by-step walkthrough of the process.
\n\n","_postman_id":"1454f86d-1e80-4ffb-9ebc-7a14776f54e5"}],"event":[{"listen":"prerequest","script":{"id":"184ee455-55fe-4423-a481-336734e1727f","type":"text/javascript","exec":[""]}},{"listen":"test","script":{"id":"62813869-8fe2-445b-80a9-3817b87935f0","type":"text/javascript","exec":[""]}}],"variable":[{"key":"webhookUrlExample","value":"https://yourwebhookurl.com/path/to/webhook/calback"}]}