Social Registration with vKontakte
This article talks about the customizations and configuration necessary to enable social-registration with vKontakte, and further a quick demo of the end-user experience. This is not part of the product yet, and I built it using a clone of the OpenIDM trunk. From a vKontakte API instance standpoint, you do need to create a client instance and VK will provide a client secret to you. The scopes available are sending notifications, access to friends, access to photos, access to audio files, access to videos, access to documents, access to proposals, access to questions, access to wiki pages, status updates, access to notes, access to wall, access to groups, access to replies, stats access, access to products. The only scopes needed for this demo are email, but I included status and notes as well.
vKontakte uses an OAuth2 like 3-legged flow for authorizing a user with some exceptions in how the JSON responses are formatted. In that it is similar to OAuth2 helps in creating interfaces to the social authorization filters inside OpenIDM but the dissimilarities necessitate creation of a new authnfilter module and some rewriting of the OAuthHttpClient inside the identity-provider module in OpenIDM. The email is not recevied from the userinfo endpoint, called getProfiles but is returned along with the access token. Further, changes are necessary at the javascript layer to resolve specific redirects to vKontakte endpoints. Another complexity is that the state returned is url decoded already – for no fault of vKontakte- but it is tough to take the state returned as-is because we need to know what query parameters were embedded by OpenIDM to begin with. So we must url decode and pack into a new state to return param by param. Therefore changes are necessary in the oauthReturn.html callback URL to support parsing back to the correct state received from vKontakte, in order to continue the OAuth2 flow.
Administrative Experience
Add the vKontakte configuration to identityProviders.json using the configuration example for Google in the same file.
Next, turn on the vKontakte provider in the Social ID Providers menu:
Enable user registration, and any custom Terms and Conditions needed for social registration.
At this point you will have the basic plumbing in place to support users registering their accounts via vKontakte. However, since vKontakte will not provide a username in the format you prefer, I strongly recommend modifying the Social Registration Properties transform scripts to accommodate or pre-fill any attributes you want. For example, I remove all spaces from the full name returned by vKontakte to create a username:
One could also write a transform script to verify the email address for example.
End User Experience
The following is the flow for social-registration with vKontakte.
The user clicks on the register link after navigating to http://domain-registered-with-vKontakte/#login.
The user is then presented with the previously configured (by the admin) Terms & Conditions screen:
After accepting the T&Cs, the user is taken to the Registration page:
Upon clicking the “Register with vKontakte” link, the user is taken to the vKontakte site and presented a login page as follows:
After logging on, the user must consent to grant access as follows:
Allowing the access takes the user immediately to the following page that shows the user data made available by vKontakte:
vKontakte did not provide me the email address from the userinfo endpoint, but it was provided as per the requested scope along with the access_token. Some logic in the OAuth HTTP client takes care of pulling the email from the json response and adding it to the getProfiles json response for OpenIDM to process.
Save the profile and a confirmation appears stating I registered successfully unless you have a KBA stage configured as well:
This completes the social-registration portion. The next step is to be able to login from vKontakte into OpenAM and achieve seamless sign on to OpenIDM.
