Access Denied - (with CDN?)

I got the same error.
I think this happens because path 'singlesignon/claim' is not defined by hook_menu in client-module

[Delete by dunx as not related to this issue]

It happened to me too with a fresh install. Can't access my second site at all without editing the settings.php to no longer include the $conf line. :( I have two sites sharing the same database with different table prefixes. Any other program or workaround I can use for a single sign on?

Thanks

It's an installation error. First make sure that you EXACTLY follow README.txt. If you alter the steps somehow and get a problem, go back to README. then report when exactly you got problem.

Also, if you have domain.com, client1.com and client2.com, you don't have to change $cookie_domain at all, so this shouldn't be a problem.

Ad VladSavitsky: you are wrong. It's not because the client is not defined in hook_menu, it's because when the client doesn't match controllers nonce and request id, it returns 403.

To the problem - are you sure you have configured sharing users, authmap and sessions tables? Is there a column "nonce" in sessions table (shared one)?

Promes: without more information, I can't determine if there is any bug so it's unlikely there will be a new version possibly fixing your problem. I have never encountered something like that and I guess the problem lies in the setup. If you can, try to post as much info as you can.

The module is working like a charm on my local development environment, but when I deploy it on the staging server, the single sign on seems to be working, but when I do things like set a Type filter under admin/content/node nothing applies...

My setup is as follows:

http://controller.domain.dev
http://client1.domain.dev

I have turned the debug flag on my local and the staging, while also stepping through with the debugger, the staging server experiencing the problems keeps redoing the session propagation handshake on every request and I can't figure out why...

I have played with the settings.php $cookie_domain setting it to domain.dev, controller.domain.dev, and client1.domain.dev for each site to no avail...

--------------------------------------------------------------------------------
2009-10-29T10:39:30+13:00
Status: Beginning session propagation handshake
Request ID: 4841a606973b7c3e
Request: http://client1.domain.dev/admin/build/modules
Referrer: http://client1.domain.dev/
User agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090217 Ubuntu/9.04 (jaunty) Firefox/3.0.14
Remote Address: 122.58.134.236
Cookies: Array
(
[SESScbf58652f956a9d293206e5445c5627f] => d3fbe85c99e5216e48892063b68dc2cb
[has_js] => 1
)

Old SID:
Old Global SID:
New SID: 38dcb4c78b9c4c414e87417f61b576ee
New Global SID:
Domain:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
2009-10-29T10:39:30+13:00
Status: Session associated
Request ID: 4841a606973b7c3e
Nonce: 5d6fcf5c7455435b
Request: http://controller.domain.dev/singlesignon/associate?origin=http%3A%2F%2F...
Referrer: http://client1.domain.dev/
User agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090217 Ubuntu/9.04 (jaunty) Firefox/3.0.14
Remote Address: 122.58.134.236
Cookies: Array
(
[SESSd804e4ee9f7d066240cec03cdcdc6ef7] => 1
[has_js] => 1
)

Old SID:
Old Global SID:
New SID: ae42051f8cf7c73651b6e96162c576b6
New Global SID:
Domain:
--------------------------------------------------------------------------------

I think it has something to do with the global sid not being stored on the $user object, or being saved properly to the sessions table... I'm having one helluva time debugging this

Does sessions table contain column "nonce"?

No, I'm still getting this issue too. I've followed the upgrade and install instructions just fine and the setup was working fine as a multisite. I could log in separately to both the controller and the client sites fine.

Problems started I got to "5) At this point, you will need to log in again to you client site as administrator" in the README.txt, so I haven't got as far as entering the controller SSO details in the client SSO screen.

When I try to log in, I get redirected to http://controller.com/singlesignon/associate?origin=http%3A%2F%2Fclient....

This is all on a local server using WAMP.

I have no cookie_domain entries in either settings.php. The $conf['session_inc']=... entry is in both.

I cleared first the controller session table and then the client session table, just in case, but still no joy. Both have the nonce column, but when I log in on my controller domain and attempt to log in to by client this column remains empty in the shared controller session table:

uid 	sid 	hostname 	timestamp 	cache 	session 	domain 	global_sid 	nonce
1 	lrr9i3sk0rfn2n5drq4tklbda5 	127.0.0.1 	1256824142 0 	<empty>  	               controller.com 	<empty>  	<empty> 
0 	35qivni2jkb9ba8cce3pp9ffq7 	127.0.0.1 	1256823586 0 	request_id|s:16:"ac0d4715f5c70bdc"; 	client.com 	<empty>  	<empty>

Does anybody actually have this working on FQDs rather than sub-domains as with meba's demo site?

You said that you cleared controller session table and client session table. But these tables should in fact be ONE TABLE. Isn't that your error? That you are not sharing the tables?

Both tables are accessible via phpMyAdmin though, one under controllerDB and one under the even clientDB. Nowhere in multisites or sso does it to say to delete any tables! Only one of them is used; the contollerBD.session through db_prefix'ing. Like I said, multisites was working fine and session records were being created in contollerBD.session only.

I did say both had the nonce column and that's because of another problem of my creation when I enabled sso controller on the client site. I've now deleted domain, global_sid and nonce columns from clientDB.session for clarity.

I've spent all day on this trying things in different orders. No luck yet. To even get back my client site I had to delete all single% records from the clientDB.system table.

I have a funny feeling that a previous attempt from days ago has left the controller's private key stored somewhere for the client, so as soon as I activate the client module and before I get the chance to configure the controller's private key under the controller, the private key is already wrong and access is denied. I'm just looking for that now...

DELETE FROM variable WHERE name LIKE 'singlesignon%'; UPDATE system SET status = 0 WHERE name = 'singlesignon_client';

will always help you disable it

:) That seemed to do the trick, although I almost missed it as the above table name should have been "variable", not "variables".

So, here's a walk through for the solution to my issue.

1. Get multisites working.
2. On both DBs... DELETE FROM variable WHERE name LIKE 'singlesignon%';
3. On both DBs... UPDATE system SET status = 0 WHERE name = 'singlesignon_client';
4. Add the db_prefix array to both settings.php
5. Log on to controller and enable sso controller.
6. Add the $conf['session_inc'] line to controller settings.php
7. Go to the sso controller config page to see the domain and private key.
8. Log on to the client and enable the sso client.
9. Add the $conf['session_inc'] line to client settings.php
10. Go to the sso client config page and paste in the controller's domain and private key.
11. No need for any $cookie_domain values in settings.php

And then I have SSO working on two separate fully qualified domains.

Right, I'll move on to getting Domain Access working now!

I am glad it wasn't SSO fault and it was installation error indeed :-)

Domain Access should work seamleslly, since you already have SSO working. (Run it on client site only, not on controller :)

Others: I will close this issue now. If you still have problems (like mdance), please open your separate issues.

I have fixed my own problem too.
Anonymous user has no record at table users and sessions didn't craeted for him.
See http://drupal.org/node/596068#comment-2208596 for details.

Quite a few people have had issues setting this up simply. Mine was because I made one mistake weeks ago. It's taken ages to sort out what had caused the initial problem, which was something that sso_client did when I installed it incorrectly, but which then following the instructions provided would never have resolved.

Perhaps my "variable" record issue and VladSavitsky's uid 0 issue could be added to the faq.txt at the very least.

I am experiencing this issue trying to upgrade from the Shared Sign On module which worked without a problem. I have a multi-site and multi-database configuration with a shared codebase ala:

example.com (controller site):
$db_prefix = '';
$cookie_domain = "example.com";

a.example.com, b.example.com (client sites):
$db_prefix = array(
'default' => '',
'users' => $USERDB.'.',
'sessions' => $USERDB.'.',
'role' => $USERDB.'.',
'authmap' => $USERDB.'.',
'sequences' => $USERDB.'.',
'profile_fields' => $USERDB.'.',
'profile_values' => $USERDB.'.',
);
$cookie_domain = "example.com";

I have followed the README instructions and the suggestions in this thread including:
1. Removed the Shared Sign On module from all databases
2. Followed the instructions in #15 above.
3. In the controller database, made sure that there is a uid 0 in the users table and a "nonce" column in the sessions table.

I have no issues with the controller site. However, as soon as I add the controller's domain and private key to the client sites, I am redirected to a login screen with the URL of the form:

http://a.example.com/singlesignon/claim?nonce=d24e2b...&origin=http%3A%2... 2F&request_id=268985...auth=37...

and I cannot login to the client site as any user including admin.

As soon as I disable the Shared Sign On module on the client site and clear the cache, I can login the client site again.

Any suggestions? In particular, it would be helpful if dunx could explain in more detail how he fixed his problem.

I got the client sites working with the Single Sign On module by commenting out the cookie domain in the client site settings.php files.

This needs to be documented in the README. For multisite installations:
- $cookie_domain in the controller site should be set to the controller FQD
- $cookie_domain in the client sites should not be set.

I have been having this same issue but none of the solutions mentioned above seem to help. I've tried deleting all the singlesign* variables; I've never had $cookie_domain set on controller or client; My uid=0 user is safe and sound in the users tbl.

MY SETUP

login.site.com = controller
site1.com = client1 \
site2.com = client2 |- using Domain Access
site3.com = client3 /

note: the client sites all have a CDN (Akamai) in front of them

MY PROBLEM

I have SSO installed and working great for this site on my dev environment and staging environment but once I moved everything up to production I get Access Denied on all pages on my client sites (anon users only - anyone who was already logged in before turning on SSO (and by definition bypassing CDN) has no problems). I believe that my problem is related to the CDN, but I cannot understand where the problem might be hidden based on this setup. It seems to me that even if Akamia caches an anon user's session that it would be perfectly fine for all other anon users to use that same session. Any thoughts or ideas would be welcome.

I'm having a similar issue as #20... http://drupal.org/node/680348#comment-2998508

meba,

may i know did you create video on how to setup SSO? i also facing problem that mentioned above and follow every step on README.txt as well as the advise above but still failed.

I encountered the same trouble like you and did just resolve it.

Thanks to Dunx for his synthetic resume, and i will add this :

1. Assure there is only one "$db_prefix = ...." in each settings.php file.
In my trouble, i didn't pay attention that my $db_prefix array was overwritten by another declaration farther.

Put in your settings.php controller :
$db_prefix = 'controller_';

Put in your settings.php client :
$db_prefix = array(
'default' => 'client_',
'authmap' => 'controller_',
'sessions' => 'controller_',
'users' => 'controller_'
);
Pay attention to not put a coma (,) after the last declaration in the array.

2. Make sure you put "$conf['session_inc'] = 'sites/all/modules/sso/session.singlesignon.inc';" in the both settings.php files

3. Assure that client sites and controller site are well separated when you enable sso modules

I hope to help you.