As a part of Customer Data Management, the ability for customers to use an existing (usually social based) identity to gather basic registration information, is key to lowering the bar for customer acquisition. In this phase of CDM, we will enable the capture, storage, updating and deleting of all social identity data from several providers including any OAuth2 based or OpenID Connect based IDP and FaceBook, Google+, Twitter and other ranked Social IDPs in accordance with customer and market demands.
OpenIDM/CDM administrators should have the ability to configure user registration process to enable one or more existing (social and other) providers where customers have an existing account.
Users are first directed to a branded web site, they are provided an opportunity to register. They will see a set of familiar logos which will allow them to consent to the web site gathering and using Social IDP data, rather than creating a new, web site specific user account. Once a user chooses a social IDP to use for registration, they are presented with the appropriate consent dialog from the associated Social IDP (FaceBook for example)
Upon logging in and consenting to IDM's requirements users are redirected back to IDM where IDM will retrieve the user's social profile and list of associates on that social IdP. If the social IdP profile passes all of IDM's managed user attribute policies then the user will be directed to their IDM profile page where they can manage their consent settings. If the profile does not pass the policies then the user will see a partially pre-populated account registration form where they may correct the issue and/or add any missing required data. Upon submission of that registration form the user will see their IDM profile page.
Users who opt to enable an additional social IdP will follow the flow above except for the policy requirements and registration steps. IDM will collect these additional social profiles and store them just as the first but the data is not used to modify their managed user profile. These additional enabled IdPs allow the user to log in via these additional credentials and allow IDM to collect their profiles.
Disabling any social IdP disables login via that IdP and prevents export of that IdP's profile data to marketing targets but it has no effect on the profile data in their stored managed user.
RESTful interface to enable, disable and configure social IDPs, as well as the ability to list all currently enabled Social IDPs.
As an Administrator, the configuration of Self-Service registration should now include Social IDP selections and the associate (site specific) configuration for each of the providers. Administrators should be able to configure as many social providers as they choose to support in order to offer registration services to end users.
Providing the capability to capture rich customer data while easing the registration and authentication process is the key to higher registration rates and better data (as social IDP data tends to be more up-to-date than dedicated, single purpose accounts).
From a consumers standpoint, Social registration allows consumers to quickly and easily register for accounts and log in to your websites or mobile apps using their existing social media identities. By authenticating their identities with social login, users give brands permission-based access to the identity data housed within their social profiles. Today, there are more than 30 networks that consumers can use to authenticate their identities. These identity providers range from social networks to email and payment providers.
Top Tier Social Providers include (but are not limited to):
*Oauth 2.0 (several IDPs)
Second Tier providers might include:
Prospects have told us that even though they have existing cIAM/CDM solutions - but don't like the limitations. Easing a migration from other solutions would be beneficial for ForgeRock and our customers.