Integration with LDAP

Posted by narres on July 21, 2006 at 8:45am

There are several discussions about integration of Drupal, Moodle, Elgg, aTutor and so on.

The questions:
- Is there a common user database?
- Which software is integrated in which (Drupal in Moddle or Moodle in Drupal)?
- Is this a real integration or only a synchronisation of user accounts?
- Which version works which version?

The current solutions are very version specific and specialized. A huge disadvantage is, that they are not using a common user database: They are only synchronising the user accounts.

As it doesn't make sense to integrate Drupal into Moodle, the question (not only Moodle specific) is: "How do I integrate other web-applications into Drupal?". In fact: "How do I use the Drupal user database from outside?".
So, you will find more information on the "other" software sites:
http://www.google.com/u/moodle?q=drupal&sa=Search+this+site&domains=mood...

In my opinion a common centralized LDAP authentification would be the better way:
http://drupal.org/project/ldap_integration
http://moodle.org/mod/data/view.php?d=13&rid=314 (Moodle)

Building a common userbase in this way makes you able to integrate other software, as:
http://forums.vtiger.com/viewtopic.php?t=1689&highlight=ldap

Categories: eLearning, LDAP, moodle

Comments

site specific

Posted by moshe weitzman on July 21, 2006 at 12:41pm

moshe weitzman's picture

your answer depends on the capabilities of your other system, and the capabilities of your users. your options are many though. drupal's distributed auth feature (see drupal.module) is a web services auth integration point, you can just query the drupal users table when needed, ...

and it certainly is reasonable and sometimes easier to just let the 3rd party app (in this case Moodle) be the master and configure drupal as the slave.

The other piece of this

Posted by bonobo on July 23, 2006 at 7:10am

bonobo's picture

The other piece of this discussion involves the method of SSO --

As you point out, most of the solutions discussed are version specific and specialized -- an ideal integration would allow for a simple install that worked in a variety of situations -- basically, the SSO piece (we'll get to the user piece in a second) needs to work without touching the core code of any app involved in the integration.

RE users -- the need to maintain duplicate user data within an organization is a dealbreaker. This is the advantage of a distributed authentication system like OpenID -- on the backend, you can authenticate from any data source, including but not limited to LDAP. Incorporating a userbase from legacy systems is possible, which eliminates the need for duplicate sets of user data. When Access Control Lists become a reality, it will be possible to eliminate any user data ever being stored on any site other than the central source accessed by the OpenID server. Until that point, however, it makes sense (ie, can be done without writing any additional code, using the existing functionality of Elgg, Drupal, or Moodle) to let a user's privileges be set within the different apps.

FunnyMonkey

Check it

Posted by bezprym@drupal.org on July 24, 2006 at 8:20pm

bezprym@drupal.org's picture

I started some discussion about that issue at the Moodle forum.
Check it ;)

LDAP great for single organizations

Posted by adavidow on September 25, 2006 at 4:55pm

adavidow's picture

The SSO piece depends very much on scope. If the relevant domain is a single organization, LDAP (or equivalent - but my preference right now is LDAP) is a major sanity point - it's relatively easy to set up and administer ("easy" also being a relative term, here), and gives organizations a single point from which to administer some of the trickier access issues (most often, that rare, "lock this person out of all of our servers" crisis, but also ensuring that the admin assistant can get into all relevant secured sites with a minimum of fuss and muss).

Once you have a distributed framework, however, and more than one IT organization is involved, I'm open to hearing that there are other solutions, or that some localized sign-on is saner.