Salesforce supports many Auth Provider out of the box, which can be used as Identity provider. Some of the examples – Facebook, Google, Github, Salesforce, OpenId Connect , Linked In and Janrain.
If you are in need to use Wechat , Yahoo or some other social account like Microsoft, don’t get disappointed. Even if they are not available out of the box as Auth Provider in Salesforce , Salesforce has provided magical box Janrain. Janrain supports vast list of social platform which can be used as Identity provider for your Salesforce instance.
How Janrain is different compared to other SSO solutions for Salesforce
If we configure Identity provider for Salesforce using Single Sign On or Auth Provider, those options will appear on Login Salesforce page as a button (shown in below image).
Below are important summary about Identity Connect
It comes as add on feature with Salesforce with additional cost
Only works with Active Directory
Its only one way Sync, from Active Directory to Salesforce
We can assign profile, role and permission set to user using Identity Connect
Any changes made manually for mapped field on user record would be overwritten with next sync.
Sync from Active directory to Salesforce can be realtime or scheduled
If the user is deactivated in Active Directory then user record also gets deactivated. Identity Connect internally uses API to deactivate user. Unlike for some other SSO solutions, if user is deactivated in Active directory then they cannot login to Salesforce. However, if they already logged into mobile phone or connected app then they can still access Salesforce. This problem is resolved in Identity Connect.
Identity connect is installed on client network behind the firewall. Identity connect pushes the changes to Salesforce from client’s network.
If we want to use Identity Connect as a SSO and user wants to use Salesforce from outside company network or on mobile phone, then its login page must be accessible on internet. This can be done by installing Identity Connect on De-militarized Zone (DMZ).
Identity connect is used for User provisioning but not for Just in Time (JIT) provisioning.
We can use Identity connect as a SSO. If customer already has SSO implemented then Identity connect can only be used for user provisioning.
One Identity Connect can be used for multiple Salesforce instances however all production or all sandboxes. If you want to use Identity connect for production and Sandbox at same time, then we would need two Identity Connect, one for Sandbox and other for Production.
Identity Connect will work with only one Active Directory but it can have multiple domains in same AD.
Integrated Windows Authentication (IWA) is supported by Identity Connect using Kerberos authentication protocol. Means, if user is already logged into company provided windows system, then login screen would be bypassed and Salesforce login experience would be seem less.
Scheduled sync uses more API’s then realtime schedule. Because, Schedule sync checks for changes in all Salesforce users vs all AD users.
If you are new to Microsoft Azure, you can get free trial access however you might need to provide Credit card details to use few features. You would not get charged because we get $200 worth credit for new Account that can be used in a span of year.
I was not able to use Azure’s Active Directory SSO for Just in Time (JIT) provisioning. Rather, it connects to Salesforce and creates user whenever user is provisioned in Active Directory, just like Identity Connect
Security token is mandatory. In case if you have IP login range then we don’t get Security token. To fix this, we can divide our password to have some value in Security token. As final password anyways is Password + Security Token. Shown in below image
When we assign any user to Enterprise application (in our case its Salesforce), we need to map profile to the user.
After writing this article Salesforce has enabled CSP (Content Security Policy) which restricts adding Salesforce in iFrame. We can add MyDomain URL as CSP whitelisting and it works only if user already logged into other Salesforce instance. However, if user is not logged into other instance , internally OAuth navigates through login.salesforce.com which is too restrictive and canvas application fails to load.
In this post we will discuss how Canvas can be used to integrate Salesforce with Salesforce. On my blog we have seen many articles and possibilities to integrate Salesforce with another Salesforce instance like this and this post.
Whats is force.com Canvas
Why we are accessing another Salesforce instance as Canvas app
To get hands on with Canvas, most of article are around creating Heroku applications. I understand there are few developers who are not comfortable with Heroku. So to keep learning curve less, lets use Visualforce page to be exposed as Canvas application after all Visualforce is very advance MVC framework in itself.
Before starting you have to decide which salesforce Instance will act as Identity Provider and which one will act as Service Provider. To Avoid confusions, we can create app with different Logo to distinguish Identity Provider and Service Provider like I did.
Step 1 : Enable Domain in Identity Provider Organization
From Setup, click Domain Management | My Domain, enter a new subdomain name, and click Check Availability. If the name is available, click the Terms and Conditions check box, then click Register Domain.
In this post, We will be dicussing how to setup Federated SAML based Authentication in Salesforce.
SAML stands for “Security Assertion Markup Language” and it is Open standard for exchanging Authentication and Authorization between Systems. SAML based authentication is supported by all editions of Salesforce.
User Validation can be initiated by any one of below two types:
Service Provider Initiated SSO
Identity Provider (IDp) initioated SSO
We are going to use Identity Provider Initiated SSO in this article. Means User will Login from Outside(IDp) and will be redirected to Salesforce (Service Provider). Identity Provider must follow Federated Authentication (SAML) standard which should be deployed to DMZ (URL should be publicly accessible on Internet) layer of your Organization. As a Salesforce developer you should assume that you will always get IDp URL which implements SSO and implements valid SAML response. To Quickly start with this tutorial assume that your organization already deployed SAML based Authentication endpoint and for that we will be using great Heroku app available freely as open source named “AXIOM“.
AXIOM is java based heroku application which implements SAML and can be used for testing purpose to check whether SSO is working properly or not.
IDp Initiated Single Sign On :
In IDp Initiated SSO, User Directly logins to Identity provider and IDp redirects user to proper Salesforce Instance with SAML assertion in request (Service Provider). If SAML assertion is valid then Salesforce validates that user successfuly.