Prijava korisnika u Silverlight aplikaciji, 1. dio
Svaka poslovna Silverlight aplikacija zahtjeva prijavu korisnika, i na web servisu provjeru korisničkih podataka da bi se utvrdile dozvole izvršavanja metoda. WCF i Silverlight nude out-of-box autentikaciju koja se uglavnom zasnima na ASP.NET Membership provideru (u najvećem broju primjera dostupnih na netu). On radi tako da pripremi SQL Server bazu sa svojim tablicama, te se brine oko svih aspekata upravljanja korisnicima (prijava novog, promjena lozinke, osobni podaci, role,...). Kako ja u svojim aplikacijama nikada ne koristim taj membership provider, nego imam svoju bazu, svoje objekte (i ORM za pristup bazi), uz to sam uvjek bio pre ljen napraviti vlasitit membership provider, ne mogu iskoristiti gotove kontrole za prijavu. WCF nudi nekoliko načina prijave korisnika, od kojih su dva opisana ovdje.
Zahtjevi su jednostavni: prijava preko Silverlight aplikacije, metode web servisa ne smiju zahtjevati user id ili slično (npr. GetProducts(int logedUserID), provjera korisničkih podataka mora se obavljati u mojoj klasi, sa mojom bazom, svaki request/respons na Silverlight mora biti „potpisan“ sa ID-em logiranog korisnika, bilo preko cookia ili drugačije.
U ovom tekstu je opisana implementacija autentikacije Silverlight (SL) aplikacije na web servise. Opisana su dva načina konfiguracije WCF servisa, gdje se korisnički podaci spremaju u SOAP poruci i Http Coookiu. Svaki od thi načina ima neke prednosti i mane, a neki od njih su:
| Custom WCF auth (SSL) | Forms auth (Cookie) | |
| Za | - Sav promet ekriptiran, preko SSLa (https), sigurnost velika, nema cookia za ukrasti | - Jednostavna konfiguracija - Mogućnost upotrebe gotovih atributa za WCF metode za presretanje prometa - Radi sa Cassini web serverom (VS2010), lakše debugiranje - TCP transport (višestruko brži od HTTP) |
| Protiv | - Razvoj teži zbog potrebe punog IIS - Debugiranje prometa (https promet se ne vidi jednostavno) - Pad perfomansi zbog višestrukih handshake requestova (SSL), cca 5-20% manje req/sec - TCP prijenos ne radi sa SSLom | - CSRF (cross site request forgery) napad, krađa cookia - Sav promet lako vidljiv (packet snifferi,...) |
Napredni načini bindanja i behaviora WCF servisa (queues, reliable sessions, transactions, message-level security, peer-to-peer messaging, drugi protokoli osim HTTP, HTTPS, TCP) u Silverlightu nisu dostupni zbog ograničenja sandbox modela rada unutar browsera, tako da se može koristiti samo basicHttpBinding (ili neke custom verzije, uz dodatno konfiguriranje). [more]
Dodatne informacije o načinima konfiguracije WCF za rad sa Silverlightom i dostupnim protokolima su dostupne na adresi http://msdn.microsoft.com/en-us/library/cc197959%28v=VS.95%29.aspx
Custom WCF + SSL
Korisnički podaci (username, password) se spremaju unutar SOAP poruke. Zbog sigurnosne implikacije ovakvog načina prijenosa, WCF zahtjeva upotrebu HTTPS protokola. U konfiguraciji WCFa to se zove TransportWithMessageCredential, i za SL znači da će korisnički podaci biti sadržani u poruci.
Sa server strane potrebno je konfigurirati da barem jedan endpoint (web servis) sadrži basicHttpBinding sa podešenim security modom. Također, potrebno je i napraviti klasu koja će vrštiti autentikaciju:
public class MyCustomValidator : UserNamePasswordValidator
{
public override void Validate(string userName, string password)
{
// This isn't secure, though!
if ((userName != "some_username") && (password != "some_password"))
{
throw new SecurityTokenException("Validation Failed!");
}
}
}
navedena klasa i metoda će se izvršiti za sve pozive na web servise koji imaju podešen taj binding, i registrira se u web.configu.
Primjer WCF konfiguracije:
Za rad ovakvog web servisa ne može se koristiti ugrađeni Visual Studio web server (Cassini), pošto on ne podržava SSL (HTTPS) protokol, stoga je potrebno aplikaciju publishirati na IIS server (IIS7 ili 7.5, sa .NET 4 application poolom). Uskoro će biti moguče i koristiti IIS Express, izvšnu (.exe) verziju punog IIS web servera, međutim ona je još u beta fazi razvoja (SSL se na IIS Expressu može konfigurirati preko WebMatrixa).
IIS web site sa SL aplikacijom i web servisima mora imati instaliram SSL certifikat, i bindan https protokol na 443 portu (ili nekom drugom). Za testiranje se može koristiti self-signed certifikat, koji se jednostavno dodaje u IIS:
Detaljne upute o podešavanju IIS-a se mogu pronaći na adresi: http://www.digicert.com/ssl-certificate-installation-microsoft-iis-7.htm
Kao što je u ovom primjeru prikazana upotreba basicHttpBinding endpointa (endpoint definira protokol kojim će web servis izlagati svoje podatke), tako možemo definirati i custom binding, te dodatno podesiti parametre prema želji. Primjer defaultno definiranog endpointa:
Ista ta konfiguracija može biti napravljena i putem custom binding endpointa
Ovaj primjer je preuzet sa stranice http://www.codemeit.com/security/wcf-basichttpbinding-equivalent-custombinding.html, gdje se može pronaći detaljni opis upotrebe!
Sa strane Silverlight klijenta, svaki upit na web servis je potrebno potpisati sa korisničkim imenom i lozinkom, podešavanjem ClientCredential objekta na proxy klijentu od web servisa (generiran od strane VS-a):
private void Button_Click(object sender, System.Windows.RoutedEventArgs e)
{
tbRez.Text = "loading...";
try
{
WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);
client = new SecuredServiceClient();
client.ClientCredentials.UserName.UserName = txtUsername.Text;
client.ClientCredentials.UserName.Password = txtPass.Text;
client.DoWorkCompleted += client_DoWorkCompleted;
client.DoWorkAsync();
}
catch (Exception ex)
{
tbRez.Text = ex.Message;
}
}
void client_DoWorkCompleted(object sender, DoWorkCompletedEventArgs e)
{
if (e.Error != null)
tbRez.Text = e.Error.Message;
else
tbRez.Text = e.Result;
}
Navedeni način autentikacije je moguč u SL3 i SL4 aplikacijama, ne i SL2.
U slučaju NotFound greško kod poziva web servisa, prilikom publisha SL aplikacije na lokalni web server (IIS), potrebno je konfigurirati endpoint adresu web servisa, u ServiceReferences.ClientConfig datoteci SL projekta. Meni poziv na web servis nije radio sa hosts mapiranom domenom (www.nesto.hr na 127.0.0.1), iako se aplikacija otvarala na toj adresi. Nakon promjene adrese u ime kompjutera, pozivi su proradili.
Životni vijek requesta:
1. Instanciranje proxy web servis objekta poslovne logike
2. Dodavanje credentiala
3. Poziv web servisa
4. Pokretanje bindane klase za validaciju na serveru
a. U slučaju krivih korisničkih podataka bacanje SecurityTokenException
b. Klijent dobiva Exception poruku
5. Pokretanje pozvane metode web servisa poslovne logike
6. Metoda provjerava logiranog korisnika u OperationContext.Current.ServiceSecurityContext.PrimaryIndentity objektu
a. Prijavljeni korisnik nema dovoljna prava, bacanje Exceptiona
b. Klijent dobiva Exception poruku
7. Metoda vraća podatke klijentu
u sljedećeom nastavku će biti opisan Forms način prijave sa http cookijima…