UserLock single sign-on (SSO) for Salesforce

Mention SaaS, and one of the first applications that comes to mind is the Salesforce customer relationship management (CRM) platform. When it first appeared, Salesforce was used mainly by sales and marketing teams. This quickly expanded to other job roles, resulting in ever greater numbers of employees requiring access.

Salesforce holds lots of sensitive business data, and defending it is always a high priority. The risks here are considerable, which makes it essential to put in place additional security layers such as single sign-on (SSO) and multi-factor authentication (MFA).

Security is always a big SaaS challenge. As with any SaaS, access usually requires a platform credential.

The problem is, organizations worldwide use an average of 112 SaaS applications. Deploying and managing individual credentials for each platform quickly becomes impractical.

With more credentials to keep track of, employees cope with easy-to-remember but insecure passwords, or they simply reuse the same credential across multiple accounts.

This amplifies identity-based risk, especially for organizations built around on-premises Active Directory.

Today’s go-to solution is to use SSO to consolidate multiple SaaS logins under a single credential. SSO makes life more manageable for everyone.

Users love using one credential for access to different services.

Meanwhile, security teams gain because there's only one credential to defend. Plus, they can protect it with stronger security policies, such as MFA and access monitoring.

But for on-premises Active Directory environments, implementing SSO isn't always easy.

It seems simple, but implementing SSO for SaaS apps like Salesforce brings security risks and complexities. Organizations with on-premises and hybrid Active Directory environments won't want to underestimate:

• SSO doesn't take away the need to enter a separate password (in most cases) to access a workstation. SSO will consolidate the process to log into multiple SaaS applications, but on its own, it won’t lower the total number of logins to only one.

• SSO can also create a single point of failure. This means attackers can access Salesforce plus any other SSO-enabled SaaS apps if they compromise the SSO credential. That’s why organizations offering SSO authentication do well to implement it alongside extra security layers such as strong password policies and multi-factor authentication (MFA) . Together, these security measures reduce the chance of a compromise. Many SaaS apps like Salesforce already require MFA (read about the Salesforce MFA requirement).

• Organizations must choose which identity system to use for SSO authentication. The most common answer is to integrate with a cloud identity provider (IdP), but this means organizations hand authentication over to an external service provider. For some, this expands the attack surface beyond what their security goals or compliance requirements will allow. Importantly, it can also increase the cost of SSO implementation, including essential security protections such as MFA.

When last we checked, Salesforce does not charge extra for SSO on their end.

On the IdP side, there are often high per-seat charges for SSO. And that's only the first part of the implementation bill. The next stage is MFA, which is usually a separate cost.

Why does this happen?

Largely because, in the Windows platform, services such as SSO and MFA have always been seen as add-ons that are necessary only for high-risk users.

Today, IT security best practices point to the need for security across most or all accounts, but the old model persists. If you want the convenience of SSO or the security of MFA, the status quo expects you to arrange (and pay for it) on your own.

The irony is, many organizations already have an in-house authentication platform in the form of Windows Active Directory (AD). For these organizations, it may be unnecessary to rely on an external IdP for SSO implementation.

This is who UserLock SSO is for: organizations that prefer to implement SSO through their existing on-premise infrastructure.

The philosophy behind UserLock SSO is that these organizations already have what they need to make the technology a reality without overpaying for external platforms.

At the core of on-premise networks is Active Directory (AD), responsible for authenticating users when they log in. Implementing UserLock SSO allows organizations to continue using this directory service, hugely simplifying the time and cost of any integration with a third-party IdP or SSO platform.

Admins can configure SSO using UserLock SSO’s built-in tools and wizards, turning a potentially onerous setup into a manageable project. Importantly, they don’t have to go elsewhere to add essential security layers such as granular MFA and user access controls, which come with UserLock out of the box.

With UserLock SSO in place, end users no longer need to complete a Salesforce login.

Instead, the permission to access Salesforce becomes part of an employee’s network login. It's that login that gives them access to any line-of-business SaaS resources, with just one credential.

Admins can decide whether or not to give an employee permission to access Salesforce using UserLock policies.

To configure this, admins first set up the trust connection between UserLock SSO and Salesforce in both consoles. At the Salesforce end, this can be done either manually or, more simply, with the aid of metadata.

Find detailed instructions for configuring UserLock SSO for Salesforce in the configuration guide.