Understanding SSO with External Login

Overview

When you implement single sign-on (SSO) by using an external login, users can choose to log in by using Facebook Connect, or Google OpenID Connect.

This article provides information about using SSO with external login and migrating existing users.

Information

External logins are a good choice for public communities because authentication can be passed to a third-party provider. The community user enters credentials on the provider site. The authentication token is then passed back and verified on the Jive side. Community users can log in with a number of different providers and have all their details pre-populated. For sites that support an avatar attribute, avatars are synchronized as well.

An external login implementation can include Facebook Connect or Google OpenID Connect authentication. Both Google OpenID Connect and Facebook Connect use the Attribute Exchange standard for exchanging information, which enables Jive to pull in profile information about new users. After logging in, the user sees a confirmation page and can verify profile information, pick a username (if this information is not prepopulated from the profile), and proceed to the Jive community.

Migrating Existing Users

If you have not yet implemented SAML, the best practice for migrating users is to enable Username Identity to look up existing users by username. In most cases, you should also enable Merge Local Users to ensure that existing users are automatically federated. This recommendation assumes that either the email address or the username matches between existing accounts and the SAML response. If neither of those fields matches, you can:

• Update the existing email addresses in Jive before using Username Identity to sync them.
• Update the usernames in Jive before using the username identity to sync them.
• Add the external IDs in Jive and federate the users by using another method.
  You can use the REST API or, if you need more assistance, a partner or Professional Services can handle this by creating a database script.

If you have non-federated local users that you do not want to merge, you should not select Merge Local Users. Instead, mark only the accounts you want to merge as federated before enabling Username Identity.

Back to top