6

Ho letto un sacco di cose online sull'autenticazione e l'autorizzazione e alla fine ho optato per un codice che sembra funzionare ... ma non comprendo completamente tutto ciò che sta facendo (per quanto riguarda FormsAuthenticationTicket).Perché utilizzare FormsAuthenticationTicket con l'autenticazione di Windows?

L'app MVC con cui sto lavorando gestirà alcuni dati sensibili e desidero triplicare tutto ciò che faccio relativamente all'autenticazione e all'autorizzazione.

Sto utilizzando l'autenticazione di Windows;

<authentication mode="Windows" /> 
<authorization>  
    <deny users="?"/> 
</authorization> 

Ho un set di tabelle in SQL Server con informazioni aggiuntive su Utente e Autorizzazione.

  • Utenti
  • Ruoli
  • UsersInRoles
  • altre tabelle che definiscono gli oggetti nell'applicazione e associati permessi.

Nel mio Global.asax ho i seguenti metodi ispirati dal

http://www.codeproject.com/Articles/5182/Insight-into-Security-Model-using-Principal-and-Id

protected void WindowsAuthentication_OnAuthenticate(object sender, WindowsAuthenticationEventArgs e) 
{ 
    if (e.Identity == null || !e.Identity.IsAuthenticated) 
    { 
    //Redirect to error or access denied page 
    } 

    string userData = e.Identity.AuthenticationType;   

    var cachedUser = HttpContext.Current.Cache[e.Identity.Name] as User; 

    if (cachedUser == null) 
    { 
    var user = repo.GetUserByFullUserName(e.Identity.Name); 
    HttpContext.Current.Cache.Insert(e.Identity.Name, user, null, DateTime.Now.AddMinutes(2), Cache.NoSlidingExpiration); 
    cachedUser = HttpContext.Current.Cache[e.Identity.Name] as User; 
    } 

    var userIdentity = e.Identity.Name; 

    var formsAuthTicket = new FormsAuthenticationTicket(1, e.Identity.Name, DateTime.Now, DateTime.Now.AddMinutes(2), false, userData); 

    var encryptedTicket = FormsAuthentication.Encrypt(formsAuthTicket); 
    var httpcook = new HttpCookie("authCookie", encryptedTicket); 
    Response.Cookies.Add(httpcook); 
} 



protected void Application_AuthenticateRequest(object sender, EventArgs e) 
{ 
    if (Request.IsAuthenticated) 
    { 
    var httpcook = Context.Request.Cookies["authCookie"]; 
    var formsAuthTicket = FormsAuthentication.Decrypt(httpcook.Value); 

    var cachedUser = GetCachedUser(formsAuthTicket.Name); 
    if (cachedUser == null) 
     { 
     cachedUser = CreateCachedUser(formsAuthTicket.Name); 
     } 

    var genIdentity = new GenericCustomIdentity(cachedUser, Request.IsAuthenticated, formsAuthTicket.UserData); 

    var genPrincipal = new GenericCustomPrincipal(genIdentity, cachedUser); 

    HttpContext.Current.User = genPrincipal; 
    } 
} 

Così qui sono le mie domande:

  1. Perché hanno un FormsAuthenticationTicket nel WindowsAuthentication_OnAuthenticate metodo? Non posso semplicemente costruire i miei oggetti Identity e Principal nel metodo WinAuth?

  2. La memorizzazione dei dati utente in HttpContext.Current.Cache rappresenta un rischio per la sicurezza? Poiché questi metodi sono chiamati numerose volte non voglio colpire il db ogni singola richiesta. Esiste un'alternativa migliore/più sicura?

  3. Non ho familiarità con l'utilizzo di FormsAuthenticationTickets, Identity e Principal quindi qualsiasi commento o suggerimento sarebbe molto apprezzato. Spiacente, questa non era una domanda.

+0

[Non utilizzare mai web.config per bloccare ASP.Net MVC] (http://stackoverflow.com/questions/11765030/how-to-lock-down-paths-in-asp-net-mvc-4) –

+0

Questo vale anche per l'autenticazione di Windows? Non esiste un modulo di registrazione o schermata di accesso. Probabilmente otterrò User.Identity e creerò un record "predefinito" nel mio database e poi permetterò ad un amministratore di applicare altre autorizzazioni o restrizioni in un altro momento. Non ho ancora tutti i dettagli, ma a qualsiasi utente con un account AD valido dovrebbe essere consentito l'accesso e chiunque altro non dovrebbe farlo. In questo caso dovrei seguire i suggerimenti nel link o lasciare il web.config così com'è? – killerbunnyattack

risposta

3

Perché hanno un FormsAuthenticationTicket nel metodo WindowsAuthentication_OnAuthenticate? Non posso semplicemente costruire i miei oggetti Identity e Principal nel metodo WinAuth?

Gli oggetti Identity e Principal esistono solo durante la chiamata/richiesta corrente dal client. Fanno parte dello HttpContext e sono, per mancanza di un termine migliore, smaltiti alla fine della richiesta. Una volta che la persona autenticata si connette di nuovo, viene creata una nuova richiesta e, per impostazione predefinita, non vengono autenticati.

FormsAuthenticationTicket (Per impostazione predefinita) utilizza un cookie sul lato client per memorizzare le informazioni di autenticazione per ogni richiesta successiva. Ciò consente al metodo Application_AuthenticateRequest di utilizzare il cookie per autorizzare di nuovo la richiesta.

La memorizzazione dei dati utente in HttpContext.Current.Cache rappresenta un rischio per la sicurezza?Poiché questi metodi sono chiamati numerose volte non voglio colpire il db ogni singola richiesta. Esiste un'alternativa migliore/più sicura?

Il HttpContext.Cache viene memorizzato. Se il server si ripristina o il pool di app si riavvia per qualsiasi motivo, la cache non funziona.

Sì, si tratta di un rischio per la sicurezza, la memorizzazione delle informazioni utente è memoria del server. Il rischio tuttavia è molto piccolo, a meno che qualcuno non abbia il tuo codice per vedere come stai usando la cache e potrebbe caricare il codice per leggere la cache.

Non ho familiarità con l'utilizzo di FormsAuthenticationTickets, Identity e Principal quindi qualsiasi commento o suggerimento sarebbe molto apprezzato. Spiacente, questa non era una domanda.

Come su collegamenti ad HttpContext.User (IPrincipal) con la sua proprietà Identity di tipo IIdentity. Non è la risposta più descrittiva, ma entrambe le interfacce sono estremamente basilari.

+1

Ho anche dimenticato di menzionare, un altro rischio per la sicurezza è la modifica di un utente in modo che non possano accedere. Se queste informazioni utente sono nella cache, l'utente può ancora accedere, perché è una versione memorizzata nella cache. –