Systém centrální správy uživatelů

14.3.2010 00:34 | Přečteno: 1571× | Linux |

Většinou je zvykem mít uložené větší množství uživatelů v LDAP. Já mám uživatele uložené v tabulce v MySQL databázi, kterou si mohu jakkoli upravovat, měnit strukturu apod. Prostě mi to přijde lepší než LDAP(jistě, je to věc názoru). Navrhl jsem si pro sebe takový mechanismus pro centrální databázi uživatelů. Pomocí této databáze se může uživatel přihlásit do linuxu, mailu k ftp serveru apod.

Celý mechanismus spočívá v tom, že mám jednu tabulku:

tabulka: username password password_sha password.. ftp_quota ftp...

V této tabulce jsou všichni uživatelé, jejich hesla a hlavně nastavení všech služeb které jsou do tohoto přihlašování integrovány.

Každá služba si pro vlastní potřebu vytvoří view na tuto tabulku a vezme si vše co potřebuje.

Ačkoliv takto může vzniknout docela velká tabulka, je to o dost rychlejší než mít zvlášť tabulku pro uživatele + konfiguraci pro jednotlivé služby a to pak spojovat pomocí username.

Výhoda takové tabulky je zřejmá: uživatel může mít kolik hesel chce(stačí vytvořit vhodné pohledy) a hlavně view nad jednou tabulkou je updatovatelný, proto koncové služby nemusí vůbec tušit a vnitřní struktuře databáze a mohou si klidně do pohledu zapisovat.

Musím říct, že se mi daný systém velice osvědčil a zrovna pro něj dodělávám administratorské rozhraní v php pro editaci uživatelů: každá služba má nějaký seznam pravidel pomocí kterých se uživatel zobrazuje a upravuje - je to vlastně plugin. Pokud chci upravovat nastavení služby mail vytvořím pouze plugin mail.php a ten se automaticky zaintegruje do celého prostředí.

A proč to sem píšu? Docela by mě zajímalo jestli by měl někdo zájem o to administrátorské rozhraní + schéma db, mohl bych to zveřejnit třeba pod licencí GPL. (To administrátorské rozhraní bude je docela rozsáhlá aplikace)

Drobnou nevýhodou celého řešení je nutnost mít databázi uživatelů + databáze ostatních služeb na jednom serveru(i když to taky není úplně nutnost, protože každý plugin může mít vlastní připojení do databáze).

Takže pokud někdo plánujete podobné řešení databáze uživatelů a máte zájem o tenhle "projekt", napište mi určitě sem do blogu.        

Komentáře

[MaFy]

Ja se hlasim Zrovna pracuji na necem podobnem a ocenil bych neco na porovnani a pripadne vylepseni meho reseni...

[s0]

Zní to zajímavě. Každopádně mám otázky, protože je mi to trochu nejasné:

- jak řešíš změnu hesel uživatelem?

- jak řešíš pčidání nové služby? Přidáním dalšího sloupce do té megatabule?

- není ta tabulka příliš "řídká"? Tj. není hodně hodnot s hesly prázdných (uživatel nepoužívá třeba FTP apod.)?

- máš nějaké benchmarky pro tvrzení "Ačkoliv takto může vzniknout docela velká tabulka, je to o dost rychlejší než mít zvlášť tabulku pro uživatele + konfiguraci pro jednotlivé služby a to pak spojovat pomocí username." Protože tohle mi přijde zvláštní.

- jak si každá služba view vytvoří?

[moira]

máš nějaké benchmarky pro tvrzení "Ačkoliv takto může vzniknout docela velká tabulka, je to o dost rychlejší než mít zvlášť tabulku pro uživatele + konfiguraci pro jednotlivé služby a to pak spojovat pomocí username." Protože tohle mi přijde zvláštní.

Autor asi myslel o dost méně pracnější. S rychlostí to imho nemá co dělat, leda tak s rychlostí bastlení.

[vaclav.x]

Změna hesla je centralizovaná přes webové rozhraní. Nyní je jedno heslo pro všechny služby, možnost přidat si zvláštní heslo pro každou službu. Přidávání sloupců a dělání pohledů řeším ručně zásahem do db(ty služby se nemění tak rychle aby se mi vyplatilo zahrnout to do toho administračního rozhraní). A některé hodnoty jsou null, nicméně mám to dělané tak, že i když uživatel službu nepoužívá, má automaticky předdefinováné její nastavení(uid,gid,homedir...), tabulka je sice větší, ale pak je přehlednější a rychlejší správa uživatelů. Benchmarky vskutku nemám, je to spíš můj úsudek, že select na jedny tabulce s vhodnými indexy je rychlejší než selecl na více tabulkách.

[Filip Jirsák]

Benchmarky vskutku nemám, je to spíš můj úsudek, že select na jedny tabulce s vhodnými indexy je rychlejší než selecl na více tabulkách.

Myslím, že za ty desítky let vývoje relačních databází by se na to už přišlo, že jsou relační databáze nesmysl a je lepší vše nacpat do jedné tabulky. Stačí si uvědomit, že u řídké tabulky se musí z disku načíst mnohem víc dat (i ty prázdné nebo nezajímavé hodnoty, které nepotřebuju), a načítání z disku je ta nejdražší operace.

[krotitelODS]

to co jste napsal je od zacatku do konce uplny nesmysl.

[Filip Jirsák]

Tak proč se tedy dodnes používají relační databáze, když je prý výhodnější nacpat to všechno do jedné tabulky? A od kdy platí, že čím víc dat se z disku přečte, tím rychlejší to čtení je?

[Zdeněk Štěpánek]

Nesmysl je predevsim to, ze relacni databaze jsou nesmysl.

[Filip Jirsák]

To ale netvrdím já, ale autor blogu – já jsem se mu to jen snažil vyvrátit.

[Zdeněk Štěpánek]

Aha, faux-pas... Pri rychlocteni jsem si nevsiml slovicka "by" - zcela uplne meni vyznam tve vety.

Zdenek

[pavlix]

A česky? (Nebo jakýmkoli srozumitelným jazykem.)

[msk]

... co je prave v pripade tabulky urcenej na takyto ucel uplne irelevantne a nestoji to za dalsi cas straveny vyvojom a vrstvenim roznych tabuli. Okrem toho, kolko to bude realne dat pre +- 200 userov a 10 sluzieb? 20kB?

Mna to riesenie rozhodne zaujima. Momentalne to nevyuzijem, ale uz som sa dostal par krat do stavu, ze som to potreboval vyriesit a LDAP mi moja hlava proste nebola schopna pobrat ani na piaty pokus.

[xkucf03]

nestoji to za dalsi cas straveny vyvojom a vrstvenim roznych tabuli

Uznávám, že výkon zde asi není tak důležitý, ale udělat kvalitní návrh takovéto DB nezabere až tolik času a hlavně to hodně práce ušetří v budoucnu, při rozvoji aplikace, úpravách. Normální formy a další doporučení pro návrh databází nejsou jen akademické bláboly, má to svůj smysl. Efekt je např. v tom, že při přidání další služby prostě jen přidám záznam do číselníku služeb (DML operace) a nebudu musel upravovat tabulky (DDL operace) ani aplikaci – což v případě, kdy je vše namaštěné v jedné tabulce, musím.

[msk]

To je pravda.

[s0]

ok, dík

[RoboShim]

Chapu to dobre, ze jsis naprogramoval vlastni jednoduchy LDAP? Proc to, kdyz LDAP uz existuje a je urcite vic podporovany nez ten tvuj system?

[Heron]

Nemohu mluvit za autora, ale mě se tento koncept líbí daleko více než LDAP. Přiznám, je to značně ovlivněno mým kamarádstvím se SQL DB a nepřátelstvím k LDAP (do teď nepochopil jeho smysl, v nasazení které vídám je opravdu jednodušší tabulka, klidně i v textovém souboru).

Asi bych to neřešil jednou megatabulkou, to však půjde snadno změnit díky použití pohledů.

[vaclav.x]

Také LDAP moc nemusím. Nebránil bych se ale jeho nasazení, kdyby ho všechny služby uměly. Já jsem takhle integroval přihlašování i do všech možných "neredakčních systémů" apod. Dokonce to chci zkusit používat pro ověřování sambou(ta ačkoliv přímo mysql nepodporuje, tak podle slov autora toho externího pluginu by to mělo být funkční). Neříkám že je můj návrh dokonalý, neživým se navrhováním db, ale zkoušel jsem už hodně schémat a tohle mi přijde nejjednodušší a velice dobře rozšiřitelné.

[vaclav.x]

Ještě k tomu schématu: tady je hlavně problém s tím, když daná aplikace/služba potřebuje záznamy upravovat a já jí podstrčím jen view s omezenými právy. Pokud je ten view na jednu tabulku tak není problém, ale view nad více tabulkama už není updatovatelný,

[krotitelODS]

nenechte se znejistit tou 'jednou' tabulkou. Na to co delate je to naprosto ok, naopak, rozdelit to do vice by byl relacni fetisismus. A to, ze je rada udaju NULL vas menusi vubec zlobit a uz vubec nemusite delat nejake benchmarky. Ja bych sice misto NULL pouzil char s maximalni delkou a oblozil to blankama, ale na tech par mikrosekund uz neprijde.

[Vskutečnosti Saýc]

Na to by byla hezka dokumentova databaze.

[Karel Benák]

Vynález kola po X-té ... aneb zase budu ve výsledku osočen z toho, že jsem si na LDAPu postavil diplomku

Protokol LDAP slouží právě pro "centralizovanou" správu uživatelů. To že autor nechápe jeho princip není problémem LDAPu, ale autora. Zopakuju to určitě ještě několikrát, ale prostě to zopakuju. Jednou z vlastností LDAPu je STANDARDIZOVANÝ KOMUNIKAČNI PROTOKOL mezi klientem a serverem. Je to hodně důležité pochopit!!! Jde o to, že klient napsaný pomocí klientských knihoven OpenLDAP může komunikovat např. s Active Directory serverem (och, jak jsem si na tomhle serveru mohl dovolit zmínit se o produktu Microsoftu!), Novell eDirectory apod. Vyměníte OpenLDAP server za LDAP server od SUNu a vše běží. Vyměníte MySQL za PostgreSQL a ... jste u Heleny Vondráčkové Další velmi důležitou vlastností LDAPu je to, že má STANDARDIZOVANÁ SCHÉMATA, která pro hodně případů postačuje a aplikace, které umí s LDAPem pracovat, se jimi řídí. A snad jen poslední poznámky na závěr, ale pro autora možná velmi podstatné. Kdyby byl protokol LDAP nevyhovující, určitě by do něj firmy jako je Microsoft, Novell, IBM, HP, Oracle apod. neinvestovaly takové peníze, jaké do něj nainvestovaly. LDAP je důležitou součástí podnikových řešení, ale jejich architekturu musí navrhovat někdo, kdo má zkušenosti. LDAP lze poměrně obstojně integrovat s jinými databázemi, protože nemusí mít jako zdroj dat svoji integrovanou databázi, povětšinou založenou na BerkeleyDB, ale může používat SQL databázi. Takhle to má uděláno například Oracle u svého Oracle Internet Directory. Dalším řešením by bylo, naprogramovat si datovou pumpu, která by v určitou dobu tahala data z SQL databáze do LDAP serveru. Řešení je hodně, ale rozhodně bych LDAP nezatracoval pro jeho neznalost. Když se nad tím člověk zamyslí, dojde k tomu, že všechno spolu nějak souvisí ...

[Filip Jirsák]

Dá se v LDAPu nějak vyřešit, že lidé mohou mít různé e-mailové adresy nebo telefony, a chtějí k nim uvádět poznámky (např. e-mail do práce, soukromý mobil apod.)? Dá se nějak vyřešit to, abych měl uloženou pro každou službu jiný hash hesla (heslo je stejné, ale algoritmus hashe nebo sůl je pokaždé jiná)? Chtěl jsem na LDAPu řešit centrální databázi účtů a adresář, ale když si uvědomím, že bych tohle musel nějak obcházet (a ve výsledku tedy stejně nebudu mít standardizovaná schémata), vychází mi z toho databáze jako jednodušší řešení.

[Karel Benák]

Tady je potřeba si uvědomit, co vlastně potřebuju a co od toho očekávám. Pokud jsou potřeby značně variabilní, pak samozřejmě má smysl použít SQL databázi, ale proč nepoužít propagaci do LDAP záznamu a jeho standardizovaný přenosový protokol ... Faktem je, že v LDAPu by z toho asi bylo několik záznamů a musel by se podle něčeho vybrat ten správný záznam. U SQL bych si nadefinoval pomocí left joinu nějaký libový pohled a bylo by vymalováno ... Jak říkám, záleží na tom, co od systému chcete a kolik do toho chcete investovat času a peněz.

Váš zmíněný problém by se dal rozlousknout rozdělením do LDAP stromu a uvedením referencujícího záznamu, jiné řešení mě zatím nenapadá ...

[krotitelODS]

ja bych mel 2 poznamky, predem prohlasuji, ze si mi myslenka ldapu libi preve v tom vami popisovanem standardnim protokolu.

1. to ze nekdo investoval do nejakeho nastroje buhvikolik penez jeste neznamena, ze je to spravny nastroj, smysluplny nastroj apod. Tyto nesmyslne argumenty patri do ust politickych predaku, absolventu ekonomickych a managerskych skol a pracovniku obchodnich oddeleni. V zadnem pripade na technickem portalu, zde maji hovorit fakta.

2. To, ze ldap musi navrhovat nekdo se 'zkusenostmi' jak pisete je problem tohoto nastroje. Jestlize v nejake firme musi prijit doktor ved aby nastavil a 'navrhnul' opatreni, aby se mohlo cenralne prihlasit 50 uzivatelu, tak se neni co divit, ze nekdo 'vymysli to kolo'.

[xkucf03]

To, ze ldap musi navrhovat nekdo se 'zkusenostmi' jak pisete je problem tohoto nastroje.

Neřekl bych, že je potřeba mít o tolik víc znalostí než pro návrh kvalitního schématu relační databáze. Spíš bych řekl, že to bude naopak – u LDAPu tě vedou ty standardizovaná schémata (nejužitečnější vlastnost LDAPu), zatímco u návrhu schématu relační databáze autora většinou jen „selský rozum“, pocity jak by to „mělo vypadat“ (podle toho to pak dopadá) a v lepších případě zkušenosti a načtené teorie z knih. U LDAPu tam člověk vrzne ty struktury, které už vlastně dostal naservírované a nemá toho tolik co zkazit (jasně, třeba uspořádání toho stromu se dá zkazit, ale není tam taková volnost jako u relační DB).

Dřív jsem byl z LDAPu hodně nadšený, ale časem to vyprchalo. U jednodušších systémů je problém, že má člověk uživatele na jednom místě (LDAP) a ostatní data na jiném místě (např. SQL databáze) a mezi nimi nefunguje referenční integrita a záznamy je potřeba synchrozizovat. Také čím dál víc aplikací umí ověřování vůči SQL databázi, nejen vůči LDAPu. U složitých systémů se zase člověk nevyhne nějakému tomu IDM, takže pak zase není problém, aby aplikace měly svoje (relační) databáze uživatelů a IDM to všechno režíroval. LDAP se pak hodí hlavní pro nějakou tu prostřední kategorii (kdy ještě IDM není potřeba) a ta je celkem úzká. Asi nejzajímavější je mít data v relační DB a nastavit LDAP server tak, aby fungoval jako rozhraní k této SQL databázi pro aplikace, které LDAP potřebují – pak má člověk jak relační tak LDAPový přístup k uživatelům a data jsou na jednom místě.

[Karel Benák]

Souhlas, občas je LDAP jako kanón na vrabce. Když už jste nakousl IDM, jako jeden ze zdrojů dat samozřejmě podporuje LDAP. IDM využívá LDAP jako datasource, ale to může dělat i DNS server, DHCP server apod. Dokonce jsem měl jednu dobu fungující DNS, které si informace tahalo z LDAPu. A když už jsme u toho, musím uznat, že Active Directory je v tomhle směru poměrně pokrokové, protože si DHCP i DNS server mohou potřebná data tahat právě z Active Directory. K tomu ještě Kerberos ... Je to všechno pěkně v jednom, zatímco na UNIXech jsou to balíky oddělených serverů a přinutit je k nějaké integraci bývá občas problém. LDAP neslouží jen pro autentizaci uživatelů, to je jen jeho zjednodušené chápání. Lze do něj ukládat k jednotlivým záznamům fotografie uživatelů, čísla kanceláří, telefonní čísla, číslo přiděleného služebního auta, reference na nadřízeného apod.

Co se referenční integrity týče, s tou je problém, to připouštím a dokonce to i někde uvádím. Některé LDAP servery umožňují omezenou funkci referenční integrity. Ale co je hlavní, některé LDAP servery mají jako svůj hlavní datasource SQL databázi. Se synchronizací bývají problémy skoro vždy.

[xkucf03]

LDAP neslouží jen pro autentizaci uživatelů, to je jen jeho zjednodušené chápání. Lze do něj ukládat k jednotlivým záznamům fotografie uživatelů, čísla kanceláří, telefonní čísla, číslo přiděleného služebního auta, reference na nadřízeného apod.

Do LDAPu toho jde dát opravdu hodně, ale potíž je v tom, že se tam nevejde úplně všechno – není tak univerzální jako relační databáze, kterou nakonec člověk stejně má. A potom je část dat tam a část tam – proto mi přijde vhodnější použít LDAP jen na ověřování a všechny ostatní data mít jinde (datová vrstva aplikace nemusí pracovat se dvěma protokoly ale jen s jedním).

[Karel Benák]

Do relační databáze taky nejde nacpat úplně všechno. Hlavní výhoda LDAPu je právě ve standardizaci přenosového protokolu, základních schemat a hlavně provázanost s protokolem X.509 (podmnožina X.500), odtud právě to ověřování proti LDAPu. Když už tedy něco takového píšete, myslete prosím také na export dat ze SQL do LDAPu, který v podnikových řešeních hraje neviditelnou, ale podstatnou roli. Hodně lidí ho nemá rádo, protože ho nechápou. Je to o pojetí dat, zatímco v SQL jsou data ukládána relačně, v LDAPu je to holt hierarchická struktura.

[Karel Benák]

1.) Fakta ... X.500 byl moc složitý, tak se nadefinoval protokol LDAP jako jeho odlehčená varianta, resp. původně jako protokol, který uměl k X.500 přistupovat. Nad X.500 sedělo hodně chytrých hlav, jinak by telekomunikace nebyly tam kde jsou, ale ještě bychom používali světelná návěstidla. Protokol je to léty prověřený, skvělou implementací X.500 je Novellovská NDS. A jelikož to byl svého času zdroj jejich obživy, nelze předpokládat, že by se tolik let zabývali naprostou cypovinou To samé je s MS Active Directory, Oracle Internet Directory apod. Jsou to enterprise řešení a samozřejmě si za to nechají řádně zaplatit. Pokud chcete "ušetřit", musíte si vše splácat sami. To, že X.500 a LDAP není tak známý a prosazovaný je dáno jeho použitím. S HTTP, SMTP a POP3/IMAP4 pracují denně nejen v práci, ale i doma. Doma si mohou vyzkoušet různé věci, ale X.500/LDAP není tak jednoduché vyzkoušet, vyžaduje dost znalostí okolo, např. jak napojit na LDAP SMTP/POP3/IMAP server, jak na něj napojit VOICP server apod. Nojo, ale to najednou nejsme u LDAP protokolu, ale museli jsme obsáhnout protokoly další. U SQL databází to je jednoduché, tam se vymyslí většinou nějaká jednoduchá tabulka do které se všechno ukládá a pak se použije PAM.

2.) K návrhu SQL taky přistupuje někdo ze zkušenostmi, nebo by aspoň měl. Pravdou je, že 3.NF zvládne bez větších obtíží každý, na to stačí selský rozum, navrhnout adresářový strom je trošku větší kumšt, člověk musí hodně uvažovat dopředu. Problém je, že všechno souvisí se vším a je velká potíž najít někoho, kdo se v systémech a jejich návaznostech vyzná. Mě osobně to přijde, že je tu plno lidí, kteří znají velmi dobře nějaký svůj kus z IT a ostatní je moc nezajímá. Je to jejich specializace, v té si hoví a bojí se kouknout "za plot" svých znalostí. Systémy mají navrhovat systémoví architekti a ne nějaký správce. Když se systémový architekt snaží dělat admina, je to katastrofa. Když se admin snaží dělat architekta, je to podobné ...

Jen bych rád podotkl a uvedl na správnou míru, že rozhodně nejsem politik, odborářský předák nebo nedejbože obchodník či absolvent práv a ekonomky.

[Zdeněk Burda]

Pěkně jsi to napsal

Jen k těm architektům a adminům - jako optimální vidím, když architekt je/byl admin, ví potom co za hovadiny nemá vymýšlet

[Karel Benák]

Děkuju Ti náčelníku, že jsi se mě zastal :D

Systémový architekt s předchozími administrátorskými (nikoliv programátorskými, ty jsou opravdu jen volitelný doplněk) zkušenostmi je opravdová výhra, protože takový člověk skutečně ví nejenom jak to má navrhnout, ale jak píšeš, nevymýšlí zbytečné kraviny. Ale pokud se za navržené řešení nepostaví vedení firmy a zaměstnanci jej nevezmou za své ... jsi v šípku.

[vaclav.x]

Já jsem nehledal nějaké STANDARDIZOVANÉ ŘEŠENÍ. Moje řešení přináší mnohem víc volnosti.

[Zdeněk Štěpánek]

Me by to docela zajimalo.

Mam podobny problem v praci. Mam uzivatele v 5 (ne-li 6) databazich, vsechno ruzny systemy. Potrebuju propojit domenu (windows server), postu (mysql), CMS (mysql), linuxovy uzivatele (ted taha dost ujetym zpusobem uzivatele z posty a hesla z domeny). Jeste je tam jeden databazovy IS, ten ma DB nekde na woknech a je to blackbox, to by asi melo zustat samostatne.

Zdenek

[vaclav.x]

No windows server to asi nebude umet tahat z mysql.

[pepazdepa]

prinosy ldapu - v mailovym klientu si clovek muze prohlizet adresar, co je v LDAPu.

v LDAPu mame nekolik emailu, telefonu k jednomu cloveku, skupiny a mame plugin do pidginu, takze pohoda ;)

[pavlix]

Použití jiné databáze než LDAP naprosto chápu a nevím, čemu se tu kdo diví. LDAP je jen jedna z možností, je to jako kterýkoli jiný flame A versus B s mnoha příznivci/odpůrci na obou (všech) stranách.