LDAP-strategia: tobbfajta usert hogyan?

[KORN Andras]

Sziasztok,

adott egy ceg, par tucat alkalmazottal; ezek szepen benne vannak egy
LDAP-faban, ou=People,dc=cegnev,dc=tld alatt, posixAccount es shadowAccount
objectclass-szal. Eddig jo.

Van egy csomo szolgaltatas, ami az LDAPbol authol (kismillio host ssh-val,
courier imap, webes ezazamaz). Eddig is jo.

Viszont van egy partnerceg, szinten jopar tucat alkalmazottal, es az o
usereik is kellene hogy hasznalhassanak bizonyos webes szolgaltatasokat,
sot, esetleg bizonyos hostokra lephessenek is be ssh-val, de csak azokra.

Felolem lehet uidNumberuk a partnerusereknek is, de nem baj az se, ha nincs
(az ssh-hoz persze nyilvan kell, de a webes cuccokhoz nem).

Hogyan erdemes ezt csinalni es miert ugy?

Nyilvan tobbfele megoldast is el tudok kepzelni (pl. uj reszfaba rakom a
partnerceg usereit es ahol kell, feljebb rakom a search base-t; vagy valami
csoport-alapu megoldas; stb.). Sajnos ezeknek a hosszu tavu
hasznalhatosagat/implikacioit nem latom at, ugyhogy ha valaki mar megoldott
ilyesmit valahogy, az legyszi irja meg, hogy csinalta, es hogy ma is ugy
csinalna-e. :)

Koszi

Guy

[Kovács Attila]

Post by KORN Andras
Hogyan erdemes ezt csinalni es miert ugy?

Én úgy csinálnám hogy a szolgáltatásokat külön szolgáltatások részfába
gyűjteném,
a két partnercégnek meg szintén külön részfát készítenék, tehát lenne
egy ou=partner1,
ou=partner2, meg egy ou=szolgáltatások részfa a dc=énszolgálom ki őket
alatt.
A problémád abból fakad imho hogy az ldap definíció szerint vertikális
felépítésű hierarchiájú. Ez nyilván korlátokat is jelent, amiket csak
csúnya
módon tudsz megkerülni. Szerintem így lesz a legkevesebb gondod.

Elfilóztam közben ezen az ldap fán :)))).
A kettős könyvelés elve teljesen jól alkalmazható a felmerülő
problémákra érzésem szerint, de a kutyának van kedve mélyebben
belegondolni ;).

[KORN Andras]

Post by Kovács Attila

Post by KORN Andras
Hogyan erdemes ezt csinalni es miert ugy?

Én úgy csinálnám hogy a szolgáltatásokat külön szolgáltatások részfába
gyűjteném, a két partnercégnek meg szintén külön részfát készítenék, tehát
lenne egy ou=partner1, ou=partner2, meg egy ou=szolgáltatások részfa a
dc=énszolgálom ki őket alatt. A problémád abból fakad imho hogy az ldap
definíció szerint vertikális felépítésű hierarchiájú. Ez nyilván
korlátokat is jelent, amiket csak csúnya módon tudsz megkerülni. Szerintem
így lesz a legkevesebb gondod.

Ezt most nem teljesen ertem. Mi lenne az ou=szolgaltatasok alatt? Milyen
objectclasst hasznalo entitasok? Jelenleg a szolgaltatasok egyaltalan nem
jelennek meg az ldapban, csak hasznaljak.

Azt sem latom egyelore, hogy ha tobb ou-ban vannak a userek, az hogyan
jelent megoldast arra, hogy bizonyos szolgaltatasokat az {x, y, z}
userhalmaz vehessen igenybe, masokat pedig a {w, y, z}. Ha meg lehet adni az
adott szolgaltatasnal osszetett filtert, amivel keressen hitelesiteskor,
akkor megoldas, de pl. azt sem tudom elore, hogy melyiknel lehet ilyet es
melyiknel nem (a jovoben bevezetendoket is ideertve) - ezert orulnek
tapasztalatoknak. :)

Guy

[Kovács Attila]

Post by KORN Andras
objectclasst hasznalo entitasok? Jelenleg a szolgaltatasok egyaltalan nem
jelennek meg az ldapban, csak hasznaljak.

Honnan tudják, hogy kinek mire van joga?

Post by KORN Andras
Azt sem latom egyelore, hogy ha tobb ou-ban vannak a userek, az hogyan
jelent megoldast arra, hogy bizonyos szolgaltatasokat az {x, y, z}
userhalmaz vehessen igenybe, masokat pedig a {w, y, z}. Ha meg lehet adni az

Szerintem úgy hogy a szolgáltatások alatt felveszel egy objektumot, ami
alá beteszed
az engedélyezett usereket.
Az user fát authentikálásra használod, a szolgáltatás fában
hozzárendeled a jogokat.
Az user fában megvan a partnercégneved, a felhasználód, rátalálsz, a
szolgáltatás tudja hogy milyen szolgáltatáscsoporthoz tartozik, alatta
megtalálhatod
az usert, vagy ha igényes vagy és készítesz még egy részfát a
felhasználócsoportoknak,
akkor meg azt.

Ha az engedélyezendő szolgáltatás nincs benne (vagy valami ráutaló id,
bármi) külön a
fában, hanem a leveleken óhajtod tárolni, beleőszülsz ;). Szerintem
persze. Mondjuk
ldap-pal nincs tapasztalatom, de az nds-t már elég régóta ismerem és az
is ldap
megvalósítás ha jól tudom :).

[KORN Andras]

Post by Kovács Attila

Post by KORN Andras
objectclasst hasznalo entitasok? Jelenleg a szolgaltatasok egyaltalan nem
jelennek meg az ldapban, csak hasznaljak.

Honnan tudják, hogy kinek mire van joga?

A legosszetettebb korlatozas eddig az, hogy csoporttagsaghoz van kotve
valamilyen szolgaltatas hasznalata.

De tenyleg, szerinted milyen objectclass-szal kellene megjelennie mondjuk
egy trac-nek vagy egy subversion szervernek az LDAPban, es aztan hogyan
hasznalnad hitelesitesre/engedelyezesre?

Post by Kovács Attila

Post by KORN Andras
Azt sem latom egyelore, hogy ha tobb ou-ban vannak a userek, az hogyan
jelent megoldast arra, hogy bizonyos szolgaltatasokat az {x, y, z}
userhalmaz vehessen igenybe, masokat pedig a {w, y, z}. Ha meg lehet adni az

Szerintem úgy hogy a szolgáltatások alatt felveszel egy objektumot, ami
alá beteszed az engedélyezett usereket.

Leirnad ezt egy peldaval, objectClassok es attributumok szintjen? Igy sajnos
nem ertem.

Post by Kovács Attila
Az user fát authentikálásra használod, a szolgáltatás fában hozzárendeled
a jogokat.

Ez az elv vilagos, de vagy nem lattam meg olyan szolgaltatast, ami ezen az
elven autentikalna, vagy nem tudatosult bennem...

Guy

[Kovács Attila]

Post by KORN Andras
De tenyleg, szerinted milyen objectclass-szal kellene megjelennie mondjuk
egy trac-nek vagy egy subversion szervernek az LDAPban, es aztan hogyan
hasznalnad hitelesitesre/engedelyezesre?

|
DC= Nagykupac
/ | \
/ | \
ou=Partner1 ou= Partner2 ou=Szolgaltatasok
| |
/ | \
uid,etc user uid,etc, use svn1 svn2 trac
/

userazon,jogok

Ja, most értettem meg hogy mire célzol :).
Megnézem hogy van-e a modellemhez osztályobject :).

[Kovács Attila]

Post by KORN Andras
De tenyleg, szerinted milyen objectclass-szal kellene megjelennie mondjuk
egy trac-nek vagy egy subversion szervernek az LDAPban, es aztan hogyan
hasznalnad hitelesitesre/engedelyezesre?

dn: cn=trachasznalo, ou=szolgaltatasok, dc=nagykupac
cn: trachasznalo
objectClass: groupOfNames
member: uid=partner1user1uid, ou=partner1, dc=nagykupac
member: uid=partner1user2uid, ou=partner1, dc=nagykupac
member: uid=partner2user1uid, ou=partner2, dc=nagykupac
----

Persze sok felhasználónál az useridek helyett célszerű csoportokat
használni gondolom. Megvallom őszintén hogy én az alkalmazás
jogosultságokat inkább rdbms-ben tárolnám, de akinek kalapács
van a kezében, az mindent szögnek lát :).

[KORN Andras]

Post by Kovács Attila

Post by KORN Andras
De tenyleg, szerinted milyen objectclass-szal kellene megjelennie mondjuk
egy trac-nek vagy egy subversion szervernek az LDAPban, es aztan hogyan
hasznalnad hitelesitesre/engedelyezesre?

dn: cn=trachasznalo, ou=szolgaltatasok, dc=nagykupac
cn: trachasznalo
objectClass: groupOfNames
member: uid=partner1user1uid, ou=partner1, dc=nagykupac
member: uid=partner1user2uid, ou=partner1, dc=nagykupac
member: uid=partner2user1uid, ou=partner2, dc=nagykupac
----

Es ezt meg fogja vajon enni mondjuk a trac LDAPAuthStore-ja vagy az apache
ldap auth modulja? :) En ketlem, de bevallom, nem neztem utana kifejezetten.

Post by Kovács Attila
Persze sok felhasználónál az useridek helyett célszerű csoportokat
használni gondolom.

Ahhoz viszont megint kell akkor a szolgaltatasok oldalan annak az
indirekcionak a tamogatasa, hogy a member-ekre kulon csinal egy lookupot, es
ha az is valami group, akkor annak a tagjait is megvizsgalja - szoval ez igy
elvileg mukodhetne, de a gyakorlatban szerintem nem mukodik, mert az
autentikaciot vegzo programok nem tudjak, hogy ezt kene csinalniuk.

Post by Kovács Attila
Megvallom őszintén hogy én az alkalmazás jogosultságokat inkább rdbms-ben
tárolnám, de akinek kalapács van a kezében, az mindent szögnek lát :).

Talan nem volt vilagos az eredeti kerdesbol, de elsosorban letezo
eszkozokkel jol integralodo megoldas erdekel, nem nullarol akarom
megvalositani. :) Biztos szamos elonye lenne egy olyan megoldasnak, ahol az
auth ldap alapjan tortenik, a csoportok pedig rdbms-bol jonnek, de en inkabb
nem cifraznam most. :)

Guy

[Kovács Attila]

Post by KORN Andras
Es ezt meg fogja vajon enni mondjuk a trac LDAPAuthStore-ja vagy az apache
ldap auth modulja? :) En ketlem, de bevallom, nem neztem utana kifejezetten.

Pont ezt nem, de valami hasonlót igen:
http://trac-hacks.org/wiki/LdapPlugin#Groupmanagement

The /LDAP group/ setting would add <http://trac-hacks.org/wiki/add> a
new member attribute to the group entry

# developers, groups, example.org
dn: cn=developers,ou=groups,dc=example.org
objectClass: groupOfNames
objectClass: tracgroup
member: uid=eblot,ou=people,dc=example.org

Gondolom apachenál is hasonló lehet a dolog.
Örülök neki hogy a valóság igazodik az elképzelésemhez :))))))).

[Kovács Attila]

Post by KORN Andras
Es ezt meg fogja vajon enni mondjuk a trac LDAPAuthStore-ja vagy az apache
ldap auth modulja? :) En ketlem, de bevallom, nem neztem utana kifejezetten.

Pont ezt nem, de valami hasonlót igen:
http://trac-hacks.org/wiki/LdapPlugin#Groupmanagement

The /LDAP group/ setting would add <http://trac-hacks.org/wiki/add> a
new member attribute to the group entry

# developers, groups, example.org
dn: cn=developers,ou=groups,dc=example.org
objectClass: groupOfNames
objectClass: tracgroup
member: uid=eblot,ou=people,dc=example.org

Gondolom apachenál is hasonló lehet a dolog.
Örülök neki hogy a valóság igazodik az elképzelésemhez :))))))).

[Szijártó Zoltán]

Post by KORN Andras
Sziasztok,
adott egy ceg, par tucat alkalmazottal; ezek szepen benne vannak egy
LDAP-faban, ou=People,dc=cegnev,dc=tld alatt, posixAccount es shadowAccount
objectclass-szal. Eddig jo.
Van egy csomo szolgaltatas, ami az LDAPbol authol (kismillio host ssh-val,
courier imap, webes ezazamaz). Eddig is jo.
Viszont van egy partnerceg, szinten jopar tucat alkalmazottal, es az o
usereik is kellene hogy hasznalhassanak bizonyos webes szolgaltatasokat,
sot, esetleg bizonyos hostokra lephessenek is be ssh-val, de csak azokra.
Felolem lehet uidNumberuk a partnerusereknek is, de nem baj az se, ha nincs
(az ssh-hoz persze nyilvan kell, de a webes cuccokhoz nem).
Hogyan erdemes ezt csinalni es miert ugy?
Nyilvan tobbfele megoldast is el tudok kepzelni (pl. uj reszfaba rakom a
partnerceg usereit es ahol kell, feljebb rakom a search base-t; vagy valami
csoport-alapu megoldas; stb.). Sajnos ezeknek a hosszu tavu
hasznalhatosagat/implikacioit nem latom at, ugyhogy ha valaki mar megoldott
ilyesmit valahogy, az legyszi irja meg, hogy csinalta, es hogy ma is ugy
csinalna-e. :)
Koszi
Guy

Első nekifutásnak: Groupba kulon ezek az emberek es a groupot vedd
azonositasi alapnak a weben is , ssh ban is.
Üdv
Szijártó Zoltán

[Gabor HALASZ]

Post by KORN Andras
Sziasztok,
adott egy ceg, par tucat alkalmazottal; ezek szepen benne vannak egy
LDAP-faban, ou=People,dc=cegnev,dc=tld alatt, posixAccount es shadowAccount
objectclass-szal. Eddig jo.
Van egy csomo szolgaltatas, ami az LDAPbol authol (kismillio host ssh-val,
courier imap, webes ezazamaz). Eddig is jo.
Viszont van egy partnerceg, szinten jopar tucat alkalmazottal, es az o
usereik is kellene hogy hasznalhassanak bizonyos webes szolgaltatasokat,
sot, esetleg bizonyos hostokra lephessenek is be ssh-val, de csak azokra.

Erre volt jo a nememlekszemanevere (hatha valaki), host/service alaku
attributumokat lehetett vele beallitani, de par eve kinyirta valami
nagyonokos, igy marad a csoportbaszervezes vagy az osszetett queryk,
amik objectclasshoz illeszkednek (uid & posixAccount, stb)