On 30 July 2014 18:01, Daevid Vincent <daevid@xxxxxxxxxx> wrote: > We have a service where we have a front end using Wordpress/Magento/custom > PHP code and a distributed backend using various other servers and services > from note.js, magento, mysql, c#, java, ms sqlserver, Apache, etc. > > > > The idea is we want to have multiple UIs spread across different > geographies (different USA states, different countries, etc.) either user > selectable or load-balancer assigned > > > > How can we have it set up such that someone’s login/authentication is > valid across the different UIs (and can switch amongst them) without > re-logging in when they switch (after having logged in already to any of > the nodes). I don’t want to have to constantly authenticate against some > shared backend for every request either, so I imagine some kind of token > must be used? Like how does OpenID work? Or these “Login with Facebook” or > “Google ID”? Amazon AWS/EC2 are good examples for their UI console to > manage computes as it has different regions at the top you switch to simply > by the dropdown and really nothing else changes except some AJAX reload of > your statistics, even the URL is mostly the same except another parameter. > > > > We’re not necessarily married to Wordpress and in fact we’re trying to > phase it out eventually and only use Magento. > > Custom code is also an option – at least if there is a good example base > or API we can maybe hack it in. > > We’re open to many technologies, but obviously would prefer to use one we > already have (PHP ideally) > > > > Pointers? Thoughts? References? Whitepapers? Plugins? FOSS projects? > Third party authentication (which is basically what you're wanting) works through token passing. The sequence goes something like this: 1) User clicks a button on your site to log in using a third party ( http://www.yoursite.com/login). 2) Server connects to the third party to get a time-limited "authentication" token that will allow authentication and redirects the user to that third party (http://www.sharedloginserver.com/login?authtoken=x ). 3) Third party site checks the token is valid and if so presents the login form. 4) User enters their credentials and clicks the login button (POST to http://www,sharedloginserver.com/login?authtoken=x). 5) Third party site validates the token and the user's details, and if all is correct will generate a "logged in" token, also usually time-limited and redirects the user back to the original site ( http://www.yoursite.com/login/success?authtoken=x&loggedintoken=y). 6) Your site contacts the shared login server to verify that the authtoken and loggedintoken are both valid, and if so logs the user in locally. 7) From this point on there is no need to contact the third party's server unless you need to re-authenticate the user. In your scenario you would want to set an encrypted cookie on www.sharedloginserver.com that provides it with information about the login against yoursite.com so that it can decide whether it needs to show a login form for login to www.anothersite.com or simply create another loggedintoken for it. Hope that makes some sort of sense. As far as existing code to do this I've never come across anything, but it may well exist in implementations of openid. It's fairly straightforward to build. However, having read back what you wrote that doesn't actually appear to apply here. Will your different UIs be on different domains? If so, why? You could easily have uk.yoursite.com, us.yoursite.com, au.yoursite.com, etc, which would only require the user to authenticate on www.yoursite.com so long as it doesn't use "standard" sessions to track the logged in user. I'd recommend something similar to my sessionless sessions ( http://3ft9.com/sessionless-sessions-2/) and make sure your cookies are set on .yoursite.com and not x.yoursite.com. Those cookies are then accessible from any subdomain. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
