ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 38
Abonament PDF

Asigurarea Accesului Autorizat la Resursele Web prin Utilizarea ASP.NET Identity

George Rus
Software Developer @ Yardi România



PROGRAMARE


Î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. 

Ce este ASP.NET Identity?

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:

Î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: 

Părțile principale ale sistemului sunt formate din: 

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:  

Pe lângă stores, există și partea de managers. Aceștia sunt responsabili pentru orchestrarea modificărilor, respectiv: 

Î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: 

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: 

Autentificarea externă 

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.

Concluzii

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.

Bibliografie

  1. http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity

  2. https://msdn.microsoft.com/en-us/magazine/dn605872.aspx

  3. http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects