5

Does Craft support any form of single sign-on across separate installations? I don't think there is a native way of doing this, but does anyone have any idea how I would approach this?

What I need is for users of Site A and Site B to be kept in sync in some way so they can use the same username and password to sign-on to both sites. Bonus points if they can automatically signed into to Site B if they are already signed into Site A.

Note that using some form of social sign-on (e.g. Facebook, Twitter, etc.) is not an option for this client.

  • 1
    I don't think there is something like this available yet unfortunately, I'd love it too. Maybe add a FQ here? feedback.craftcms.com/forums/285221-feature-requests – Sean O'Grady May 19 '16 at 19:04
  • Nice to know I'm not the only one who would like this :-) However, I'm not sure something as edge-case as this should really be in core, so I'm not convinced about making a feature request for it. – Steve Rowling May 20 '16 at 8:23
5

No, Craft doesn't have any native notion of SSO.

(You can technically run multiple sites from the same Craft instance. If you had sites sharing the same server, you could run them from the same Craft installation, thereby enacting a de facto shared user roster by virtue of the shared database. If such sites also shared a root domain, you could gracefully maintain a persistent session between them. However, for the purpose of this answer, I'm assuming such a circumstance does not apply.)

Nonetheless, you could enable a limited/simple SSO-ish setup using a custom plugin...

 

What I need is for users of Site A and Site B to be kept in sync in some way so they can use the same username and password to sign-on to both sites.

Trying to keep user records perfectly in sync across multiple sites would not be simple. However, you probably don't need records to be perfectly in sync. Rather, you only need one site to serve as the authoritative source of truth, and the other site(s) only needs to keep track of a unique reference (i.e. a username, or even better, a UUID.):

Master/Slave setup

  • Let's say Site A is the master, Site B is the slave.
  • All user registration takes place on the Master site. (User registration is not allowed on the Slave site.)
  • Login on Master uses Craft's native users/login controller method.
  • Login on Slave uses a custom controller method that submits a username/password combo to Master, receives back a response, and logs in the user if Master says their credentials are valid. (If a record for this user doesn't already exist on Slave, one is created 'just-in-time' and logged in.)

CaveatIf profile values are allowed to change, then we do need to create a mechanism for the Master site to notify its Slave sites of any changes. (We don't care about the slave sites' copy of the user's password, because only the Master site ever needs to do any authentication. We might care about keeping username/email/profile values in sync, because the Slave sites may want to display User info in templates or something.) This can be accomplished using a custom controller action (authenticated by some secret key, perhaps) by which the Master site triggers the Slave site's users/saveUser method with new/updated content.

 

Bonus points if they can automatically signed into to Site B if they are already signed into Site A.

If the sites share a root domain...

Craft decides that a user is "still signed in" by matching a known session ID (stored in the craft_sessions table) to the cookie sent by the user's client.

If your sites share a root domain (e.g. mysite.com and other.mysite.com) then they will be able to share cookies. (You'd use the defaultCookieDomain setting to cause both sites to store cookies under the root domain.) That means the Slave site can read the user's CraftSessionId cookie, validate it with the Master site, and log the user in as appropriate.

If the sites don't share a root domain...

Alas, due to cross-domain restrictions, sites not sharing a root domain are not allowed to receive/read each other's cookies. Automatic multi-site login might still be possible, but it'd involve bouncing the user back and forth in a series of [hopefully imperceptible] redirects between Master and Slave that would accomplish something basically single-sign-on-y (Kerberos, anyone?). It'd be convoluted and weird and I don't have brainpower to think about it anymore tonight. :-P

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.