SSO is a chargeable add-on and is not included as standard. Please speak to your Account Manager if you would like it adding to your system.

What is SSO and how does it work?

Single Sign-On (SSO) is an authentication method used by many organisations and systems to ensure everyone has access to the applications they need, while reducing (and in many cases, removing) the need to remember multiple usernames and passwords.

If you’ve ever used a Login with Facebook/Google/LinkedIn function to access a website or service, this is an example of SSO in action – Social SSO.

In this guide, we’ll be looking at configuring an Enterprise SSO, which works in a similar way to Social SSO, but has additional configuration requirements.

In simple terms, your Enterprise SSO provider (such as Microsoft Azure/Office 365 and Okta) contains a list of your employees (users) and approved applications.  Each user is linked to the applications they are permitted to access. 

Within each application (such as Eploy), you’ll need a corresponding user with the same username as the user within the SSO provider (the type of username used can vary, but quite often will be their email address – this is the example we’ll use throughout this guide, unless stated otherwise).

When someone wants to log-in to the application, rather than entering a dedicated username and password for that application, they’ll use the Login with Office 365/Okta/Google button, or they’ll be logged in automatically if Force SSO has been activated (see below).

The application will check with the SSO provider that the person has access to the system, and if so, log them in automatically.  If they don’t have access, they’ll see an error message.

So long as you’re already logged in to your SSO account (and chances are, if you’ve been looking at your emails today, you will be), this all happens seamlessly.  If you’re not logged in to it, you’ll be asked to login to your SSO account (e.g. MS Office 365, Google, Okta) before being granted access to the application.

Force SSO

When using an Enterprise SSO, you have the option of forcing the users to use SSO. 

If this is switched off, your users will have the option of using the SSO provider or a dedicated username and password.

If Force SSO is switched on, the login page is hidden altogether – authorised users will be automatically logged in when they access Eploy, meaning only SSO can be used to access the application.

SSO and your Eploy System

Within your Eploy System, you’ll find that Social SSO is readily available within the Candidate Portal.  Your Candidates will be able to access the Candidate Portal using their Facebook, Google and LinkedIn accounts.

Social SSO can also be used to access the Core System, Hiring Manager and Vendor portals, though we typically advise against this as Social SSO is inherently less secure than an Enterprise SSO – once someone has access to your Google, Facebook or LinkedIn account, they also have access to any other system you’re using these credentials to log in to.  Although this functionality is available within your system, it’s switched off as a default for Standard, Hiring Manager and Vendor users.

Within your Eploy system, Social SSO is called Social Logins and Enterprise SSO is called Corporate Single Sign On.  This is the naming convention we’ll use throughout the rest of this guide.

As Corporate SSO is technically a type of Integration, it is not available within your system as a default, unless you have specifically asked for it.

To check if Corporate SSO has been activated in your system, navigate to Admin > Security Settings > Standard Users, then scroll down to the Corporate Single Sign On section.

If it’s not active in your system, you’ll see this:

If you see this message, please speak to your Implementation Manager, if in Implementation, or your Account Manager if your system is already Live.

If it is active, you’ll see a Reply URL and be able to select an SSO provider (more on this later):

Supported SSO Connectors

As a default, Eploy is configured to work with the following SSO connectors:

• Microsoft Azure AD/Office 365
• Active Directory Federation Services (ADFS)
• Okta
• Google Gsuite
• OneLogin
• Shibboleth
• Ping

In practice though, Eploy can work with any SAML-based SSO provider.

If the SSO provider you want to use is not listed above, please discuss it with your Implementation or Account Manager.