[development] Single signon question

[antgiant]

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 at 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 at gmail.com<antgiant%2BdrupalDevel at 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 at 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 at 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110105/b3ebca97/attachment.html