The other day I opened a fresh Salesforce org for my fellow Fluidians for sharing some technical best practices and ideas among the team members. Once I had that opened, I had it clear in my mind that I would also setup our core Salesforce org as the authentication provider for this fresh org. For those of you who don't know, this is a feature Salesforce launched about 1,5 years ago with the aim to allow social sign in using credentials from services like Facebook, LinkedIn, Salesforce and Google (some via utilizing Janrain). We get questions about single sign-on very often and I thought it would be good to share one use case for the latest Salesforce Identity features.
Although social sign in works pretty well, handling user provisioning also nicely, I wanted seamless single sign-on experience. So, knowing that it has been possible for some time now also to use Salesforce as SAML identity provider, I decided to give it a try. My requirements were:
1. Single sign-on from our core Salesforce org (A) to another Salesforce org (B).
2. If a user has fluidogroup.com or fluido.fi username in A he should automatically be enabled for login to B.
3. If the user is deactivated in A deactivate him also in B.
The requirements 2 and 3 are definitely the hardest and made me look for a proper approach for some time. Single sign-on still requires that you have user created in the org. I wanted to keep user syncing as simple as possible, so I chose to implement user provisioning on the fly combined with integration job for user de-provisioning.
First, I enabled identity provider in org A (Security Controls – Identity Provider). This gives some attributes that I then used in org B, where I enabled single sign-on (Security Controls – Single Sign-On Settings). Next up, I created Connected App in org A, using SSO attributes that I got from org B (Manage Apps – Connected Apps). This used to be under Service Providers in the Setup menu, but by Winter 14 is now done here. This config gives you the “IdP-Initiated Login URL” with format “/idp/login?app=0sp20000000AbcXyz” that you will use to login to the service provider, namely the org B.
At this point, I had single sign-on working, given that the user was already existing in org B. Now I entered the iterative phase of the setup - I needed to configure Custom Attributes for the on the fly user provisioning to work. All required user fields need their own attribute. For example the required key value pair needed for username is: User.Username => $User.Username & “.myorg”. Notice that you can write formulas in the value, which makes it more interesting! In my case I used formula in username to block login for certain users. I ended up with setup similar to below:
You can further add the connected org login in the standard App Launcher tab with your own logo. App Launcher may not show by default – you may need to request salesforce.com support to enable Salesforce Identity org level permission.
Note that if you want to test the login with other users, do not use the “login as user” if someone has granted login access to you. Single sign-on does not work with it, resulting in “Insufficient Privileges” message, that may leave you scratching your head.
Happy spring time!
Head of Development