About Web SSO

SmartRecruiters has implemented a broadly supported industry standard for Web SSO – SAML 2.0.

It not only allows a quick set up and configuration but is also supported by a majority of Identity Providers on the market.

Key characteristics

Below are explained core SmartRecruiters SAML 2.0 implementation characteristics.

User Provisioning

User has to be created and activated in SmartRecruiters prior to logging in from an Identity Provider. This should be done by using our Users API. You can find the detailed instruction on how to do it in our Creating new SSO-enabled user guide .

When you create the user in API:

• when no ssoIdentifier has been specified, API will assign default one, based on user’s email – this is not recommended – please set the ssoIdentifier when creating the user via API
• when ssoIdeintifer has been specified, the defined one is used.

If you are using Okta for user provisioning, you may find this Okta-SmartRecruiters guide useful.

User Binding

The ssoIdeintifer needs to be exactly the same (case sensitive) in your IDP application and in SmartRecruiters system. This can be achieved in 3 ways:

1. ssoIdeintifer in SR can (and should) be assigned straight away at the moment of user’s creation in SmartRecruiters when you create the user in our Users API (as in User Provisioning above). You can find detailed instruction on how to do it in our Creating new SSO-enabled user guide.

2. ssoIdeintifer in SR can be changed by our Public API PATCH /users/{id} endpoint (https://developers.smartrecruiters.com/docs) with request body:

[
  {
    "op": "add",
    "path": "/ssoIdentifier",
    "value": "sso_identifier_for_the_user_usually_email"
  }
]

You can find detailed instruction on how to update the ssoIdentifier in our Updating ssoIdentifier guide.

3. Login binding: when SmartRecruiters is not able to recognize the identifier that IDP sends – the login form is presented. Once user logs in, the IDP identifier is bound to logged in account.
   The next attempt to login via IDP to SmartRecruiters will recognize this identifier with the user that logged in this way and user will be signed in automatically without displaying a login page.
   Please note, that the system will bind this identifier with the user that will successfully login to SR, which might not necessarily be the one that initiated logging process on your IDP’s side – this means that [email protected] can initiate logging process on your company’s IDP end, and when asked to login – user’s colleague [email protected] might do it. In this scenario [email protected] IDP user will be bound to [email protected] SmartRecruiters user.

Signature Algorithm

Both RSA-SHA1 and RSA-SHA256 signature algorithms are supported for SP-initiated and IDP-initiated flows.

Assertion

For correct SAML 2.0 assertion, the NameId Format (nameId) and NameId Policy (nameIdPolicy) need to agree with the official SAML 2.0 standard, as per it’s official documentation:

• the NameId Format: nameId format has to be either “emailAddress” or “persistent” (as per sections 8.3.2 and 8.3.7 of the documentation)

• the NameId Policy: NameIDPolicy needs to be correctly configured as per section 3.4.1.1 of the documentation

Callback

Callback is performed via POST method.

Direct log-in to SmartRecruiters

It’s possible for users to log-in directly to SmartRecruiters without going through an IdP.
In order to do it, a user must have an account set up within SmartRecruiters, ideally using the User API.