Salesforce Customer Portal is the Force.com ISV’s natural choice for providing support to users of their applications. However, requiring customers to log in to a Customer Portal using a Salesforce username and password which is separate from their own Salesforce login is cumbersome.
Fortunately, you can configure single sign-on using OAuth, with Salesforce as the identity provider for your Portal. This means that Portal users are identified by their Salesforce user accounts in their own orgs.
This was the approach taken to deliver the FinancialForce Community, which was launched at Dreamforce 2012.
Single sign-on is convenient for your customers, as they can move seamlessly from their own org to your Portal without being challenged for a separate username and password, but this also allows you to automatically update your customer Contact records via the single sign-on process. When the customer first signs-on via OAuth they must agree to share their user information with you in order to complete authentication.
There is a small problem however, relating to sessions. When a customer logs in to your Portal (whether by username and password, or by OAuth) a session id cookie for the Portal session will be created. If the Portal and the user’s own org are on the same domain, say na1.salesforce.com for example, then the customer’s session id for their own org will be overwritten. They could not work simultaneously in both their own org and the Portal, and they would need to log back in to their own org when they finish with the Portal. However, we can overcome this by using a Force.com Site to ensure that your Portal is on a unique domain, for example: foobar.force.com
I will be walking through the steps needed to set up single sign-on into a Portal using Salesforce as the identity provider, and using a Site to make the Portal domain unique.
I will be treading as narrow a path as possible, so I will not be covering detailed Portal or Site configuration. As we’re configuring single sign-on between orgs, we’ll be using two orgs – a vendor org which will host the Customer Portal, and a customer org where we will have our user who will access the Customer Portal via single sign-on.
I recommend working through this process using a trial or developer vendor org before attempting the same in a production org – some steps are irreversible! I am using a clean Developer Edition org for my vendor org, and a second Developer Edition org as my customer org.