[ vujkev @ 21.02.2008. 11:00 ] @
Trenutno pravim aplikaciju gde je potrebno da korisniku koji radi na programu ograničim pristup nekim funkcijama, pregledima i sl.

Primera radi imate aplikaciju u kojoj su osobe grupisane u nekoliko grupa. Potrebno je da osobi koja radi sa programom ogranicite pristup nekim grupama (naravno u zavisnosti od korisničkog imena i šifre), pa čak i određenim osobama u grupi ukoliko ne sme da se ograniči pristup celoj grupi, da ograničite promenu podataka, brisanje i sl.

Interesuje me kako bi vi ovo napravili.

Pozdrav
[ mmix @ 21.02.2008. 12:38 ] @
Fundamentalno zavisi od toga da li radis WinForms ili asp.net aplikaciju... KOja je?
[ vujkev @ 21.02.2008. 13:54 ] @
..ups, WinForms
[ mmix @ 21.02.2008. 17:14 ] @
najbolje je da koristis security credentials ulogovanog korisnika, a za kontrolu pristupa mozes koristiti workgroup ili domenske grupe.

Code:

using System.Threading;
using System.Security.Principal;

    class Program
    {
        static void Main(string[] args)
        {
            // OVO JE VAZNO pokrenuti na pocetku, ukljucuje podrsku za Windows .NET Principale
            AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

            WindowsIdentity user = (WindowsIdentity)Thread.CurrentPrincipal.Identity;
            Console.WriteLine("Username: {0}", user.Name);
            Console.WriteLine("User is administrator?: {0}", Thread.CurrentPrincipal.IsInRole("Administrators"));
            foreach (IdentityReference grp in user.Groups) 
                Console.WriteLine("Belongs to group: {0}", grp.Translate(typeof(NTAccount)).Value);
            Console.ReadLine();

        }
    }


daje sledeci izlaz:

Code:

Username: SOLARIS\Administrator
User is administrator?: True
Belongs to group: SOLARIS\Domain Users
Belongs to group: Everyone
Belongs to group: BUILTIN\Administrators
Belongs to group: BUILTIN\Users
Belongs to group: BUILTIN\Pre-Windows 2000 Compatible Access
Belongs to group: NT AUTHORITY\INTERACTIVE
Belongs to group: NT AUTHORITY\Authenticated Users
Belongs to group: NT AUTHORITY\This Organization
Belongs to group: LOCAL
Belongs to group: SOLARIS\Group Policy Creator Owners
Belongs to group: SOLARIS\Domain Admins
Belongs to group: SOLARIS\Enterprise Admins
Belongs to group: SOLARIS\Schema Admins
Belongs to group: SOLARIS\Denied RODC Password Replication Group



sa Principal.IsInRole() proveravas da li pripada odredjenoj grupi, a uz pomoc gornjeg koda mozes da proveris kojim sve grupama pripada. Ako ne pozoves Translate(NTAccount) onda grp.Value bude domenski SID grupe.

Sad ti od ovog napravi siguronosnu shemu kakvu hoces. Ono sto ti .NET moze jos pomoci je Code Security, bilo deklarativno, bilo imperativno.

Npr, sledeci metod, deklarativno se zahteva da pozivar pripada grupi administratora, a unutar se imperativno zahteva da korisnikov username bude "perica", u slucaju neispunjenja tih uslova pada SecurityException

Code:

        [PrincipalPermissionAttribute(SecurityAction.Demand, Role = "Administrators")]
        static void ProtectedMethod()
        {
            PrincipalPermission perm = new PrincipalPermission("perica", null);
            perm.Demand(); // ovde puca ako user nije perica
        }

[ Shadowed @ 21.02.2008. 19:06 ] @
Usput da pitam, je l' moguce koristiti neki deo framework-a za ACL odredjivanje pristupa delovima aplikacije/podataka ali sa sopstvenim user sistemom, ne Windows-ovim? Ovo me interesuje za obe varijante, i za asp.net i za winforms.
Ja trenutno implementiram svoju verziju acl-a sa default membership provajderom i sql bazom, ali me interesuje postoji li nesto gotovo (ili bar gotovije ).
[ mmix @ 21.02.2008. 19:41 ] @
Naravno da moze, Thread.CurrentPrincipal moze da primi bilo koji objekat koji implementira IPrincipal interfejs, samo napravis svoju implementaciju IPrincipal i IIdentity interfejsa (npr nasledjujuci GenericPrincipal i GenericIdentity). Jedino sto si onda sam i zaduzen da kreiras instancu principala i postavis je u Thread.CurrentPrincipal. Dok god isInRole vraca "nesto" moze da se koristi "fabricki" role based security.
[ Shadowed @ 27.02.2008. 13:46 ] @
Zapravo, ono sto mi je trebalo je namespace System.Security.AccessControl. Tj. da acl klase odatle koristim ne za fajlove i sl. vec za neke svoje objekte. To doduse, ne iskljucuje da bi mi trebalo i to sto si pomenuo (nisam jos proucio dovoljno).
Medjutim, deluje mi to malo previse komplikovano a vec sam zamislio kako da ostvarim potrebnu funkcionalnost sa sve cuvanjem i odredjivanjem effective permission (kada postoji vise acl-ova za user-a i/ili njegove roles).
[ mmix @ 27.02.2008. 18:04 ] @
Ne iskljucuje, zapravo neces moci da je izbegnes. Kad zavrsis sa ACE i ACL objektima i definises svoj security framework moraces da uradis "autorizacioni" deo koji te tvoje ACL liste vezuje za security identity. Poimence, kad budes dosao do tacke da koristis AccessRule instance trebace ti IdentityReference klasa iz System.Security.Principal, a isti je vezan za Identity/Principal implementaciju o kojoj je pisano gore.
[ Shadowed @ 27.02.2008. 20:56 ] @
Lepota :) Fino sam ja to resio sa 4 tabele i nekoliko upita/stored procedure-a ;)

(Videcu koliko ce fino biti kasnije ;])