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.<div>
<br></div><div>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.</div>
<div><br></div><div>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.<br>
<br><br><div class="gmail_quote">On Wed, Jan 5, 2011 at 11:49 AM, Greg Knaddison <span dir="ltr"><<a href="mailto:Greg@growingventuresolutions.com">Greg@growingventuresolutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Can you expand on the Bakery+LDAP issues?<br>
<br>
And, maybe file it as an issue? ;)<br>
<font color="#888888"><br>
--<br>
Greg Knaddison | 720-310-5623 | <a href="http://growingventuresolutions.com" target="_blank">http://growingventuresolutions.com</a><br>
Mastering Drupal | <a href="http://www.masteringdrupal.com" target="_blank">http://www.masteringdrupal.com</a><br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
On Wed, Jan 5, 2011 at 9:20 AM, antgiant <<a href="mailto:antgiant%2BdrupalDevel@gmail.com">antgiant+drupalDevel@gmail.com</a>> wrote:<br>
> Bakery is what Drupal.org and <a href="http://groups.drupal.org" target="_blank">groups.drupal.org</a> uses for SSO. However, be<br>
> warned that it doesn't play nice with the LDAP modules and if your user's<br>
> clock is off by more than you session expiration amount they will only be<br>
> able to log in with firefox.<br>
><br>
><br>
> On Wed, Jan 5, 2011 at 10:00 AM, Dave Metzler <<a href="mailto:metzler.dl@gmail.com">metzler.dl@gmail.com</a>> wrote:<br>
>><br>
>> Not sure I agree with this statement. SSO does not demand the sharing of<br>
>> the sessions table, but there are some things you will want to consider how<br>
>> you will share across the sites.... Such assail address and profile<br>
>> pictures. Anyway, this is starting to sound like a support question more<br>
>> than a development question... you might get better answers about how<br>
>> people use the products on the support forums and lists.<br>
>><br>
>> The CAS module provides some minimal functionality for saying, if you're<br>
>> logged into site A then you are logged into site B as well.<br>
>><br>
>> Sent from my iPad<br>
>><br>
>> On Jan 4, 2011, at 9:51 PM, "Roberto Gorjão" <<a href="mailto:roberto@asenseofdesign.com">roberto@asenseofdesign.com</a>><br>
>> wrote:<br>
>><br>
>> > Hi Paolo,<br>
>> ><br>
>> >> The SSO must permits us to:<br>
>> >><br>
>> >> 1) Normalize already registered users and automatically get them access<br>
>> >> to<br>
>> >> all site's network.<br>
>> >> 2) Same thing as before but for new registered users.<br>
>> >><br>
>> ><br>
>> > 1- SSO doesn't "normalize" already registered users. As each database<br>
>> > has,<br>
>> > currently, it's users table, you'll have to merge users of all future<br>
>> > "client" sites into the users table of the future "controller" site.<br>
>> > Then,<br>
>> > when setting up SSO, only this last users table will be used and the<br>
>> > others may even be dropped.<br>
>> ><br>
>> > 2- New users will be registered on the controller site users table, that<br>
>> > will be shared with all the client sites. Therefore, yes, users will be<br>
>> > "normalized" and get automatic access to all sites.<br>
>> ><br>
>> >><br>
>> >> Openid could be a solution ?<br>
>> ><br>
>> > It wouldn't. SSO also permits the sharing of the "sessions" table, which<br>
>> > is essential for the simultaneous login to work. That wouldn't happen<br>
>> > with<br>
>> > Openid that would login the user just on the one site he's logging in<br>
>> > to.<br>
>> ><br>
>> > HTH<br>
>> ><br>
>> > Roberto<br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>