I recently implemented SSO with SFDC as the IdP and wanted to share a few of my experiences and stumbles along the way to hopefully smooth the process for others. Overall I (and more importantly my Sales team) are pleased with the results. First our configuration details:
E10, Eloqua for Sales (Profiler/Discover, Engage)
SFDC Enterprise Edition
Configuration
The Eloqua SSO configuration guide Salesforce SSO (IDP and User Provisioning) - Configuration Guide is complete and easy to follow as far as setting up Salesforce and Eloqua. You'll be making changes to both systems sequentially switching back and forth between the two through the process. On the SFDC side you'll actually begin by creating a unique sub-domain that will become your new SDFC URL for login. The process is easy but takes about 15 - 20 minutes for approval and then propagation by Salesforce. So where your login currently is https://login.salesforce.com it will become https://[uniquename].my.salesforce.com. I used my company name as the unique name. Salesforce maps the old login to the new domain so SFDC users won't see any difference or even need any training to use the new login. Per the Salesforce warning, once you change over to the new SSO domain you apparently can't go back. I don't know whether this would impact your ability to shift to a different SSO option (e.g. corp IT LDAP as IdP). For our case the convenience of single sign on via Salesforce was sufficient reward and motivation.
SSO and Eloqua User Administration
One surprise was that once you've set up SSO you no longer control aspects of Eloqua User Administration within the individual Eloqua User record, rather you map SFDC Profiles to Eloqua Security Groups. After SSO is enabled the User and Security Group sections are 'locked' and controlled through SFDC (user access), or Eloqua SSO section (SFDC profile - Eloqua security group mapping). So for example a Profile of "Sales Reps" in SFDC might map to "Sales, Discover Users, Engage Users" security groups in Eloqua. You'll want to think this through before you start the SSO set up process as the mapping happens at a late step in the process. You can change the mapping any time you wish through the "Single SignOn" link in the top level Eloqua Users section.
Linking SFDC user IDs to Eloqua users
At the bottom of the Eloqua user record you'll find a field call Salesforce User ID. If you haven't already set these up you'll need to copy the SFDC User ID (from SFDC URL or user record) and paste it here. And then make sure to click the "link' button. You'll get a confirmation on the top of the page when the link has been authenticated and confirmed. I didn't realize 'link' was a button and merrily pasted all my SFDC IDs in all my user records and then when it didn't work had to go back to each user record and click the button.
SSO and Discover
There's one critical missing piece in the guide, however, if you have the Discover-SFDC object. The guide only provides instructions for the older Profiler-SFDC object. Eloqua Support apparently hadn't seen this situation previously and it took some time to identify and resolve the difference so please make sure you get the correct information based on which of the objects you have. If you have Discover here's how to set it up:
At the 'Configuring Profiler' section of the guide (linked earlier in this post), where it provides the URL to update on your Profiler Lead and Contact VisualForce pages you'll 'discover' that the Discover VisualForce page doesn't have an embedded URL like the older Profiler VisualForce pages did. What you need to do is to take the updated URL exactly as described in the configuration guide and use it to update the ACS URL entry that you'll find at:
Setup/Administration Setup/Security Controls/Identity Providers/
You'll see "Eloqua" listed in the Service Providers section. Select Edit and then very carefully edit/update the ACS URL field with the new path. The Entity ID field displays the exact same URL
With this change made your SFDC users will now see the Discover/Profiler object automatically display on their lead/contact views. No more manual login required.
Hopefully these few tips will help you approach SSO better informed and for your implementation to go a bit more smoothly.