What is Customer Portal Open Login?
Environment:
Customer Portal Open Login, February 2011 and newer
Resolution:
Beginning in the February 2011 release, you can login to your end user pages using an account that you already have through another identity provider such as Facebook or Twitter.
Effectively, this means that you can authenticate into your CP pages with your Facebook, Twitter or Gmail accounts, or conceivably, with some services assistance, any login that they have with an identity provider that supports Open ID or OpenAuth 2.0
If you are updating a site to the February 2011 release you will not get this feature automatically. Once you update, you will need to copy standard pages containing the new functionality and absorb those pages into your CP deployment.
Choosing the Identity Provider – Facebook Example:
- Click Facebook button to open the Facebook authentication page (and short description on what is about to happen)
- Click Login with Facebook button to access the Facebook login page (in the majority of cases)
- If you are already logged into Facebook but have not made your email address public in the profile, the prompt permissions page will be displayed and the user needs to click ‘Allow’
We recommend its usage in all but two cases
Case 1: Customers have a user base already with a large number of users with contact records
If the user already has a contact record with you and then you give them the option of logging in with Facebook etc, you are letting them (potentially) create a second account, which they will do if providing a different email address. This fragments your view of individual customers across several contact records. It is recommended that you discuss this issue with customers; install base customers who prompt for login prior to allowing the customers to go to an Ask a Question page are recommended to change page flow prior to making this capability available to their consumers.
Case 2: Customers using Householding (Email Address Sharing)
Since every trusted, verified federated login provider is based on the assumption that one email = one user, that is the premise that we in turn must accept.
- If E-Mail sharing is enabled, contact creating and updating is the same.
- If no contact with the provider-supplied email address exists, then one is created.
- If any contacts with the email address exist, then the first matching contact in the database with that email address is used.
- Any channel type or openid_accounts rows that are added or updated are associated with that first contact. The same API that is used across the product (contact_match) is used here; so whatever contact is returned by calling contact_match() with the user’s email and first and last name (if the first name and last name are provided by the provider) is the contact that is used.
As a result, it is advised not to use this feature if you use E-Mail sharing outside of its intended use case (to ‘version’ an account for example, with the last contact being the ‘live’ customer record)
