LightSwitch – Autentifikacija i Autorizacija

U prethodnom blog postu na temu Visual Studio LightSwitch su pokazane mogućnosti rada sa upitima.

Ostale teme u seriji za LightSwitch:

Pod autentifikacijom i autorizacijom generalno mislim na kontrolu pristupa u okviru LightSwitch aplikacije.

Kada smo završili kreiranje LightSwitch aplikacije, poslednji korak prije puštanja u produkciju (izdavanje) potrebno je da razmislimo o koracima za kontrolu pristupa određenim funkcionalnostima u okviru aplikacije ili generalno govoreći o sigurnosti u okviru aplikacije (Application Seccurity).

Da bi to mogli da odradimo, prvo je potrebno da imamo sistem koji će nam reći ko koristi našu aplikaciju, sa kojim kredencijalima (User Name, Password), kojoj grupi korisnika pripada osoba koja koristi aplikaciju a potom i da iskoristimo tu činjenicu i da omogućimo u okviru poslovne logike da li korisnik može ili ne može da koristi određenu funkcionalnost.

LS omogućava da se kontrola sigurnosti izvede na prilično jednostavan način. LS aplikacija se logički sastoji iz tri nivoa:

  • Prezentacioni nivo (Presentation Tier)
  • Logički nivo (Logical Tier)
  • Nivo podataka (Storage Tier)

Prilikom implementacije sistema sigurnosti potrebno je da razmislimo o primjeni sigurnosti na svakom od ova tri nivoa. Kontrolu pristupa možemo ostvariti na dva načina:

  • Autentifikacija
  • Autorizacija

Autentifikacija

LS putem Autentifikacije zna ko je korisnik koji koristi aplikaciju. Podržani tipovi autentifikacije su:

  • Windows autentifikacija
  • Forms autentifikacija
  • Bez autentifikacije
    Ove tipove možemo podesiti iz App properties/Access Control tab

Permissions

Windows autentifikacija se koristi u Intranet okruženju sa domenom kada smo sigurni da su svi korisnici oni koji imaju privilegije da pristupaju domenu te smo sigurni da je korisnik koji koristi računar isti onaj koji će koristiti i LightSwitch aplikaciju. U ovom slučaju se ne pojavljuje Login dijalog i aplikacija ne čuva nikakve informacije o korisnicima (User Name, Password).

S druge strane Forms autentifikacija koristi Login screen (Login Name, Password) kako bi identifikovala korisnika koji želi da koristi aplikaciju. Ovaj tip se koristi u Internet okruženju ili Intranet okruženju gdje ne postoji postavljen domen.
Forms autentifikacija zahtijeva da se korisnik prvo doda u sistem kako bi ga on mogao koristiti.
Windows autentifikacija može da radi isto kao Forms autentifikacija ali može i da se odabere opcija da sistem može koristiti bilo koji korisnik koji ima privilegije da se loguje na domen.
Napomena: Ako postoji bilo koji dio aplikacije koji zahtjeva određene privilegije napravljene u kodu, Windows User neće moći koristiti funkcionalnost dok ne bude eksplicitno dodat kao User.

Za određene vrste aplikacija dovoljno je da samo znamo da je korisnik koji koristi aplikaciju onaj korisnik kome možemo da vjerujemo jer ima pristup operativnom sistemu kroz sistem Windows autetifikacije.
U tom slučaju smo završili sa kontrolom pristupa našoj aplikaciji bez potrebe za dodatnim programiranjem u okviru aplikacije. Potrebno je samo još razmisliti o podešavanju IIS na serveru koji hostuje našu aplikaciju.

Ali u svakom drugom slučaju, kada je potrebno da u apliakciji imamo detaljniju kontrolu nad akcijama (određeni korisnici mogu da vide samo podatke koje su oni unijeli, određena grupa korisnika ne treba da ima pristup određenim ekranima, korisnik ne treba da vidi određene podatke na ekranu, korisnik ne treba da pokrene određeno dugme za štampu i slično). Za sve ovakve situacije potreban nam je sistem kontrole pristupa putem autorizacije.

Autorizacija

LightSwitch omogućava autorizaciju zasnovanu na postavljanju dozvola za definisanje poslovnih pravila (permissions).
Definišemo permisije u okviru App Designer-a (Properties/Access Control). Nakon definisanja permisija, u kodu u okviru aplikacije možemo koristiti provjeru da li postojeći korisnik ima određenu dozvolu. Moguće je kreirati permisije na tri nivoa:

  • Prezentacionom nivou (na nivou ekrana ili kontrole u okviru ekrana)
  • Logičkom nivou (na nivou entiteta i upita)
  • Nivou podataka (na nivou baze podataka)

LightSwitch omogućava testiranje autorizacije pomoću testnog korisnika TestUser u Debug režimu. Da bi omogućili da korisnik ima određenu dozvolu u okviru procesa razvoja aplikacije, koristićemo opciju Granted for Debug.

Implementacija autorizacije je moguće na dva mjesta:
-U toku izrade aplikacije pisanjem provjera u kodu da li korisnik ima određenu dozvolu za određenu akciju
-Ili definisanjem pravila u okviru Security Administration u toku rada Publish-ovane aplikacije

GDJE KORISTITI KONTROLU PRISTUPA?
1. U toku izrade aplikacije pisanjem provjera u kodu da li korisnik ima određenu dozvolu za određenu akciju

Na svakom od narednih nivoa je moguće ugraditi provjere pristupa određenim funkcionalnostima LightSwitch aplikacije:

Logički nivo:
– Entiteti
– Upiti
Prezentacioni nivo:
– Ekran
– Komanda na ekranu
Nivo podataka

Logički nivo
Na logičkom nivou za entitete je moguće koristiti sledeće provjere: CanDelete, CanInsert, CanRead, CanUpdate:

EntityAccessControl

LS je obezbijedio API za provjeru User.HasPermission. Postoji veza između odrešenih privilegaija. Na primjer, ako korisnik nema privilegije da čita podatke-Customer_CanRead, onda automatski neće moći da odradi i Update i Delete.
Kao primjer ćemo kreirati permisiju za mogućnost dodavanja novih podataka u entitet Customer:

partial void Customers_CanInsert(ref bool result)
{
  result = this.Application.User.HasPermission(Permissions.CanInsertCustomer);
}

Naredni primjer je kreiranje permisije za provjeru brisanja podataka u entitetu Customer:

partial void Customers_CanDelete(ref bool result)
{
  result = this.Application.User.HasPermission(Permissions.CanDeleteCustomer);
}

Ukoliko korisnik nema pravo brisanja podataka, ova izmjena se prenosi i na prezentacioni nivo zahvaljujući LightSwitch-u. Na ekranu će dugme Delete biti neaktivno:

DisableDelete

LS automatski za svaki entitet generiše tri različita upita. Za upite je moguće kontrolisati sledeće (Query Access Control Methods) :
– <Entity>_All_CanExecute (vraća sve instance entiteta)
– <Entity>_Single_CanExecute (vraća instancu po ključu)
– <Entity>_SingleOrDefault_CanExecute (vraća instancu po ključu)
Kako se novi upiti mogu kreirati na osnovu drugih upita, onda i upiti koji nasleđuju druge upite preuzimaju kontrolu postavljenu u osnovnom upitu.
Single i SingleOrDefault upiti su kreirani od All query, tako da kontorla “All” upita takođe osigurava i pojedinačne upite osim ako nije posebno specificirana kontrola za pojedinačne upite.

Prezentacioni nivo
Nakon sređivanja kontrole pristupa na nivou entiteta potrebno je srediti pristup i na prezentacionom sloju. Moguće su dvije metode za kontrolu pristupa, na nivou ekrana ili komande:
1. <ScreenName>_CanRun
2. <CommandName>_CanExecute

Ukoliko želimo kontrolu pokretanja ekrana kreirat ćemo permisiju za postojeći ekran SearchCustomers:

partial void SearchCustomers_CanRun(ref bool result)
{
  result = this.User.HasPermission(Permissions.CanViewCustomer);
}

Ukoliko korisnik nema privilegije da vidi ovaj ekran (SearchCustomers), link za pokretanje ekrana se neće pojaviti u navigacionom meniju.

Na nivou komande je kontrola da ako kreiramo neko dugme, koje će pokrenuti određenu funkcionalnost, možemo kontrolisati kontrolu nad izvršavanjem dugmeta pomoću metode CanExecute.
Ostale metode koje se mogu koristiti na nivou ekrana su vezani za kontrole kao što su dugmad i link. Sa ovim metodama možemo kontrolisati:

  • <ScreenControl>.IsEnabled
  • <ScreenControl>.IsReadOnly
  • <ScreenControl>.IsVisible

Primjer korištenja na nivou kontrole bi bio kada bi željeli da postavimo određenu kolonu u SearchCustomers ekranu za sve redove na Not Enabled. Privilegiju ćemo dodati kada je ekran kreiran:

partial void SearchCustomers_Created()
{
  this.FindControlInCollection("Name", this.Customers.SelectedItem).IsEnabled = false;
}

Autorizacija na nivou ekrana ne štiti mogućnost pristupa podacima na logičkom nivou već samo kontroliše načine pristupa tim podacima. Dakle, moguće je preskočiti ove kontrole na nivou ekrana i pristupiti logičkom nivou te je stoga veoma bitno odraditi kontrolu pristupa na logičkom nivou.

Nivo podataka
Nivo podataka predstavlja bazu podataka gdje su smješteni podaci.
Ovu kontrolu obezbjeđujemo tokom procesa Publish-ovanja aplikacije određivanjem korisnika koji će imati privilegije nad samom bazom podataka.

GDJE KORISTITI KONTROLU PRISTUPA?
2. Definisanjem pravila u okviru Security Administration u toku rada Publish-ovane aplikacije.

Security Administration opcija se pojavljuje kada se odradi Publish aplikacije i sastoji se iz dvije stavke menija: Roles i Users. Ovim stavkama menija je moguće pristupiti sa privilegijom Security Administrator-a koji se definiše prilikom Publish procesa.  Uloge (Roles) definišemo preko ekrana Roles, te za uloge definišemo privilegije (Permissions):

Roles

Korisnike (Users) i pripadnost određenoj ulozi (Roles) definišemo preko ekrana Users:

Users

Informacije o trenutnom korisniku koji je ulogovan u aplikaciju kada se pokrene aplikacija se nalazi u donjem desnom uglu:

ChangePassword

Ukoliko to korisnik želi, može promjeniti šifru (Password). A ako je kojim slučajem zaboravio svoju šifru, to u svakom momentu može učiniti Application Administrator preko ekrana Users tako što će unijeti novu šifru u polje Password.

Zaključak

Sigurnost u LightSwitch-u je zasnovana na ASP.NET Security tj. koristi se Membership, Role, i Profile provider API-ji definisani od strane ASP.NET.

LightSwitch omogućava da se na veoma jednostavan način implementira kontrola pristupa aplikaciji preko autentifikacije. Kada je potrebna kontrola pristupa na nižem nivou, sa više detalja, onda možemo koristiti autorizaciju kao mehanizam kontrole pristupa na logičkom i prezentacionom nivou. I na kraju, podešavanjima na nivou IIS zaokružujemo cjelinu aspekta sigurnosti podržanoj u aplikacijama kreiranim putem Microsoft Visual Studio LightSwitch-a.

About Spaso Lazarevic

Spaso Lazarevic is Senior Software Developer working with Microsoft technologies. Leader of .NET User Group Bijeljina, speaker at Microsoft events, writter and blogger. Microsoft MVP for Visual C#.
This entry was posted in Programming and tagged , , , . Bookmark the permalink.

One Response to LightSwitch – Autentifikacija i Autorizacija

  1. Bogi says:

    Kako se administriraju novi korisnici na SQL?
    Aplikacija je Desktop i napravljena je nova SQL baza tokom deploy-a. Kada dodam nove korisnike koji nemaju login na SQL i dodelim im aplikativna prava, ali dobiju poruku o grešci. Koje su potrebne privilegije na SQL-u?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s