Oprávnění uživatelů v desktopové aplikaci   zodpovězená otázka

VB.NET, Bezpečnost

Máte někdo zkušenosti s řešením oprávnění na úrovni desktopové aplikace? Mám tím na mysli věci typu "tento uživatel smí toto tisknout", či "tato skupina smí tento objekt modifikovat, ale ne smazat" atd.

Zatím jsem to řešil tak, že při přihlašování do aplikace byl uživatel ověřen proti databázi (MSSQL) a pak jsem mu přiděloval práva víceméně ručním způsobem. Systém přihlašování a oprávnění mám tedy zčásti založen na uživatelích a skupinách v MSSQL a zčásti to prasím. Toto mi přestává stačit a začíná přerůstat přes hlavu.

Nevíte o nějakém udělátku či mini-frameworku, který by s tím to pomohl? Tzn. jde mi o:

* možnost mít uživatele a skupiny

* možnost nastavovat práva uživatelům a skupinám

* možnost to nějak jednoduše spravovat

* možnost s tím nějak jednoduše pracovat z kódu

Díky za tipy!

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ověřen proti databázi? Proboha snad nepřipojujete klienty přímo do databáze! Běžně se to dělá tak, že do databáze se připojuje pouze aplikační server jedním jediným uživatelským účtem a autentizaci a autorizaci řeší aplikační server (který také spravuje tyto uživatelské účty a jejich oprávnění), říká se tomu třívrstvá architektura.

Dá to sice celkem práci takový mechanizmus vytvořit, ale .NET Framework k tomu má spoustu užitečných tříd a lze také využít autentizační mechanismy Windows (potom je ale řešení závislé na doméně a nastavení oprávnění v Active Directory).

nahlásit spamnahlásit spam 0 / 2 odpovědětodpovědět

Mrkněte na ADO.NET Data Services. Umí to zpřístupnit databázi (resp. tabulky, které si řeknete), umí to třídit, stránkovat na serveru (takže je to rychlé) a můžete si pro každý objekt specifikovat oprávnění, kdo co může.

Bohužel spousta těžkých klientů se připojuje rovnou do databáze, takhle to v mnoha firmách funguje.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Díky. Problém je, že moje oprávnění se netýkají pouze dat, ale obecně toho, co kdo smí či nesmí páchat se samotnou aplikací v GUI.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To se snad ale týká databáze a ne obecného řešení rolí v aplikaci? Když budete potřebovat řešit například který uživatel může tisknout a který ne, tak vám toto bude k ničemu.

nahlásit spamnahlásit spam -8 / 8 odpovědětodpovědět

Tak tohle ADO.NET Data Services pochopitelně neřeší, ale i tahle oprávnění budou pravděpodobně uložena v databázi, takže jde jen o to nad tím napsat pár tříd.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Tedy nechci se hádat, ale nezdá se mi, že WCF Data Services (dříve pojmenované ADO.NET Data Services) by se jakkoliv hodilo k řešení tohoto problému. Z toho co jsem vyčetl na MSDN se jedná o záležitost pro webové aplikace. Pokud budou oprávnění uložena v databázi, nevím jak by se k tomu hodil tento kolos, když by stačilo pár věcí ze System.Data.SqlClient.

nahlásit spamnahlásit spam -8 / 8 odpovědětodpovědět

Řeší to problém, kdy se těžcí klienti připojují přímo do databáze a oprávnění k jednotlivým tabulkám se řeší různými uživateli v SQL, jak tazatel popisuje.

WCF Data Services databázi zpřístupní přes Web Services nebo jiné protokoly, je to de facto řešení toho aplikačního serveru, o kterém jste psal výše. Mělo by to umět autentizaci a autorizaci jen na určité objekty.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No to je ale pořád jen o přístupu do databáze což neřeší zde diskutovaný problém.

nahlásit spamnahlásit spam -8 / 8 odpovědětodpovědět

Přesně tak, problém to neřeší. Já umím udělat tabulku, kde budou uživatelé a jejich práva popsána. Umím si z toho vytahat jednotlivá oprávnění a tak, ale pořád mi přijde, že vynalézám kolo. Přece mi neříkejte, že jsem první, kdo potřebuje pár objektů a metod ve smyslu

* addUser

* addRole

* addUserInRole

* isInRole

* ...

Tohle už přece musely psát stovky lidí přede mnou, tak bych se moc divil, kdyby to už někde nebylo.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jak už jsem zmiňoval, ve Frameworku jsou na to předpřipravené věci, ale implementovat si to musíte celé sám. Z vlastní zkušenosti mohu říct, že to vůbec není nic jednoduchého. Můžete začít třeba studiem třídy System.Security.Principal.GenericPrincipal, což bude asi základní kámen představující uživatelská oprávnění. Dále System.Security.Permissions.PrincipalPermission, což je objekt ověřující uživatelská oprávnění.

Jinak o žádném API třetích stran umožňujících nějak jednoduše řešit tuto problematiku nevím.

nahlásit spamnahlásit spam -7 / 7 odpovědětodpovědět

Připojuji klienty přímo do databáze! Říká se tomu dvouvrstvá architektura - proč se tomu proboha divíte? Správa uživatelů a rolí je sice pro mě problém, ale jako argument pro nasazení aplikačního serveru je to pro moje účely přece jen trochu overkill.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To, že se něčemu nějak říká (dvouvrstvá architektura kupříkladu), ještě neznamená, že je to vhodné a správné řešení.

Overkill to opravdu není, když už někde běží databázový server, není přece problém k němu přidat ještě jednu tenkou vrstvu, která řeší oprávnění a poskytuje data.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

TO byla odpověď na p. Linharta, ale odeslali jsme to skoro najednou ;-)

Pohled na to, jak já vnímám aplikační servery je dán Javou. Napsat něco tenoučkého mezi DB a aplikaci by samozřejmě řešením bylo ;-)

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.
  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback