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
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Do witches run spell checkers?
_______________________________________________
linux++ mailing list
lin...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux++
Kovács Attila
> Hogyan erdemes ezt csinalni es miert ugy?
>
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 ;).
--
k-atti-
KORN Andras
On Wed, Mar 25, 2009 at 02:43:56PM +0100, Kovács Attila wrote:
> KORN Andras írta:
> > 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
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
A gargarizalas remek modja annak, hogy megallapitsuk, nem szivarog-e a nyakunk.
Szijártó Zoltán
> 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
>
>
azonositasi alapnak a weben is , ssh ban is.
Üdv
Szijártó Zoltán
Kovács Attila
KORN Andras írta:
> 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
>
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 :).
--
k-atti-
Gabor HALASZ
KORN Andras wrote:
> 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)
--
Gabor HALASZ <hala...@freemail.hu>
KORN Andras
On Wed, Mar 25, 2009 at 03:10:29PM +0100, Kovács Attila wrote:
> KORN Andras írta:
> > 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?
> > 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.
> 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
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Minel tavolabbrol nezzuk, annal messzebbrol latjuk.
Kovács Attila
KORN Andras írta:
> 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 :).
--
k-atti-
Kovács Attila
KORN Andras írta:
> De tenyleg, szerinted milyen objectclass-szal kellene megjelennie mondjuk
> egy trac-nek vagy egy subversion szervernek az LDAPban, es aztan hogyan
> hasznalnad hitelesitesre/engedelyezesre?
>
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 :).
--
k-atti-
KORN Andras
On Wed, Mar 25, 2009 at 05:00:11PM +0100, Kovács Attila wrote:
> KORN Andras írta:
> > 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.
> 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.
> 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
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Alone in a bank at night is a pleasant experience.
Kovács Attila
KORN Andras írta:
> 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.
>
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 :))))))).
--
k-atti-
Kovács Attila
KORN Andras írta:
> 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.
>
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 :))))))).
--
k-atti-
_______________________________________________