Single signon question
Dear all, Probably there are a lot of questions here about Drupal SSO implementation, but my searches did not help me a lot, so sorry in advance. We are running a network of D6 sites (multisite), each site have a different db, with different users, not sharing any tables. Some users, have signed themselves to more sites of the network, creating another complexity layer (same users, different uid). The SSO must permits us to: 1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users. Openid could be a solution ? Any kind of tips is really appreciated. Best wishes. Paolo Mainardi CTO Twinbit http://www.paolomainardi.com
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped. 2- New users will be registered on the controller site users table, that will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Openid could be a solution ?
It wouldn't. SSO also permits the sharing of the "sessions" table, which is essential for the simultaneous login to work. That wouldn't happen with Openid that would login the user just on the one site he's logging in to. HTH Roberto
Not sure I agree with this statement. SSO does not demand the sharing of the sessions table, but there are some things you will want to consider how you will share across the sites.... Such assail address and profile pictures. Anyway, this is starting to sound like a support question more than a development question... you might get better answers about how people use the products on the support forums and lists. The CAS module provides some minimal functionality for saying, if you're logged into site A then you are logged into site B as well. Sent from my iPad On Jan 4, 2011, at 9:51 PM, "Roberto Gorjão" <roberto@asenseofdesign.com> wrote:
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped.
2- New users will be registered on the controller site users table, that will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Openid could be a solution ?
It wouldn't. SSO also permits the sharing of the "sessions" table, which is essential for the simultaneous login to work. That wouldn't happen with Openid that would login the user just on the one site he's logging in to.
HTH
Roberto
Bakery is what Drupal.org and groups.drupal.org uses for SSO. However, be warned that it doesn't play nice with the LDAP modules and if your user's clock is off by more than you session expiration amount they will only be able to log in with firefox. On Wed, Jan 5, 2011 at 10:00 AM, Dave Metzler <metzler.dl@gmail.com> wrote:
Not sure I agree with this statement. SSO does not demand the sharing of the sessions table, but there are some things you will want to consider how you will share across the sites.... Such assail address and profile pictures. Anyway, this is starting to sound like a support question more than a development question... you might get better answers about how people use the products on the support forums and lists.
The CAS module provides some minimal functionality for saying, if you're logged into site A then you are logged into site B as well.
Sent from my iPad
On Jan 4, 2011, at 9:51 PM, "Roberto Gorjão" <roberto@asenseofdesign.com> wrote:
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped.
2- New users will be registered on the controller site users table, that will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Openid could be a solution ?
It wouldn't. SSO also permits the sharing of the "sessions" table, which is essential for the simultaneous login to work. That wouldn't happen with Openid that would login the user just on the one site he's logging in to.
HTH
Roberto
Can you expand on the Bakery+LDAP issues? And, maybe file it as an issue? ;) -- Greg Knaddison | 720-310-5623 | http://growingventuresolutions.com Mastering Drupal | http://www.masteringdrupal.com On Wed, Jan 5, 2011 at 9:20 AM, antgiant <antgiant+drupalDevel@gmail.com> wrote:
Bakery is what Drupal.org and groups.drupal.org uses for SSO. However, be warned that it doesn't play nice with the LDAP modules and if your user's clock is off by more than you session expiration amount they will only be able to log in with firefox.
On Wed, Jan 5, 2011 at 10:00 AM, Dave Metzler <metzler.dl@gmail.com> wrote:
Not sure I agree with this statement. SSO does not demand the sharing of the sessions table, but there are some things you will want to consider how you will share across the sites.... Such assail address and profile pictures. Anyway, this is starting to sound like a support question more than a development question... you might get better answers about how people use the products on the support forums and lists.
The CAS module provides some minimal functionality for saying, if you're logged into site A then you are logged into site B as well.
Sent from my iPad
On Jan 4, 2011, at 9:51 PM, "Roberto Gorjão" <roberto@asenseofdesign.com> wrote:
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped.
2- New users will be registered on the controller site users table, that will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Openid could be a solution ?
It wouldn't. SSO also permits the sharing of the "sessions" table, which is essential for the simultaneous login to work. That wouldn't happen with Openid that would login the user just on the one site he's logging in to.
HTH
Roberto
Sure, although technically it is the LDAP module's problem (as well as any other module that follows its pattern). If the LDAP modules are setup to grant roles based on LDAP properties the LDAP module deletes all roles and then recreates then. There are two problems with this approach, first it failure to access LDAP is detected after deleting the roles and thus occasionally leaves users without any roles until next login. Second, and much more critical, the roles are granted only when the user logs in via the login page. (I assume they are grabbing the wrong hook, but haven't had time to verify.) This means that programmatic logins like those done by bakery leave users with no roles. I know for sure this is true on initial login (aka when the LDAP module creates the account) however, I'm less sure about subsequent logins. (I think on subsequent programmatic logins roles are simply not modified.) So essentially login works but roles are missing. Acquia tracked down the delete recreate bug for us nearly a year ago, I'm not sure if they filed an issue or not. Our LDAP got more reliable so we stopped having users without groups. The second issue impacted us when we tried to turn on bakery as well as when we tried to turn on the EZ-Proxy module. As a result we have had to disable both of those modules. Just a side note the bakery instant timeout bug is because bakery sets the cookie timeout relative to the server's clock but the browser interprets according to the local clock (except I believe for firefox). We worked around that by using a custom block with some php and javascript to warn users when their clock was far enough out of sync to cause problems. I can provide that to anyone who is interested. On Wed, Jan 5, 2011 at 11:49 AM, Greg Knaddison < Greg@growingventuresolutions.com> wrote:
Can you expand on the Bakery+LDAP issues?
And, maybe file it as an issue? ;)
-- Greg Knaddison | 720-310-5623 | http://growingventuresolutions.com Mastering Drupal | http://www.masteringdrupal.com
On Wed, Jan 5, 2011 at 9:20 AM, antgiant <antgiant+drupalDevel@gmail.com<antgiant%2BdrupalDevel@gmail.com>> wrote:
Bakery is what Drupal.org and groups.drupal.org uses for SSO. However, be warned that it doesn't play nice with the LDAP modules and if your user's clock is off by more than you session expiration amount they will only be able to log in with firefox.
On Wed, Jan 5, 2011 at 10:00 AM, Dave Metzler <metzler.dl@gmail.com> wrote:
Not sure I agree with this statement. SSO does not demand the sharing
of
the sessions table, but there are some things you will want to consider how you will share across the sites.... Such assail address and profile pictures. Anyway, this is starting to sound like a support question more than a development question... you might get better answers about how people use the products on the support forums and lists.
The CAS module provides some minimal functionality for saying, if you're logged into site A then you are logged into site B as well.
Sent from my iPad
On Jan 4, 2011, at 9:51 PM, "Roberto Gorjão" < roberto@asenseofdesign.com> wrote:
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped.
2- New users will be registered on the controller site users table, that will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Openid could be a solution ?
It wouldn't. SSO also permits the sharing of the "sessions" table, which is essential for the simultaneous login to work. That wouldn't happen with Openid that would login the user just on the one site he's logging in to.
HTH
Roberto
On Wed, Jan 5, 2011 at 5:20 PM, antgiant <antgiant+drupalDevel@gmail.com<antgiant%2BdrupalDevel@gmail.com>
wrote:
Bakery is what Drupal.org and groups.drupal.org uses for SSO. However, be warned that it doesn't play nice with the LDAP modules and if your user's clock is off by more than you session expiration amount they will only be able to log in with firefox.
Hi Antgiant, thanks a lot for your reply. Seems that bakery module works only with subdomain that are on the same second-level domain, that is not my case... :/ Ideally, i need a solution also to synchronize profile fields (it's not a strict requirement). The situation is really complicated because "username" are not unique across different sites, so probably "foobar" user of "site a" is not the same "foobar" of site b. I think that OpenID solution would be better, but all subsites must be in the same time provider/producer, example: 1) I have an account on site a 2) I log in with my openid account of site-a to site-b 3) site-b asking me if i'm a new user or i already have an account to site-b, if new site will grab data from site-a to create my new account otherwise it synchronize with site-b account. -- Paolo Mainardi CTO Twinbit Blog: http://www.paolomainardi.com -- Please consider the environment before printing this email --
Hi Roberto, On Wed, Jan 5, 2011 at 6:51 AM, "Roberto Gorjão" <roberto@asenseofdesign.com
wrote:
Hi Paolo,
The SSO must permits us to:
1) Normalize already registered users and automatically get them access to all site's network. 2) Same thing as before but for new registered users.
1- SSO doesn't "normalize" already registered users. As each database has, currently, it's users table, you'll have to merge users of all future "client" sites into the users table of the future "controller" site. Then, when setting up SSO, only this last users table will be used and the others may even be dropped.
Which module is capable to do this (SSO), probably you mean the core capabilities to share user tables ? And how fix the multiple "uid" already registered on multiple sites by the same users ? 2- New users will be registered on the controller site users table, that
will be shared with all the client sites. Therefore, yes, users will be "normalized" and get automatic access to all sites.
Yes, this is what i mean for "normalization". -- Paolo Mainardi CTO Twinbit Blog: http://www.paolomainardi.com -- Please consider the environment before printing this email --
Which module is capable to do this (SSO), probably you mean the core capabilities to share user tables ? And how fix the multiple "uid" already registered on multiple sites by the same users ?
Paolo, 1- As someone said, you should really put this kind of questions to the support list. 2- Google is your friend and so is the search field on Drupal site. 3- The module capable of doing "SSO" is called, not surprisingly, "SSO" and you may find it at http://drupal.org/project/sso 4- Try also this module -- User Import (http://drupal.org/project/user_import) -- to the second part of your question. HTH. Roberto
On Thu, Jan 6, 2011 at 7:55 AM, "Roberto Gorjão" <roberto@asenseofdesign.com
wrote:
Which module is capable to do this (SSO), probably you mean the core capabilities to share user tables ? And how fix the multiple "uid" already registered on multiple sites by the same users ?
Paolo,
1- As someone said, you should really put this kind of questions to the support list.
Robert, i just wrote here to ear your experience, not to have free support, i know that there are a lot of ways to do the things.
2- Google is your friend and so is the search field on Drupal site.
Got it, thanks.
3- The module capable of doing "SSO" is called, not surprisingly, "SSO" and you may find it at http://drupal.org/project/sso
Yes i know that module, but: "This module is still in it's very early stages. It works, it's secure and it's stable but it has problems with things like user registrations (i recommend pointing registration links to Controller site)" And, this is why i asked here your experience in the field.
4- Try also this module -- User Import (http://drupal.org/project/user_import) -- to the second part of your question.
I can't see the link between my question and this module, thanks anyway. -- Paolo Mainardi CTO Twinbit Blog: http://www.paolomainardi.com -- Please consider the environment before printing this email --
On Thu, January 6, 2011 8:00 am, Paolo Mainardi wrote:
On Thu, Jan 6, 2011 at 7:55 AM, "Roberto Gorjão" <roberto@asenseofdesign.com
wrote:
Which module is capable to do this (SSO), probably you mean the core capabilities to share user tables ? And how fix the multiple "uid" already registered on multiple sites by the same users ?
3- The module capable of doing "SSO" is called, not surprisingly, "SSO" and you may find it at http://drupal.org/project/sso
Yes i know that module, but:
"This module is still in it's very early stages. It works, it's secure and it's stable but it has problems with things like user registrations (i recommend pointing registration links to Controller site)"
And, this is why i asked here your experience in the field.
Have it installed in 5 websites from 2 different clients. No issues. You need to be smart about the tables you share though. Those recommended by the module documentation are a safe bet but you can share any other you want/need, as, for example, the roles table (if you'll be using exactly the same roles on each client website and on the controller website too).
4- Try also this module -- User Import (http://drupal.org/project/user_import) -- to the second part of your question.
I can't see the link between my question and this module, thanks anyway.
Well, for many problems there are just no magic solutions. As this module allows you to import users from all sorts of lists in several formats, you can do your own filtering elsewhere (search for duplicates, using any criteria you need, and eliminate them, either by querying the tables or by dumping them to csv format, for example, and working on the data in any other app that is convenient to you) and then use the result to add the users you actually need to the controller site's users table. HTH. Roberto
participants (5)
-
"Roberto Gorjão" -
antgiant -
Dave Metzler -
Greg Knaddison -
Paolo Mainardi