Allows users to enter their password once, into an identity provider… and then use that athentication for other apps that are connected to that iDP.

Means that you only store user authentication details in one location, and it is easier for the users to only remember one username and password, and the user management (eg adding and removing users, or restricting or increasing access) can be done in one location.

Users generally like it because it’s much easier for them.

When we talk about SSO there is two forms of SSO,

• Inbound - Salesforce as a Service Provider (eg Salesforce is the service that Okta can log into)

• Outbound - Salesforce as an Identity Provider iDP - Salesforce Identity (eg use your Salesforce credentials to log into Workday). This is Salesforce Identity.

• Note that Salesforce can be both a Service Provider and Identity Provider simultaneously.

Why SSO

You start with a Password Manager, then you do shared password folders, then it becomes a bit cumbersome to maintain who has access to which apps. Then you have to provision multiple people on multiple apps. Each time you get a new app you need to set it up for all users. Each time you get a new user you need to set them up on all apps. And when they leave you need to lock them down really quickly. And what if you forget one.

If you have more than a team of 3 or rely on more than 3 critical business apps, then I think it is worth looking at SSO. I am one person and have many critical business apps and even I hate the burden of keeping all the passwords and user access working.

If any of this starts to become a struggle, get an SSO. Don’t wait until it’s too late.

Note that Salesforce can be your SSO, however, I still think it is good to get a third party SSO so you don’t have all your eggs in one basket.

Terms

• Salesforce Identity - where Salesforce acts as an iDP

• iDP - Identity Provider - the server providing the authentication

• SP - Service Provider - the service you are logging into

• IAM - Identity and Access Management

• SAML - Security Assertion Markup Language

• SSO Flows

• SP initiated

• IDP initiated

• JIT Provisioning - Just In Time - users are created in Salesforce from iDP

• 2FA / MFA - Multi Factor Authentication

• AD/LDAP - Active Directory

• OpenID

• SIEM

• SCIM

SAML

• “XML-based standard for exchanging authentication and authorization data between security domains, that is between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).”

• You log into somewhere, you are granted access and get a session token. SAML passes that session token to another app to log you in there.

• 3 Roles

  • User

  • Identity Provider

  • Service Provider

SAML Assertion

• The iDP asserting that the user is legitimate. It contains

  • The iDP Digital Certificate

  • The Name of the iDP (Issuer)

  • The Name of the Service Provider (EntityID)

  • The User ID (Subject)

    • User ID can be a Salesforce UserName or fully qualified AD Name eg NORTHWINDTRADERS\JMiners

  • With JIT Provisioning the SAML Assertion needs to provide

    • Email

    • Last Name

    • Profile Name (or ID)

    • User Name

    • Optionally any ther attributes from the AD such as Department, First Name, Manager etc

Salesforce Identity

Where Salesforce acts as the iDP

• Application Launcher

• Restricted/granted application access

• Can automate provisioning using standard Salesforce features like code and flow

• Can report using standard Salesforce reports

• Can purchase Salesforce Identity licences only for those users that don’t use full Salesforce.

• Pre-built integration to use Active Directory as credential store

• SSO via

  • SAML

  • OpenID

• Can use Social Logins (eg Google, Facebook)

• SAML allows users to be automatically created in Salesforce when added to your AD

• Can deep link into Salesforce from other services. This is then a seamless experience for users.

Identity Connect

The app that syncs Salesforce users with Microsoft AD. It’s a one way sync from AD to Salesforce.

SSO Apps

These apps can be used for SSO, they are the main apps used.

General Features

• 2FA/MFA

• Salesforce is a supported app out of the box

• They are reasonably priced

• Syncs to your AD/LDAP service

• Logging

• Users don’t know their passwords to specific apps so that in itself is good security.

Okta

• Not just SSO but a full security suite

• Allows 2FA

• Can build your own integration to apps not supported out of the box, but there are over 6500 integrations included

• Can be used for API athentication

• Salesforce is a standard app to connect to

• Users can add any site they visit, to their Okta sign in, if it is an Okta enabled site. (If it’s configured this way, I log into an Okta iDP for a client but it’s a heavily regulated industry so they only allow specific apps). So sort of like their own Password Manager.

• Syncs to your AD/LDAP server, even On Premise (why do you have an On Premise AD, there should be no reason for On Premise anything for small business).

• Logging can be integrated with third party SIEM logging

• Can do biometric login

• Starting at US $2/u/m

• Get Okta if you are in a regulated industry, or have a larger workforce, or anything more than just a few uers logging into a few web apps.

OneLogin

• On the face of it very similar to Okta

• https://www.onelogin.com/product/pricing

LastPass

• A password manager that can grow to be an SSO and MFA option

• https://www.lastpass.com/products/identity

• Can have shared password folders.

• Good for small and growing busineses who have Microsoft Office 365 as their user management

1Password

• https://1password.com/enterprise-password-manager/

• This is more pricey than LastPass

• But has a really nice travel solution so you are not taking passwords across borders when devices can be seized

• As a password manager, for me logging into multiple Salesforce orgs, it works better for me than LastPass, but I don’t know what it’s like as an SSO tool

• Can integrate with your AD/LDAP service, plus can integrate with Okta.

• Probably better suited to highly technical companies

Flows

iDP Initiated SAML Flow

• User signs into iDP

• SAML Assertion passed to Salesforce

• Salesforce logs in and issues a Session ID

• User is logged in.

SP Initiated SAML Flow

• Usually used for Deep Links into Salesforce

• Is needed for Salesforce Mobile

• Steps

  • User clicks on a Salesforce link

  • If necessary they are taken to the iDP for login

  • iDP sends SAML assertion back to Salesforce

  • Salesforce issues a Session ID

  • User is directed to the page.

Delegated Authentication Flow

• Reqires a WSDL

• You need to contact Salesforce to have it turned on

• Steps

  • User logs into Salesforce

  • If Delegated Authentication is enabled for the user, request details from Delegated Authentication Server (User Credentials are encrypted and passed to the DAS

  • DAS sends true or false back to Salesforce

  • DAS passes credetials to Authentication Provider for verification

• Requires a proxy server to be created

I don’t understand this. Is it old? Not used anymore? It seems to be. I probably only need to ever know about this for the exam, and know enough to know to not use it.

Social Sign On

• Usually used for communities to allow people to log on with their google or facebook credentials

• Social Sign On is widely accepted by users and often demanded by them. I know I use it all the time.

• You can set up to log into your Salesforce org via Facebook Social Sign On but oh dear, why would you?

• Steps

  • User tries to log into Salesforce

  • They choose the social sign on provider and log into that provider (or they may be logged in already)

  • If the service has not been linked before the third party service asks you to authorise Salesforce to use the social sign on credentials)

  • Some Apex code in Salesforce uses information from the authentication provider (eg google) to create or update the user record and creates or updates the contact record if the login is for a community.

  • The user is logged in.

Best Practices

• Don’t set up SSO for System Administrators because if your SSO goes down you won’t be able to login. But still set up MFA for Admins.