Open ID

Overview
There are many OpenID login systems currently in implementation in Mobibook, some developed by Webspiders, others developed by 3 rd party teams. This documentation should give a steady knowledge of OpenID's implemented by us, and a small overview of the implementation by 3 rd party vendors. Following OpenID's are in use in Mobi-book as of present:1) 2) 3) 4) 5) Google (made by Envision) Twitter (made by Envision) Facebook (made by Envision) Au (made by WS) Rakuten (made by Rakuten)

There are basically 2 types of Open ID login systems, Normal Open ID login, and BSV Open ID login, which also tie in with the Simulatenous Login rules. The core concept of how OpenID works is:User wants to login via X open ID, it sends the user to the Open ID provider, where user logs into the provider and is returned back to the Storefront, with certain additional information in form of parameters or by POST. The system checks whether the correct response code is returned which would signify authentication is true in certain cases, retrieves these info and checks with internal DB whether the identification for that user matches information contained in the system, if not a new registration is done. If it does, then it logs the user into the system. Implementation of authentication, which parameters are sent and how they are handled in our DB differs in the different OpenID's.

Au Open ID
Currently AU Open ID is implmented for Au based sites only. Normal Login Flow User clicks on the login button from homepage, and gets redirected to /Account/SignInAU, where url to AU open ID provider is created including url to return to, then redirects to AU provider, where user will have to login. If login is successful on AU end, then user is sent back to the return url. /Account/AuthResult. On returning to SF, system checks whether the authentication was successful, and obtains an unique ClaimedIdentifier, which uniquely represents the AU Open ID user. The DB is checked whether a user exists with au open id unique identifier. If it exists, then it returns a valid username and password (encrypted). User Exists User is logged into the system, using credentials retrieved from the database. User Does Not Exist If the user does not exist, then a free user is created, with username made from the partial info taken from the identifier, email is not returned by the AU provider, so email is set to username + @email.com, dummy email address. Password is generated based on the username. As same usernames cannot exist in the SSO, for multiple AU sites, during registration, username is appended with Storefront id. This user is mapped with a free plan. Then logged into the system. In both cases, during Login, user must be logged in with LoginHelper.LoginUserExternal, as the password being supplied is aldready encrypted. In the case that user is by chance aldready logged into the system, before sending it back to the LogOn page for Simultaneous login, the Tempdata value TempData["LoginExternal"] , must be set to true. BSV Login Flow (note that this flow will remain almost same for all open id logins except for which parameters are passed or to which login urls it is redirected for authentication.) User accesses url, SiteURL/Account/OpenIDLogon?u=BSV&b=AU (extra macid parameter to be added in case, of Device Access Limitation feature is active on the site). Session variables are set intiating the flow, and user is redirected to /Account/SignInAU, here parameters from appsettings are taken including the au login url, realm and return to url, and send in similar fashion to Normal login flow. On return via /Account/AuthResult, it follows the same process as Normal login,

except instead of logging into the site, it checks the Session["BSVDeviceType"] variable, which is set intially in the BSV login flow, and saves a Subscriber object containing at least the username and password (if any) in the Session["BSVSubscriberInfo"] object and redirects to /Account/BSVLoginV2 On arriving at BSVLoginV2 action, the encrypted password is obtained from the DB, using the username, from the Session["BSVSubscriberInfo"] object, Using username, password, macid (if applicable), and device id, the IsAuthenticatedUser web method is called. The returned xml is then parsed for the values, Status Description, and DeviceRegistered (if Device Access Limitaion module is enabled). A BSVUserInfo object is created, and username, password then if IsAuthenticatedUser returns true, status is set to true, and authtoken, set to the token generated. If IsAuthenticatedUser does not return true, then the error code returned is set to status and AuthToken parameter is set to blank. This is then redirected to /Account/ReturnFromSocialBSV with parameters in the BSVUserInfo object as query string parameters. On reaching, /Account/ReturnFromSocialBSV, Session objects related to BSV are set to null, and parameters from query string are used to build an xml which which is returned to BSV. The resultant xml will be in the following form:<Result> <Status>true</Status> <Auth>4v4Dfw6oP;;P2kh</Auth> <UserName>7yynNumK69vM2TaD6vKd8g==</UserName> <Pwd>E:7D3C8F3DC8930BA3A78BE989D505A46F</Pwd> </Result> if login is successful. <Result> <Status>E0081</Status> <Auth></Auth> <UserName>7yynNumK69vM2TaD6vKd8g==</UserName> <Pwd>E:7D3C8F3DC8930BA3A78BE989D505A46F</Pwd></Result> if login fails. The BSV inturns checks the xml, and accordingly logs the user in the BSV, if login is successful, if it fails then it displays appropriate error, and if error code is E0081, in which case it is unsuccessful due to user being logged in same device, then user is prompt with a message which asks the user whether user wants to be logged out in other devices. If user taps YES, then the username and password returned, is used to call the IsAuthenticatedUserForced method in the api to forcefully log the user in and kick others users logged in accordingly to simultaneous login rules.

Rakuten Open ID
Currently implemented in Mobibook storefront. Normal Login Flow To generate the login button for Rakuten, one needs to place this code on the page.
Hashtable rakutenConfig = new Hashtable(); rakutenConfig["return_to"] =Forside.Services.UtilityServices.SettingsSFUI.RakutenReturnToURL; rakutenConfig["loginButtonImage"] = Forside.Services.UtilityServices.SettingsSFUI.RakutenLogoImage; <%=RakutenAuth.LoginForm(rakutenConfig)%>

And specify the Return url and image which will be used for rakuten login button. The LoginForm method should generate the appropriate html to login to the Rakuten Provider. When user clicks on Rakuten Login icon, user will be redirected to the rakuten provider, when user enters correct credentials, user will get returned to the return url, currently it is set to /Account/Logon, where it checks for return parameter openid.identity. A hashtable is created using the query string parameter and checked via method ValidatingOpenID, to ensure it is returning from Rakuten Open ID. The Rakuten unique identifier is saved in Session object RakutenOpenId and redirected to /ReturnFromRakuten/CheckLoggedInStatus. On entering the action CheckLoggedInStatus, the unique identifier is taken from the RakutenOpenId session object and checked in the db, whether a user exists mapped with rakuten open id, this is queried in the table tbl_mst_social, with social id and socialtype as Rakuten. If it doesnt exist, it moves to create a new free user, mapped to a free plan, adds in information like a normal subscriber and is mapped to rakuten in the tbl_mst_social table. If not it is simply logged into the system, or sent to logon page again, if failed due to simultaneous login rules. BSV Login FLOW To start the BSV Login flow for Rakuten, app must launch using siteurl/Account/OpenIDLogon?u=BSV&b=RAKUTEN.(extra macid parameter to be added in case, of Device Access Limitation feature is active on the site).

Session variables are set intiating the flow, and user is redirected to /Account/LogOnRakutenBSV, which returns the LogOnBSVRakuten view, where the login form similar to login button is generated, and javascript used to forcefully submit the form, to redirect to Rakuten Provider, after authentication on rakuten's end. It is send back /Account/LogOnRakutenBSVReturn, and settings Session objects related to Rakuten Open id, it is further redirected to /ReturnFromRakuten/CheckLoggedInStatusBSV. Here almost the same thing happens as normal login, but instead of loggin in to the system directly, a SubscriberInfo object with username is set and set to Session["BSVSubscriberInfo"] session object and send to BSVLoginV2 methods, where the normal BSV flow method is continued like AU Open ID login. WorkArounds Implemented The BSV team who implemented Rakuten in BSV, made some minor changes which goes against the ideal conditions and rules to be followed by Open ID BSV (check at end). Hence this work around was needed to make this work properly. Ideally for a Japanese Open ID Rakuten, should call the login url like jp.mobibook.com/Account/OpenIDLogon..etc, however they have called www.mobibook.com/Account/OpenIDLogon, resulting in session's set regarding OpenID login flow in english site, but when control returns to Japanese site, and finding that those sessions do not exist made the user not behave strictly to the BSV flow. To make this work, what was done, was to modify the return url from regular LogOn page, to LogOnRakutenBSV, so that upon returning system would know that this was BSV flow, and accordingly set the Session ID's, and continue. Ideally speaking, if login should happen to the Japanese site, login url should be from the JP site, ie jp.mobi-book.com/Account/OpenIDLogon Additional Notes UIHelper.IsRakutenUser can be used to identify a rakuten user ShowRakuten (appsettings key) can be used to enable/disable rakuten module

Current problems Current problems that exist, are in the BSV, inapp shared login does not function properly, as upon clicking STORE icon on BSV app, it tends to login to the site using jp.mobi-book.com/Account/LoginWithToken?token=xxx, but after that it redirects to www.mobi-book.com, this will lead to opening the inapp browser in the logged out state, which is a problem, it should ideally login to Japanese site, then redirect to jp site itself.

Google, Twitter, Facebook

This currently exists only on Mobibook Storefront, the following will give a basic idea on this type of Open ID login, the basic concepts still apply along with BSV login flow which is common, however deeper details on implementation will need proper formal KT from Envision team. In any case, there is a slight difference from other OpenID's, in terms of additional configurations that need to be set in the application. In this type of Open ID system, there is one another element of interface between user and provider, called the app, this app needs to be created at Facebook/Twitter/Google, end after which the return url needs to configured in the app among other information, and will sometimes generate a consumer key and consumer secret, which needs to be set in the application config, so that when a request is send from the Storefront, the app can correctly verify that the authentication request is coming from the right site and not a illegal site. Since our SF is a multilingual site, and each seperate domain is treated as a seperate site, for each site and environment and language a seperate app needs to be created to if there are 3 languages for UAT and live each, then 6 apps need to be created and their respective consumer key and consumer secrets. Putting all this information in the config file will become confusing, so to work around this, Envision team, modified the core SocialAuth.dll, to pull the respective consumer key and consumer secret from the db depending on the domain from where it is accessed from. These keys are stored in the tbl_mst_domainkeys table. Normal Login Flow Login via Google, Twitter, Facebook is done via urls:/ReturnFromSocial/LogOnTwitter /ReturnFromSocial/LogOnFB /ReturnFromSocial/LogOnGoogle

Upon reaching the respective providers, user logs in with respective providers, and then is redirected back to the Storefront, the SocialAuthHttpModule (/socialauth/validate.sauth), verifies that the authentication is successful, which then returns to /ReturnFromSocial/CheckLoggedInStatus, where a lof of the usual checking occurs, if user does not exist then its newly created with free plan and logged on, if aldready exists, then it is simply logged on or passed to the LogOn action.

BSV Login Flow BSV login flow is almost as same as AU, except the login urls are /Account/OpenIDLogon?u=BSV&b=GOOGLE /Account/OpenIDLogon?u=BSV&b=TWITTER /Account/OpenIDLogon?u=BSV&b=FB It returns back to /ReturnFromSocial/CheckLoggedInStatus, and if Session variable for BSV login is valid, is redirected to BSVLoginV2 flow, then its same as others.

Account Connect/Disconnect The concept of Connect/Disconnect, is to simply map another provider account to existing account, if a normal mobibook user, or an aldready open id user, connects to a non-connected provider, after authentication at providers end and return to Storefront, user will map his provider account with current account from which connect disconnect is being done. Accessing the Storefront directly from Facebook app or getting invited to Mobibook SF via FB There is one other way other than logged into SF via Facebook, a bookmate can invite someone via facebook api to the SF, user who will get invite will click on the invite link upon which he can enter the SF via a Facebook app. In this flow, user is returned to SF to /Home/FacebookLandingHidden, user is then redirected to Home/FacebookLandingFinal, where user is given a choice to either continue with an existing login or continue surfing from there, in which case a new user is created for the user coming in and is logged into the system. Additional Notes a)Envision team has customized the SocialAuth-net.dll, to pull certain records from db table , tbl_mst_domainkeys, which contains the keys and secret keys to apps, set for Google/Twitter/Facebook, and for each language. b)In addition to the config changes that need to done for another SF to support this type of login by Envision, Microsoft Windows Identity Foundation needs to be installed in the target machine.

c) Make sure the dll version of Newtonsoft.Json.dll, is 4.0.0.0 any higher and it gives problems.