În această eră a mobilității și a interconectivității device-urilor, există cazuri în care accesul la informație trebuie restricționat pentru entitățile neautentificate. Scopul acestui articol este furnizarea de detalii privind metodele de autentificare și autorizare pentru dezvoltatorii de soft care folosesc platforma ASP.NET, și în special ASP.NET MVC.
În rândurile următoare vom expune infrastructura ASP.NET Identity, insistând asupra particularităților de bază ale produsului, dar și asupra modului în care acest sistem poate fi modificat pentru a se preta unor scenarii/situații diferite.
Ca să putem răspunde la această întrebare, după cum explică autorii [1], putem afirma că ideea din spatele acestei infrastructuri reprezintă o soluție care furnizează următoarele beneficii:
Un mecanism de autentificare și autorizare care permite controlul asupra mecanismului de stocare a informației, ușor de extins și de testat, ce oferă în plus și un middleware OWIN, destinat folosirii în cadrul oricărui tip de aplicație(web, mobile, cloud);
Autorizare bazată pe rol sau pe solicitare;
Infrastructură care poate fi conectată pentru diferiți furnizori, cum ar fi Microsoft, Google, Facebook, Twitter, etc.;
Facilități de integrare cu Azure Active Directory.
Privire de ansamblu asupra arhitecturii
În mod implicit, mecanismul de persistență este implementat utilizând conceptul Entity Framework Code First. Pentru a stoca informația, se vor genera un set de tabele:
Un tabel care va conține informațiile despre utilizator: user id, numele user-ului, o parolă hashed;
Un alt tabel reprezentând rolurile - poate fi interpretat ca reprezentarea grupurilor de autorizare;
Un tabel pentru claims - un set de informații care duce la identificarea utilizatorului;
Părțile principale ale sistemului sunt formate din:
Microsoft.AspNet.Identity.Core - logica pentru users, stores și managers;
Microsoft.AspNet.Identity.EntityFramework - implementarea legată de stocare specifică a Entity Framework;
Următoarea diagramă ilustrează componentele arhitecturale ale framework-ului:
Figura 1.Componentele ASP.NET Identity
Luând în considerare partea de nucleu a framework-ului, următoarea diagramă ilustrează abstractizările conceptelor de user și store:
Figura 2. ASP.NET Identity Core
Dacă privim structura centrală, vom observa entitățile de bază, acestea fiind: IUser și IRole, care sunt folosite în partea de stores; IUserStore - user management și respectiv IRoleStore - pentru rol management.
Următoarele tipuri de stores, prezentate mai jos, sunt particularizări ale conceptului reprezentat de IUserStore:
IUserClaimStore - stochează claims specifice fiecărui utilizator;
IUserEmailStore - stochează partea de e-mail;
IUserLockoutStore - reprezintă partea de lockout:- accesuri respinse, statusul de blocat, etc;
IUserLoginStore - persistarea asocierilor cu provider-ii de login externi: Google, Facebook, Twitter, Microsoft;
IUserPasswordStore - stochează parola hash-ed pentru un utilizator;
IUserPhoneNumberStore - stochează informații legate de numărul de telefon;
IUserRoleStore - face legătura între utilizatori și rolurile lor;
IUserSecurityStampStore - stochează timbrul de securitate;
Pe lângă stores, există și partea de managers. Aceștia sunt responsabili pentru orchestrarea modificărilor, respectiv:
UserManager - expune funcționalitatea care va salva modificările în user store;
În cazul în care Entity Framework nu este compatibil cu proiectul la care lucrați, există posibilitatea de a folosi diverși provider-i de stocare, care suportă următoarele tehnologii:
MySQL;
Azure Table Storage;
ElasticSearch;
CouchDB / Cloudant;
MongoDB;
NHibernate;
RavenDB;
Dacă acești furnizori nu sunt ceea ce aveți nevoie, există posibilitatea de a fi dezvoltați alții și integrați în proiectul de dezvoltat. Pentru a realiza acest lucru, trebuie luate în considerare următoarele aspecte:
Sursa de date pe care o veți folosi;
Datele care trebuie stocate: informațiile utilizatorilor, user claims, cât și partea de logins și roles
Clasele de stocare: user store, user claim store, user logins store, user role store;
Există anumite scenarii în care aplicația care urmează a fi dezvoltată trebuie să ofere posibilitatea de autentificare prin alte/de către alte surse, nu doar opțiunea tradițională, unde informațiile utilizatorului se păstrează într-o bază de date locală. În acest caz, dezvoltatorii pot folosi suportul inclus în produs, pentru implementarea provider-ilor externi.
Există două standarde de autentificare care permit utilizatorilor folosirea conturilor de la provider-i de încredere. Acestea sunt OAuth și Openld. După cum afirmă unii experți, protocolul OAuth a fost creat în principal pentru autorizare, dar sunt multe cazuri în care este utilizat pentru autentificare. Partea bună, la aceste standard, este că majoritatea provider-ilor oferă și implementarea pentru ele, scutindu-i pe utilizatori de procesul de înregistrare pentru diferite aplicații
Dacă folosim provider-i externi, în primul rând trebuie să ne asigurăm că Autentificarea proiectului este setată pe Individual User Accounts. Utilizarea de provider-i de autentificare externi, cum ar fi Google, Microsoft, Facebook, etc. obligă stabilirea conexiunii în mod SSL, dar este indicat a se folosi https și după login, pentru a nu fi transferate date sensibile în clear-text. Dacă dezvoltăm aplicații folosind ASP.NET MVC, atributul RequireHttps poate fi folosit pentru a obliga toate Request-urile să folosească https și atributul Authorize pentru a restricționa accesul. O altă abordare ar fi crearea unui filtru care să oblige toate Request-urile să treacă prin https. Configurarea RequireHttps și Authorize pentru întreaga aplicație este considerată un security best practice.
În cadrul dezvoltării de aplicații folosind ASP.NET MVC 5, provider-ii de autentificare externi sunt configurați prin App_Start\Startup.Auth.cs. În funcție de protocolul implementat, OAuth sau OpenID, provider-ul va impune un proces de înregistrare sau nu, pentru a furniza datele de autentificare. Datorită faptului că ASP.NET Identity dispune de un OWIN middleware, configurarea provider-ului extern este foarte ușor de realizat indiferent de protocolul implementat de provider.
Următorul conținut prezintă App_Start\Startup.Auth.cs cu configurația OWIN funcțională:
public partial class Startup
{
// For more information on configuring
// authentication, please visit
// http://go.microsoft.com/fwlink/?LinkId=301864
public void ConfigureAuth(IAppBuilder app)
{
// Configure the db context and user manager
// to use a single instance per request
app.CreatePerOwinContext(
ApplicationDbContext.Create);
app.CreatePerOwinContext
(ApplicationUserManager.Create);
// Enable the application to use a cookie to store
// information for the signed in user
app.UseCookieAuthentication(
new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.
ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider
{
OnValidateIdentity =
SecurityStampValidator.
OnValidateIdentity(
validateInterval: TimeSpan.FromMinutes(5),
regenerateIdentity: (manager, user) => user.
GenerateUserIdentityAsync(manager))
}
});
// Use a cookie to temporarily store information
// about a user logging in with a third party
// login provider
app.UseExternalSignInCookie(
DefaultAuthenticationTypes.ExternalCookie);
// Uncomment the following lines to enable logging
// in with third party login providers
//app.UseMicrosoftAccountAuthentication(
// clientId: "",
// clientSecret: "");
//app.UseTwitterAuthentication(
// consumerKey: "",
// consumerSecret: "");
//app.UseFacebookAuthentication(
// appId: "",
// appSecret: "");
//app.UseGoogleAuthentication();
}
}
După ce procesul de înregistrare cu provider-ul de autentificare este încheiat, pasul următor ar fi să folosim Startup.Auth.cs pentru a configura aplicația, astfel încât aceasta să folosească acel provider. Salvarea de date sensibile în cod sau fișiere reprezintă o problemă de securitate și această abordare trebuie evitată. Modalitățile de securizare a aplicațiilor web împotriva diferitelor amenințări sau atacuri care pot exista nu reprezintă subiectul acestui articol.
Scopul principal al acestui articol a fost prezentarea modului în care caracteristicile sistemului ASP.NET Identity pot fi folosite pentru a controla accesul la anumite părți ale aplicației.
În prima parte au fost prezentate informații generale despre sistem și avantajele lui pentru dezvoltatorii care trebuie să includă funcționalitatea de membership în aplicațiile lor. A doua parte a articolului oferă informații despre arhitectura framework-ului, expunând componentele abstracte, despre ce storage providers pentru diverse tehnologii de stocare există deja, dar și ce aspecte ar trebui luate în considerare atunci când este nevoie să scriem chiar noi unul. Ultima parte conține informații legate de plug-in-ul și configurarea unui provider de autentificare extern.
Luând în considerare produsul finit, posibilitatea de a extinde și de a adapta sistemul, ASP.NET Identity este o opțiune de considerat atunci când dezvoltarea unei aplicații care folosește tehnologia .NET implică și funcționalitatea de membership.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
