LDAP Authorization: Need ability to select multiple Servers in single Authorization consumer configuration

This is a duplicate of #1050944: LDAP Authorization doesn't support multiple mapping configurations for a given consumer type and was a design decision largely based on the complexity of the U.I. and lack of interest in writing documentation. Its also related to #1248116: Allow users on one LDAP server to be assigned roles defined on a different server.

Its very doable and several people have presented use cases for it.

I would suggest following up on #1050944: LDAP Authorization doesn't support multiple mapping configurations for a given consumer type with a focus on what the U.I. would look like. The issue in #1248116: Allow users on one LDAP server to be assigned roles defined on a different server is more of an edge case.

Though this issue is related to the use case in the closed issue #1050944: LDAP Authorization doesn't support multiple mapping configurations for a given consumer type, it is not a duplicate and work still needs to be done to address this issue (as suggested by johnbarclay in issue #1561828: LDAP Authorization does not handle multiple configurations).

#1050944 points out that the authorization configuration should use check boxes instead of radio buttons so that more than one server can be selected and queried for authorization groups. This work has not yet been done, and one way to address this use case.

Currently this use case can not be addressed in Drupal. But if it is possible to support queries against multiple servers via including multiple authorization configurations (issue #1561828), then this issue is less important. At a minimum the documentation should be clarified on how to address this use case.

However, it might still be worth implementing. The big advantage of being able to apply a single configuration against multiple servers is that it widens the number of use cases that can be solved with the out-of-the-box modules and saves administrators writing their own LDAP Drupal role authorization modules with associated class (a process that was not very straight-forward to figure out).

I hadn't though of this use case. I looked at the possibility of multiple configurations per consumer type, but never multiple servers for a single consumer configuration. The latter seems like a very edge case, but is much easier to implement. Since the server configuration controls the ldap entry to drupal user mapping, to implement multiple servers for a single consumer configuration they would essentially have to be the same ldap implementation on all the servers with the same set up users or a mutually exclusive set of users.

To implement this would only require:
- changing radios to checkboxes in configure
- an approach to looping through mulitple configurations in the authorization code.

Before we head down this path, are you sure you want a single ldap authorization for each consumer type with multiple servers; or multiple configurations for a each consumer type.

We had to get something in production so we decided to force some of our users to have an account on both servers. It's not what we wanted, but it gets the project done. That means that this issue is not time-sensitive for us, but it has come up before so I expect at least a thorough explanation would be useful to other users.

My use case is adequately served by having one configuration per server, and writing the authorization configuration module to do the correct mapping on each server (but this is currently prevented by #1561828). However, I find that cumbersome to implement, and involves lots of copy-paste code.

If the default authorization configuration module can be enhanced to meet more use cases, it would be a lot easier to setup. Perhaps this approach would be sufficiently flexible if we added to the authorization rules an optional server parameter:
LDAP servername / LDAP group | drupal role

The process would be:
* When a user authenticates, test each server for a username / password in the order specified (see #1561836: LDAP Server: Cannot select server order)
* If the user successfully authenticates, test the result from that server against each authentication mapping specified in the drupal_role configuration that matches that server. If no rules match that server, then test any rules that have no server specified.
* If any succeed, grant those roles.

This requires a lot less configuration, no PHP modules, and can be very predictable.

This assumes the user is authenticating with the ldap_authentication module and both ldap authentication and authorization data are on the same ldap implementation. Authentication and authorization need to be decoupled so preferred use cases work (CAS, Shib, SSO, etc.) can be implemented.

Do any of my suggestions in comment #4 seem useful for your use case?

I am not sure which suggestions you are referring to.

I believe my use case can be met by either a single authorization configuration for each consumer type that hits multiple servers, or multiple configurations for each consumer type (one for each server).

It sounds like multiple configurations for each consumer type is easier to implement.

But a single authorization configuration that can hit multiple servers would be easier to administer.

You are in a better position to evaluate the best approach than I am.

Thank you for considering the proposal.

multiple servers for each configuration is easier to implement.

To implement this would only require:
- changing radios to checkboxes in configure
- an approach to looping through mulitple configurations in the authorization code.

Clarifying the scope of this issue report.

I got a start on this. Found a use case where we are in a merger with another company and are authenticating users from 2 different domains that have a domain trust established. I've got the admin interface worked out but could use some help on actually choosing the correct server to get the mapping from.

This thread is about getting the provisioning to work with the authenticating ldap (whichever one the user has successfully authenticated against). Since you are doing the same with authorization, it will follow the same pattern.

So this approach solves issue #1 in the issue summary where applying a single authorization to multiple servers. I followed the same pattern as authorization did which is authorize against the same server the user authenticated against. Hope that makes sense. Here is a screenshot of the changes to the admin interface.

And the patch as AJAX upload is broken on d.o apparently.

I'm surprised this still isn't in the release... Thanks @haydeniv for the patch. I applied it today to 7.x-2.0-beta8 on Drupal 7.38 and it works almost perfectly. I noticed a couple of things, though:

1. If you're logged in as Drupal-only user (like admin) and try to configure the module, you get an error

Undefined index: ldap_user_session_prov_sid in LdapAuthorizationConsumerConf->loadFromDb() (line 112 of C:\vhosts\DrupalTest\sites\all\modules\ldap\ldap_authorization\LdapAuthorizationConsumerConf.class.php).

I fixed it by making this change:

// Original 
if($this->sid == LDAP_USER_AUTH_SERVER_SID) { //...
// New
if($this->sid == LDAP_USER_AUTH_SERVER_SID && isset($_SESSION['ldap_user_session_prov_sid'])) { //...

2. Testing for authorization doesn't work if you're logged in without using LDAP or when you're logged in using one LDAP server and are testing for a user in another LDAP server. Additionally, when testing as non-LDAP user, you get this error:

Trying to get property of non-object in ldap_authorization_ldap_attributes_needed_alter() (line 153 of C:\vhosts\DrupalTest\sites\all\modules\ldap\ldap_authorization\ldap_authorization.module).

I now know how to make patches! My fix added to #13.

I discovered that users created outside LDAP with multiple server set up don't get provisioned even when you untick the "Only apply the following LDAP to drupal role configuration to users authenticated via LDAP" box in Authorization Configuration. It appears that ldap_user, ldap_servers, and ldap_authorization get a bit confused in places about the LDAP_USER_AUTH_SERVER_SID and the code often relies on SID to actually point to a server.

I have fixed it in the least invasive way I could think of. My fix contains patch from #1917254-23: LDAP Authorization does not map ldap groups to drupal roles and of course the previous fixes from this issue. Tested on Drupal 7.43 with PHP 5.6 and MSSQL Server 11.0.3156.0 [SP1] Standard Edition (64-bit).

I think this needs tests.

I didn't add any tests. I just rebased it and cleaned up some of code style.

I have tested the functionality and it works.
However, I still think it needs code tests.

Also, it would be nice if someone could explain the difference between the `ldap_user_puid_sid` user field and the `data['ldap_user']['init']['sid']` user field.

This patch gives predence to the `data sid` field before the `puid_sid`.
In my setup the `puid_sid` field is never populated, even though that doesn't make sense to me from what I can remember of the code path.

The part of the patch that comes from https://www.drupal.org/node/1917254#comment-9991335 should probably be removed from the patch for this issue.

Using the patch from #21 throws errors if I turn on "Deny access to users without Ldap Authorization Module authorization mappings such as Drupal roles. Requires LDAP Authorization to be enabled and configured!"

PHP Fatal error: Call to a member function groupUserMembershipsFromDn() on a non-object in [path to module]/ldap_authorization/ldap_authorization.inc

This is because the LdapAuthenticationConf class calls ldap_authorizations_user_authorizations() with a fake $user object that does not have any $user->data properties set.

I have just applied the code in the patch from #21 to the 7.x-2.3+18-dev release to try to get Ldap Authorization across multiple Active directory servers. It didn't seem to make any difference if if have "Deny access to users without Ldap Authorization Module authorization mappings such as Drupal roles. Requires LDAP Authorization to be enabled and configured!" turned on or not.

I still get the same PHP Fatal error as drasgardian.

I would very much appreciate any ideas on how to move this forward.

Closing issue as outdated due to no further development on 7.x, if you feel this issue is still relevant and you are willing to work on a patch and/or debug the problem, please reopen.