[PPNL-Techteam] Drupal & ldap

Casper Gielen casper at gielen.name
Wed May 16 20:06:52 CEST 2012


On 05/16/12 17:33, Bèr Kessels wrote:
> Hallo,
> 
> Ik mail je even buiten de ML om. om wat achtergrondinformatie te geven
> en hopelijk vooral te krijgen.

Ik stuur mijn antwoord gewoon naar de lijst zodat anderen kunnen meegenieten,
ik zie geen informatie die ik als gevoelig beschouw.


> * LDAP is hierarchisch. Dus zullen permissies uit LDAP nooit goed
> overgezet kunnen worden naar Drupal en viceversa.
> * LDAP doet niets met sessies, maar biedt wel de mogelijkheid om sessies
> te delen over domeinen. Maar dat staat Drupal weer niet toe: Als Anna
> ingelogd is op FooBar moet zijn op AnderCMS ook ingelogd zijn" kan dus
> niet, als FooBar of AnderCMS Drupal zijn.
> * LDAP bevat metadata: volledige user-documenten. Drupal ook. Beide
> moeten gemapped (FName <=> profile_node->field_names->first_name) en
> gesynchroniseerd worden. Of, indien geen synchronisatie op een van beide
> platformen read-only gemaakt worden. Drupalvelden read-only maken is,
> gek genoeg, moeilijk.

Voornoemde drupal-module kan in ieder geval overweg met de hierachisch structuur
van Drupal. Ook is er ondersteuning voor synchronisatie van meta-data, maar dat
is nog niet klaar voor prime time.
Je text over sessies kan ik niet helemaal volgen. Heb je het hier over Single
Sign On? Dat staat wel op de wishlist, maar daar doen we nog niks mee. Dat is voor later.

> Mijn advies is dus altijd geweest:
> 
> Alleen LDAP voor:
> * mag inloggen met username x en password y? Ja of Nee.
> Andere zaken: zoals synchen van profiel- of administratieve gevens: niet
> doen.

Dat is wat ik doe. Ik heb nog 1 extra ding, ik kan één of meerdere drupal-rollen aan
een gebruiker koppelen via LDAP. Het idee is om hiermee een grove indeling in de
gebruikers te maken (bv 'lid', 'admin' of 'bestuur') en dit verder uit te splitsen
binnen Drupal met hulp van Organic Groups.
Andere applicaties kunnen een andere beslissing nemen.

> 
> Nogmaals: ik wil niet inbreken, maar heb sterk het gevoel dat het
> releasen vertraagd wordt door een koppeling die, in mijn ervaring,
> gewoon nooit goed zal gaan :)

De LDAP-integratie is af en werkt. Daar hoeft eigenlijk niks meer aan te gebeuren.
Voor deze ronde dan. Voor de toekomst staat alles open, maar wat mij betreft zitten
we nu in de afronding van onze eerste fase.
Als we live gaan (hopelijk dit weekend) zal er wel een stortvloed aan problemen op ons
af komen. Als die opgelost zijn gaan we discussieren over hoe het anders/beter moet.

>> Een ander probleem is ldap-provisioning; het aanmaken van nieuwe accounts in LDAP vanuit
>> Drupal. In Drupal6 bestond daar een module voor maar die is niet compatible met Drupal7.
>> Deze functionaliteit is ook beloofd voor Drupal7 maar is nog niet af. Sterker nog, die
>> functionaliteit zou vandaag gereleased worden, maar de release is helaas uitgesteld.
> 
> Deze heeft voor Drupal6 ook altijd erg rommelig gewerkt. Zo bleek het
> bij audit die ik voor een klant deed, het mogelijk om vanuit een
> Drupalsite jezelf te binnen de organisatie leveragen: jezelf in LDAP
> opeens Company-wide administrator-rechten te geven (Die org gebruikte
> dezelfde LDAP ook voor inloggen op PCs en dergelijke, Drupal vereistte
> "write-all", ofwel root-rechten voor zichzelf op die database. Een
> foutje in Drupal betekende dus dat de veiligheid van de hele
> company-authtenticatie doorbroken werd)

Dat ga ik uiteraard niet toe staan.
Het hele provisioning-vanuit-drupal is sowieso niet voor deze development-ronde. Ik zou het op zich
wel willen, maar dan moet het naturlijk wel goed werken. Als de kwaliteit niet goed genoeg is dan
gaat het feest niet door.  Maar op dit moment is het dus nog helemaal geen overweging want KISS.

> 
> Ook hier is mijn advies altijd geweest: don't: blijf daar ver van weg :)

Het probleem is, gebruikers moeten ergens vandaag komen. Er is een stuk software nodig dat
gebruikers aanmaakt, en het liefst zo dat gebruikers zelf een account aan kunnen maken.
Dat soort software is verbazend zeldzaam.

> Wat was jullie hoofdreden om met LDAP in de weer te gaan? Zijn er
> alternatieven overwogen? zo ja, welke?

De hoofreden is dat ik wil dat gebruikers maar één account nodig hebben voor al onze diensten. Naast
Drupal hebben we ook nog een wiki, een forum, een civicrm, een ftp(s)-server en een liquid-feedback,
en dat zal in de toekomst alleen maar meer worden. Mensen vragen om zes verschillende accounts aan
te maken gaat ook een puinhoop geven. Daarbij zou ik het
wel fijn vinden als er 1 interface is om gebruikers te managen en rechten toe te kennen.

Als je meerdere applicaties aan één user-database wil hangen kom je al vrij snel bij LDAP uit. Ik
heb nog overwogen om maar direct voor CAS te gaan maar dat zou te veel werk zijn geworden.
Toen ik eenmaal had besloten om LDAP te gebruiken vond ik ook nog een oude LDAP-database met meer
dan 100 accounts, dat al deze mensen hun account niet opnieuw hoeven aan te maken was mooi
meegenomen, want de eerste weken was er geen enkele manier om een nieuwe account aan te maken
(behalve een admin met ldap-rechten & kennis vinden).

> 
>> Als alternatief gebruik ik PMW (https://pwm.piratenpartij.nl). Op zich een prachtig product
>> maar wat meer integratie met Drupal zou wenselijk zijn. Ik ben eerlijk gezegd zo onder de indruk van
>> PWM dat ik overweeg om het permanent te maken. Daarbij heeft het ook wel voordelen om niet
>> afhankelijk te zijn van Drupal voor het aanmaken van nieuwe gebruikers.
> 
> PWM zegt me niks, maar klinkt interessant. Heb je een link?

http://code.google.com/p/pwm/


> Maar is er ooit overwogen om heel eenvoudig, een centrale openID server
> in te zetten? Daarom zou een simpel account-management kunnen zitten
> voor jullie om mensen, IPs en dergelijke te blokkeren.
<knip uitleg openid>
> Ik heb enkel ervaring met de server https://github.com/dbloete/masq.
> Maar vind dat een mooi stuk werk.
> 
> Nogmaals, niet voor nu.
>
> Maar ik wil me zeker opwerpen om een masq in te regelen als demo. Met
> een simpele Drupal (core) en mediawiki ernaast, dummy, maar om te
> demonstreren hoe zo een gedeelde inlog en -account omgeving kan werken.
> Uiteraard als daar animo voor is.


Ik ben op zich wel fan van OpenID maar, zoals je zelf zegt, voor nu is het te veel werk, zeker als
we applicaties moeten gaan aanpassen om er gebruik van te maken. Daarnaast kun je OpenID alleen
gebruiken voor authenticatie en niet voor authorisatie. Er zou dan alsnog een tweede systeem naast
moeten komen om rechten uit te delen.
Eerlijk gezegd ben ik ook bang dat OpenID voor veel mensen te ingewikkeld is. Het is conceptueel
heel anders dan wat ze gewend zijn.

Ik zou het wel leuk vinden om OpenID ook toe te staan, maar als enige methode lijkt me niet
verstandig. Ik zou dan alsnog LDAP blijven gebruiken, maar de mogelijkheid bieden om ook OpenID aan
je account te koppelen. Als je dan OID hebt (van ons of van elders) kun je dat gebruiken om in te
loggen op de diensten die het snappen. De rest werkt gewoon met username/wachtwoord.

> Oh. en overal waar men openId toestaat kun je met je
> http://leden.piratenpartij.nl/jane inloggen. ExtraGratis reclame en een
> mooie "badge" voor leden om online mee te pronken :)

Persoonlijke bitterheid: waar dan? vrijwel niemand staat OpenID-logins toe. Identity Provider spelen
wil iedereen wel doen, maar logins van andere IDPs accepteren is nog altijd zeldzaam :(
-- 
Casper


More information about the Techteam mailing list