I'm trying to set up SSO with my Domain access sites - some are sub domains and some are different domains. In the SSO instructions under both the Controller and Client sections it says,

If you are using SSO with Domain Access and controller is subdomain of client sites (like login.example.com), make sure to edit $cookie_domain in settings.php to a proper domain name.

1. What does "and controller is subdomain of client sites" mean?
2. Do I enable the controller or client module (it only let's me choose one)?
3. What is the proper cookie domain if some are sub domains and some are different domains?
4. Do you still need "$conf['session_inc'] = 'sites/all/modules/sso/session.singlesignon.inc';" in settings.php?

Thanks.

Comments

aaron1234nz’s picture

subscribing

vasike’s picture

subscribe

jratrw’s picture

I would also find documentation for this helpful.

I have three sites with different domains tied together with domain access. The sites are mostly identical and so most of the content is shared, and all of the modules are shared. Since the modules are shared I cannot enable a controller or client on one site without it being enabled on the other two. This causes conflicts since the controller and client cannot both be enabled.

meba’s picture

jratrw: you need to create a separate controller site with a separate database

bleen’s picture

subscribe

xjm’s picture

Tracking.

asak’s picture

Subscribing.. for some bizarre reason i thought that getting DA and SSO playing nicely together was gonna be pretty easy... but... ;/

;)

bleen’s picture

I just went through this yesterday and I think I finally got it... I posted my step-by-step here: http://www.bleen.net/blog/domain-access-sso

kruser’s picture

Nice work, I can't wait to give it a try.

mrgoltra’s picture

will this work with more than 100 domains?

bleen’s picture

@mrgoltra: I havent tried this on a site with more than 4 domains, but assuming your DB can handle the load I dont see why there should be any practical limit

mrgoltra’s picture

Thank you bleen18. I will give it a try and see what happens?

Exploratus’s picture

This worked beautifully. Brought tears to my eyes....

mrgoltra’s picture

has anyone tried domain table prefixing?

bleen’s picture

yes ... do you have a specific question?

mrgoltra’s picture

Thanks bleen18,

I am just wondering which tables need to be copied, need to be ignore, and need to be created. I have been playing around but haven't had any luck.

Thank you,

Mark

bleen’s picture

the only tbls that need to be copied are users, sesssions, & authmap ... this way all the client sites will be using the same users

Albrecht Marignoni’s picture

In other word I use three databases for one site with a subsite car.com/volkswagen ?
Is there an other module which can give me a better way to connect the user tables of two databases?

kruser’s picture

so I finally had a new project to try this out on, here's some of my results.

1. my existing site (pre da) was in /default, when copying the sessions table from the existing site to the login site, the login db had a different structure for the sessions table which included a domain column. So I altered the table manually in the existing db and re-exported.

2. Once I configured SSO controller/client, I could login to both sites (login and existing) using the same username, so SSO was working. I had to empty the sessions table though because I was getting a lot of errors about missing session ids.

3. I installed DA on the existing site and added a new site, but when I try to access the new site, no luck with SSO login, I just get an access denied page...

http://newsite.mysite.com/singlesignon/claim?nonce=78b56f215cc22e9a&origin=http://newsite.mysite.com/&request_id=19a2b530b1c

I can't even access it logged out, same error.

Any idea what I may be missing?

kruser’s picture

Update: The good news, I got the Access Denied to go away and SSO to work for the DA site. The bad news is that it was caused by Table Prefixing in DA - once I removed all of my table prefixes (I had blocks and menus set to 'create'), then it magically worked.

Any idea what the connection may be between sso and table prefixes - and how to get them to work together?

bleen’s picture

@2440media2 ... it sounds like you are having conflicts with the $db_prefix variable in your settings.php ... are you defining it twice?

kruser’s picture

No, I just have one array of prefixes for default, authmap, sessions, users, BUT that did lead me to discover something interesting in the readme of domain prefix....

This module replaces the default $db_prefix routine documented inside settings.php.

IT IS ADVISED THAT YOU DO NOT USE THE $db_prefix VARIABLE IF YOU ARE USING THIS MODULE.

If you must prefix all tables, do not set $db_prefix as an array.  This module should still work if $db_prefix = 'string_'.

So this is kind of depressing. I guess SSO and Domain_prefix can't work together?

davemybes’s picture

I am following bleen's instructions, but as soon as I log back into the master site (whether or not I add the sso $conf to settings.php), I get the following errors:

Warning: Unknown column 's.domain' in 'where clause' query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = '4bae79834d8f1d4ff106d8ebdfe3b819' AND s.domain = 'login.mysite' in /path/to/site/includes/database.mysqli.inc on line 128

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /path/to/site/includes/database.mysqli.inc:128) in /path/to/site/includes/bootstrap.inc on line 1037

Warning: Cannot modify header information - headers already sent by (output started at /path/to/site/includes/database.mysqli.inc:128) in /path/to/site/includes/bootstrap.inc on line 636

Warning: Cannot modify header information - headers already sent by (output started at /path/to/site/includes/database.mysqli.inc:128) in /path/to/site/includes/bootstrap.inc on line 637

Warning: Cannot modify header information - headers already sent by (output started at /path/to/site/includes/database.mysqli.inc:128) in /path/to/site/includes/bootstrap.inc on line 638

Warning: Cannot modify header information - headers already sent by (output started at /path/to/site/includes/database.mysqli.inc:128) in /path/to/site/includes/bootstrap.inc on line 639

Looks like the Domain Access module is sticking its nose in there somehow. I have no idea why or how. On one attempt I didn't do anything other than create the master site, log out and the login again. Any ideas would be appreciated. I also tried different domain names - first was a subdomain, then a completely different name. Still the same error.

bleen’s picture

There were several times when I got that ... as I recall, i just had to disable and then re-enable the SSO controller module on the master site

I may have had to "uninstall" it before reenabling - I cant recall

davemybes’s picture

Thanks for replying. Your suggestion helped me figure it out. Here is my process for anyone who is interested:

  • setup the new site and login with the same user 1 account details
  • activate the sso module and while logged in add the $conf variable to settings.php
  • logout if you don't get logged out and import the user, authmap, sessions tables like in bleen18's instructions
  • log in again - it should work OK. If you can't login, remove the $conf line, log in, disable then uninstall the controller. Re-enable, then add the $conf line again. Logout and login again, and it should work now.
  • get the private key from the sso settings page
  • on the domain access sites, login and enable the client module
  • add the $conf line to settings.php
  • add the $db_prefix array, just like in bleen18' instructions (with the trailing dot)
  • you will probably get logged out, so log in again
  • enter the private key in the sso settings page
  • logout and then login again
  • check the other sites in your group and you should be logged into them too

This is actually pretty much the step-by-step that is in the README.txt of SSO.

By the way, if you get the error I mentioned above, remove the $conf line from settings.php and you should be able to login again.

hymalaya85’s picture

I have a bug about single sign-on. I installed single sign-on Module completely.
i have two test site : http://localhost:3030/drupalssoclient1 (controller) and http://localhost:3030/drupalssoclient2 (client) . I logined into the site 1 after i went to the site 2 but Site 2 did not login into.
I think it don't save session

joshmiller’s picture

re: #22

I have opened up an issue regarding our mutual issue:

#947298: SSO, Pathauto, and Domain_prefix are not compatible

joshmiller’s picture

Re: #22 & #27...

#632950: DA, SSO and URL alias table prefixing this issue was found and fixed in the 6.x-Dev version.