Problems with CAS and ldap_integration

I'll try to schedule some time to look at this on Thursday. Hopefully someone with direct experience in using LDAP with CAS will respond sooner.

Dave

This is just my guess, but I've worked both LDAP & CAS in my time here is my thoughts.

hook_user's parameter $op sends 'login' if you login with LDAP at the time of login but if you login with CAS, it doesn't. Just 'load'. I've noticed this when I was creating modules that triggers at the time of login. Since I was looking for 'login' from $op, it never tirggered when CAS is used for authentication, but worked for LDAP login.

Here is my thoughts. LDAP modules of sync user information part could be triggered by $op parameter to be 'login'. In that case, CAS login will never trigger LDAP user sync.

Just my thoughts.

Well we supposedly fixed this in the latest rev. Login and logout hooks are supposed to be fired by Cas. I'm looking into this. I'll be adopting LDAP groups use at my site soon, so I'll get some thorough testing in on this subject.

Dave

Dave, have you adopted LDAP groups and CAS?

You know I never did. I started the effort but realized that you had to write PHP code in order to get LDAP groups to work the way I wanted. It seemed that you had to write custom code to map the groups to drupal roles. I didn't and still don't like this approach, and didn't have time to submit a proper patch to LDAP groups, so I kinda dropped the ball there.

Then I changed jobs, and LDAP was no longer my purview. I changed from being a network guy to being a full time programmer, thank god!

Since then I've been collaborating with some other folks about a better way to limit drupal sites to specific groups using custom modules. There's some new hooks in the cas module to that effect 5.x.3 has the ability to use an auth_filter hook to further limit who get's authed to a drupal site. There still haven't been any modules to my knowledge that do this, but it seems like a good approach.

If the LDAP groups module ever makes a change to the role mapping functionality to not require custom code, I may still take this up again. I had hoped that the LDAP folks would take up the challenge of making this all dependent on hook_user invocation, but I haven't heard much since then. That would (I believe) remove the need for any LDAP specific code in the cas module.

Hope that helps. If there's anything else I can do, let me know.

Dave

I should also note that the current versions of cas do invoke hook_user for login and logout.

Dave

I had the same problem with cas 5.x-3 and ldap_integration 5.x-1.3 and the Fatal Error on function connect.

It seems that ldap_integration has changed some global variables names, so that ldap connexion failed in cas module: so I wrote a patch to fix this that works perfectly for me.

I hope it will help.

Régis

Fixed in head and in the drupal 5 main branch.

Thank you for patch to solver. but I had some problem about email and group information there are can't got from ldap integration. even if i checked both the box "Should we extract the user email from an LDAP directory?" and "... extract the user group from an LDAP" already. but if i used ldap_integration module directly it work.

I hope someone to help me solve.

sorry for my English is tired. - -
and I can't use php language. Please show me your code if it not take hardship to you

Thank you.

I agree, that changes should be done in the ldap integration modules. Actually hook_user is used there but will not work as expected because sync is only done for users authenticated via LDAP and not via CAS.

Because I needed LDAP role and data synchronisation I have written some custom code for the cas module that should do the job. I tried to reuse as much code from the LDAP integration modules without the need to modify these modules. Now roles get synchronised and you have an additional setting to synchronise using the ldapdata module.

A patch for Version 6.x-1.0 is attached along with some comments about the implementation details. Maybe you want to have a look at it and integrate it in your development snapshot?

The patch includes the following changes:

* The LDAP sync is now done in the hook cas_user.
* Added an option for using the ldapdata module.
* Added options to initialize CAS as a proxy.
* Added an option for CAS debugging output filename.
* Fixed a little bug in _get_ldap_config_name: _ldapauth_init needs the sid not the name.

I have noticed another problem in this context:
* cas_form_alter did not work for me because it does not react on formid="user_profile_edit". Maybe the function is not fully ported to Drupal 6.x? Anyway, the ldapdata module syncs the email address.

Tim

Regarding the form alter, stuff, You're correct and there is a separate bug filed for that.

Regarding the user sync/login patch. If we can get this to work based on the cas_user hook , then shouldn't it be a separate module? Or filed as a patch to the LDAP module? I suppose that I could host that module with this project, but it continually bothers me that I have code in the cas module that I have no way of testing, because we just don't have an ldap environment. There's really nothing about cas that suggests that you need an ldap environment.

Dave

Even more in CAS 3 you can return attributes so connection with ldap is needed even less. I think you should rip out the ldap stuff and create a separate module. At least you can maintain it separately and maybe be able to get someone to take over the development of it.

Bahnes,

I would separate that patch into separate issues. LDAP, proxy, debugging, _get_ldap_config_name it makes reviewing patches easier. But it's Dave's module so it's really up to him.

Dave, I liked the idea of building a separate module. It works for me but I think you're right that this should be integrated in the LDAP module. What makes it difficult is that the LDAP module only synchronizes if you're authenticated by ldapauth. If I have a little time I file a feature request there.

If anybody wants to use my module, I provide it here as is. Because I don't have the time to maintain this as a standalone project I attach it to this issue and maybe someone will adopt the code. It uses some code of the CAS module. Comments are welcome.

I just installed this module, and it's working great. I was just wondering if you (or someone) could tell me how I could tweek it so that I can set permissions for the module making the admin settings only accessible to specific user accounts.

Right now, everyone that I give access to the admin pages has access to these settings.

Thanks,

-Tim

The Admister CAS setting under access control should be it. Remove that for any users. I'll check this, cause if that aint the case then it's a bug.

Dave

Please do check. I just looked at my setup and have not given perms to CAS for any of the roles in my install and can only access these settings through the 1st admin account.

Thanks,

-Tim

I'm officially won't fixing this until such time as someone is willing to step up to the plate to maintain a cas_ldap module that integrates the auth_filter and user_login hooks. If someone were willing to provide such a module, I'd be willing to host it here, but I need a committed maintainer.

I'm a web application's designer at Brigham Young University. This module is important enough to our department that we will try and maintain and support it. This may take time but we are looking into it.

This module is important enough to our department that we will try and maintain and support it.

excitebike, I'm using this at UC Berkeley. If you need help, let's talk.

I'm glad to hear that.... Let me know if you need any help. I don't have an ldap environnment, but I'd be happy to help navigate the cas code. Has anyone managed to sparate the LDAP code into something that responds to auth_filter and user_login hooks? Would love to see some code here.

Dave

just as an fyi, the following diff is needed to work with the latest ldap_integration code

119,123c119,122
< // changed init to utilize hook_user now in ldap_integration
< module_invoke("ldapgroups", "user", "login", null, $user);
<
< // Synchronize LDAP groups - redundant
< // module_invoke("ldapgroups", "user_login", $user);
---
> module_invoke("ldapgroups", "init");
>
> // Synchronize LDAP groups
> module_invoke("ldapgroups", "user_login", $user);

Tom, can you create a separate issue and attach a unified diff (cvs diff -u)?

ldapsync is included in this thread and this is just a patch to that.. my diff was wrong that I included here (I copy and pasted from the wrong screen)

the correct diff is

119,122c119
< module_invoke("ldapgroups", "init");
<
< // Synchronize LDAP groups
< module_invoke("ldapgroups", "user_login", $user);
---
> module_invoke("ldapgroups", "user", "login", null, $user);

patch attached

Module_invoke is not compatible with PHP 5.3, because the $user must be passed by reference. All user hooks should now be invoked with user_module_invoke. The CAS module has been updated. Also it should be noted that the user login hook is always invoked by the cas module. Is it possible to refactor this code so that it doesn't need to be called twice in the login process?

Please update from HEAD and/or the latest dev snapshot and patch against that.

Metzlerd,

I am trying to make the changes you suggested above and don't seem to be having any luck making it work with PHP5.3 using the user_module_invoke. Do you think that you would be able to help with making that change? My original thought was to change the call to something like

$array = ('user', 'login');
user_module_invoke('ldapgroups', $array, $user);

but this doesn't seem to be calling it correctly. Any help you (or anyone else) can provide would be greatly appreciated.

Thanks!