How to set up a single sign on

you may be able to share the necessary tables using your settings.php file. see: http://www.slideshare.net/jvandyk/multisite-van-dyk-walkah-presentation

That will give you shared usernames/passwords, but not true SSO.

OpenID would be the other way to accomplish this request, which is beyond the scope of DA.

References to the old Shared Sign On have been removed from the Domain Access documentation, thanks.

Moving to the sso issue queue.

Since the cookies cannot be shared, you have to login twice, unless the SSO module can help you. But then you need two Drupal installations, AFAIK.

I don't know, since I haven't looked at this new SSO module.

$cookie_domain can be set in settings.php as well per the slideshow.

I suppose I am misunderstanding what "true" SSO is. Per the slideshow, when logged in one 1site, you remain logged in all the shared site when one moves to the shared site.

- 1 settings.php for the default domain
- 1 settings.php for all the others subdomain or domains

Not to my knowledge, no. Instead of the default domain, you might have that as the 'account domain' where users login with SSO. Then all content, etc, would go into the settings.php and the sites controlled by DA. This is because DA needs all your content in a single {node} and {node_access} table set.

"True" SSO, here, I think, means "login once and have that valid on all domains in a defined group." The problem is that (for very good security reasons) the RFC for cookies doesn't allow sharing cookies across domains. You can only share on a canonical domain and its subdomains.

"True" SSO, here, I think, means "login once and have that valid on all domains in a defined group." The problem is that (for very good security reasons) the RFC for cookies doesn't allow sharing cookies across domains. You can only share on a canonical domain and its subdomains.

gotcha. That makes perfect sense. Thanks for explaining.

On point #1, this is not a feature of DA. 'Strict' domain assignment is a node access permission issue, not a login issue.

LaurentB,

Good work so far!

Can you give us some clues on the contents of the two settings.php files?
Do they both have:
$cookie_domain = 'controllerdomain.com';

For Domain Access to carry on working, do they both include the DA line:
include './sites/all/modules/domain/settings.inc';

What about the all important $db_prefix array?

Is the main idea here that to replace the now defunct SSO/DA combo exactly, you need to configure proper Drupal multi-sites with an extra "controller" domain to look after the user registrations and cookies and have all the original DA domains as "clients"? Or can the controller domain be one of the original DA domains?

Regards
Dunx

SSO overrides Login Restrict policy

Yes. It would, since the cookie is set by the SSO site, and the restrictions are managed by the other site(s). You would likely have to do some odd $_SESSION handling to manage the login restrictions.

I am working with latest D5 version (5.20), version 5.x-1.0-rc1 of SSO and version 5.x-1.11 of DA.
I used, like almost everyone in this posting, the "Shared sign on" module (singlesignon) and try to change to sso.

I have the following problem: when I, after login at the master site, go to a DA domain, I am not logged in anymore, not in the DA-domain and not in master. The same exists when I login at a DA-domain and switch to another DA-domain or master.
My setup is:
- master: login.example.com
DA 0: example.com
DA 1: da1.example.com
DA 2: da2.example.com
- shared codebase
- 2 databases, one for master (mysite_login) and one for DA-domains (mysite_drupal)
- equal $cookie_domain = 'example.com';
- $db_prefix = array(
'default' => '',
'users' => 'mysite_login.',
'sessions' => 'mysite_login.',
'authmap' => 'mysite_login.',
'role' => 'mysite_login.',
'users_roles' => 'mysite_login.',
);
- users, role and users_roles are copied from mysite_drupal to mysite_login.
- sessions and authmap left empty at the start.

I watched several times to http://www.slideshare.net/jvandyk/multisite-van-dyk-walkah-presentation, but didn't find the clue what I am doing wrong.
Who can help me out?

Why do you have periods at the end of the prefix strings? Are the database tables named mysite_login.tablename?

I copied the syntax from the readme.txt:
$db_prefix = array(
'default' => '',
'authmap' => 'controller_database.',
'sessions' => 'controller_database.',
'users' => 'controller_database.',
);
From the Drupal-documentation I found a period means the former is the name of another database. By this the authmap, users and sessions tables have a shared use from the controller_database and not used from the da-database.

I found out the sso clientsettings in the DA-sites where not set (anymore), maybe due to early an "access denied". I added these this morning. Now I get only the "access denied" message on every DA node with an URI something like:
http://da1.example.com/singlesignon/claim?nonce=1234567890abcdef&origin=...

Yes, the period means database. I will try to make a video on how to set up SSO next week.

Right, typical Drupal multisite uses underscores '_', so I was making sure it wasn't a typo or a misconfiguration.

I got it working!
I found the reason why I got "access denied" errors. And I got SSO working toghether with DA.
My solution: in the settings.php of the 'master/login' site I defined the $cookie_domain = 'login.example.com';
In the DA-sites the $cookie_domain = 'example.com'; (so only the base domain of 'login.example.com').
Now I understand the sentence in #9: "You can only share on a canonical domain and its subdomains". Since English is not my first language and my dictionary doesn't have a translation for the word "canonical" that explains the sentence, I didn't got the meaning of it. So, the domains of both websites (login and DA) in the $cookie_domain MUST be different. I hope 'meba' will put it in the documentation.

I hope other DA + SSO users can benefit from my tests.

Inserted into README: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/sso/README....

Thanks!

I will close this issue now.

I have multisiting based on table prefixes for common and shared tables in settings.php
Can I use this module?
Does this module works only with Domain Access module?

I'm still very confused.

I have a Domain Access setup, which was using the old SSO method. I've uninstalled that old module. There are three domains:

www.domain1.com
www.domain2.com
www.domain3.com

I want to move to the new SSO method still using DA and don't mind using www.domain1.com as the "controller", but currently I have one database and one codebase.

Do I have to re-install everything from scratch to create a multisite setup or am I missing something simple in all the helpful stuff here and various link about multisites somewhere?

Cheers
Dunx

I'm in the same boat here and I've already spent to many hours trying to get this to work. Yes, I got the default setup up and running on a localhost test multisite but I've been unable to get this working on my real sites.

I've got a basic multisite setup using the old shared signon and I'm not using DA. I like the idea of moving to the new sso as it at least will make updating the controller website simple.

www.example.com
sub1.example.com

Each has it's own Drupal database and a 3rd shared database was setup for users (via the old shared signon setup) with the following in www and sub1 settings.php...

$db_prefix = array(
'default' => '',
'authmap' => 'shared_database.',
'role' => 'shared_database.',
'sessions' => 'shared_database.',
'users' => 'shared_database.',
);

That setup works perfectly under the old shared signon.

With the new sso I basically designate www.example.com as the controller making sure I have the above tables in the controller database. I manage to get the controller site working with the module with no issues. But every time I attempt to get sub1.example.com (the client) configured it redirects with a white screen and just doesn't work. I've altered settings.php $db_prefix to point to the controller database and followed the readme multiple times. I have $cookie_domain = 'example.com'; Either I'm missing something simple or I'm misunderstanding the readme.txt and upgrade.txt somewhere.

By the other posts in the issue que, I'm not the only one struggling with this and I don't really want to redo my sites from a default setup to get this working.

@meba - If you do get a video tutorial together, I'm hoping you can give some insight on the upgrade path for those of us trying to move from the old to the new.

To avoid confusion with the "default" directory under /sites, I would suggest people read "default domain" in post#5 as "controller domain" and "other subdomains or domains" as "client domains".

To complete the paper trail, I now have SSO working on 3 FQDs fine.

The trouble was some failed attempts left records in the variable table meaning it was never going to work until I sorted those out. Only took a month!

http://drupal.org/node/606422#comment-2206222

Also problems could be because of record for user with uid=0 is missing at users table.
See http://drupal.org/node/596068#comment-2208596

Im still not sure how to set this up.

Im working in localhost, and I currently have 2 sites, both with entirely different domains.

http://site1.com > The main site
http://site2.com

Same DB for both sites, same install for both. No prefixes

Because they are using the same files and DB, I cant have the controller part of SSO and the client part of SSO active at once...It throws an error.

So how do I go about having 2 seperate settings.php. Where should the client (site2) settings.php be located?

sites/site2/settings.php or sites/default/files/domain-2/settings.php

What should the cookie_domain be for both site1 (the controller) and site2 (the client)

Do I include these lines:

include './sites/all/modules/domain/settings.inc';
$conf['session_inc'] = 'sites/all/modules/sso/session.singlesignon.inc';

in both settings.php, site1 or site2?

In some DA / multi-domain sites you don't have to use sso. See this issue: http://drupal.org/node/631784.

Actually got this working now, using SSO and Domain Access across 8 sites atm. All different top level domains. Works great :) Coming up against some problems now though with duplicate URL aliases and duplicate forums across sites, but thats a DA issue. Tried prefixing, but now it seems SSO doesnt like prefixes, so Ive got to investigate that as well. Ultimately, Im starting to think that unless your really going to share significant amounts of content across sites...might be best to leave DA out of a typical multisite setup, fabulous though it is.

Ultimately, I'm starting to think that unless your really going to share significant amounts of content across sites...might be best to leave DA out of a typical multisite setup, fabulous though it is.

I would agree with that, and I'm the DA maintainer.

bookmarking

Just want to share something that helped.

Log in and out from the controller site and the cookies don't get all whacked out. Also, erase all cookies if you are getting a weird URL and a blank screen...

and dont set the cookie_domains for controller or slave

also following the step by step examples helped and also deleting the variable tables that contain sso entries.. they get re-created if you turn the sso client module on and off.

For me, if I would log out on one of the slave sites it would jack all the cookies up. Now trying to make sure all my logout links point to controller.com/logout -- hopefully don't run into any more problems with this module. I had to spend like 30 mins on each problem in these forums.

Hi Netbuddy,

I'm having the same problem, 1 codebase and 1 database with multiple domains with domain module.
How did you manage to get SSO working?

Thanks!