ÃŽ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.
Prezentări de articole și
Panel: DevOps & Kubernetes