SSO with SAML 2.0

Overview

The interview suite can be configured as a SAML 2.0 Service Provider. Please contact helpdesk@interview-suite.com for assistance, no end-user configuration options are available.

Service Provider URLs

SAML endpoints reside under a separate subdomain for each interview suite company or organisation. They are only available once SAML is enabled by the Help Desk.

Metadata endpoint

https://company-name.interview-suite.com/sso/saml/metadata/

Also used as Authentication Request issuer value.

SSO endpoint

https://company-name.interview-suite.com/sso/saml/

(redirects user to IdP for authentication)

Assertion Consumer Service

https://company-name.interview-suite.com/sso/saml/acs/

SAML assertions from the IdP should be POSTed here.

SLO consumer

https://company-name.interview-suite.com/sso/saml/sls/

This is the Single Log Out consumer service that receives logout confirmations from the IdP

Configuration Options

The below options can be configured by the Help Desk.

Identity Provider Settings

Entity ID (required)

This is the Identity Provider “Issuer URL”.

SSO Service URL (required)

This is the Identity Provider endpoint where the Service Provider will send the Authentication Request.

SLO Service URL

IdP endpoint where the SP will send the LogoutRequest/LogoutResponse request for Single Log Out. Optional.

X509 Certificate (required)

IdP’s public x509 certicate

Option Settings

This section customizes the behavior of the SSO integration

Create new user if none exists (on/off)

If enabled, a new interview suite user will be created using the data provided by the IdP (when no existing interview suite user can be found). Any new interview suite users created during a SAML sign-on will be given the hiring manager account type by default, unless the SAML assertion for that user indicates otherwise.

Update user data from IdP (on/off)

If enabled, user data from the IdP will be used to update the interview suite user’s details.

Restrict user creation (on/off)

If enabled, new users can only be created by SAML assertion or by an account admin or account owner using the API; creation of new users will be disabled in the front end.

Restrict deleting user (on/off)

If enabled, users can only be deleted by an account admin or account owner using the API; deleting users will be disabled in the front end.

Restrict changing user account type (on/off)

If enabled, users’ account types cannot be changed in the front end. They can only be changed by SAML assertion or by an account owner or account admin over the API.

Keep standard login? (on/off)

Disable to prevent users logging in to the interview suite using a separate interview suite password instead of the identity provider. This will also disable the password reset functionality. Users will need to visit https://acme-inc.interview-suite.com/#/login/?skip_sso=true to avoid being redirected to the IdP SSO service URL.

Default session timeout (integer)

Time in minutes before a session created through a SAML assertion expires. If a SAML assertion includes AuthnStatement/@SessionNotOnOrAfter, the value in the SAML assertion will take precedence.

Interview suite account identifier

Select either email or username to indicate what the SAML IdP will use to uniquely identify the user. This needs to be used in combination with the email and username mappings below. Eg. if the account identifier is set to username, assertions will be checked for the attribute defined in the username mapping below, and the user with be associated with any existing interview suite account with this username.

The create new user if none exists option (above) determines whether a new account is created if no existing interview suite account is found.

Default preferred language

Any language supported by the interview suite can be used as the default language for users created during the SAML SSO process.

Attribute Mapping

The IdP makes assertions containing attributes describing the authenticating user. The interview suite maps these attributes to the interview suite equivalent where these attributes are named differently in the assertion. For example, if the IdP sends an assertion indicating that a user’s surname is ‘Merkel’, then an attribute mapping needs to exist to map the IdP surname to the interview suite’s last_name (alternatively, the IdP can rewrite the attributes before sending the assertion).

Email

User’s email address. This is used to uniquely identify the user; multiple interview suite users can’t share the same email address when using SSO.

Username

This field can be used to uniquely identify the user instead of the username email address. If it’s not provided, a username will be automatically generated. This field can safely be ignored in favour of the email field.

First name

User’s first name

Last name

User’s last name

Gender

User’s gender: either ms or mr. This field can be safely omitted.

Preferred language

The language to show the interview suite user interface in for this user, and in which system emails to this user are sent. Available languages can be determined over the public API.

Account type

An interview suite user’s Account Type defines what a user is permitted to do. This field maps to the field name used for the Account Type in the SAML assertion. See Account Type Mapping to map specific values to interview suite values. If omitted, all users created during the SAML SSO process will be receive the Hiring Manager account type.

Account Type Mapping

The IdP can send its own roles or group names which are mapped to the interview suite account types according to these rules. The role/group is extracted from the value of the SAML assertion field mapped to account type. Note that setting the Account Owner account type in an SSO assertion is not possible.

A role or group name is required for each of the following account types:

  • Account Admin
  • Recruiter
  • Hiring Manager

In some cases role/account values will be provided in a single statement like CN=admin;CN=Europe;. A RegExp pattern can be specified to extract all possible roles/groups from the value. In this example: CN=([A-Za-z0-9]+). The first match that matches one of the defined mappings will be used.

Advanced Settings

Strict Mode (on/off)

Must be enabled when turning on in production the SSO functionality. During setup, it can be disables to relax some SAML validations and ignore other advanced settings requirements.

NameID Format

Specifies constraints on the name identifier to be used to represent the requested subject. Review IdP metadata to see the supported NameID formats.

If in doubt, use urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.

Encrypt NameId (on/off)

When enabled, the nameID sent by the SP will be encrypted.

Sign AuthnRequest (on/off)

When enabled, the samlp:AuthnRequest messages sent by the SP will be signed.

Sign LogoutRequest (on/off)

When enabled, the samlp:logoutRequest messages sent by the SP will be signed.

Sign LogoutResponse (on/off)

When enabled, the samlp:logoutResponse messages sent by this SP will be signed.

Sign Metadata (on/off)

The metadata published by the SP will contain a signature, so IdP will be able to validate it.

Reject Unsigned Messages (on/off)

Reject unsigned samlp:Response, samlp:LogoutRequest and samlp:LogoutResponse received.

Reject Unsigned Assertions (on/off)

Reject unsigned saml:Assertion received

Reject Unencrypted Assertions (on/off)

Reject unencrypted saml:Assertion received.

Reject Unencrypted NameId (on/off)

Reject unencrypted saml:nameid received.

Lowercase urlencoding (on/off)

ADFS URL-Encodes SAML data as lowercase, and Python’s urllib Url-Encodes as uppercase. This creates a signature verification mismatch. Enable this in order to solve this issue.