5

sto usando Asp.NET Identity 2.1.0 e memorizzare un elenco di Accounts che un User ha accesso, come sostiene. Il ClaimsIdentity viene generato quando il User segni:forzare un altro utente per aggiornare le loro richieste con ASP.NET Identity 2.1.0

public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager) 
{ 
    var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 

    // Add Claims concerning Account 
    userIdentity.AddClaim(new Claim("AccountList", SerializedListOfAccounts)); 

    return userIdentity; 
} 

Diciamo che un amministratore revoca l'accesso s' User A ad un account specifico. Come posso forzare User A a rigenerare il suo ClaimsIdentity? Ricorda che non è nel contesto di User A. E non voglio aspettare fino a quando il cookie non è scaduto (e un nuovo ClaimsIdentity viene generato automaticamente

È possibile? Non c'è un modo per dire al server di considerare il cookie di User A come non valido e forzare per rigenerarlo?

il motivo che voglio questo comportamento è quello di creare un costume AuthorizeAttribute che posso mettere sul mio controller che controlla il Claims per vedere se un User ha accesso o meno, al fine di evitare un viaggio in più intorno al banca dati.

+1

Dovresti loro logout, giusto? Forse questo aiuterà: http: //stackoverflow.com/questions/10369225/forcefully-log-out-a-specific-user-among-all-online-users –

+1

@BrendanGreen non ho davvero voglia di uscire loro, costringili a rigenerare le loro affermazioni. Potrei usare UpdateSecurityStamp per costringerli ad accedere di nuovo, ma quello sarebbe il momento in cui il token scade comunque. – Joel

+0

è possibile effettuare il logout e registrarli nuovamente con le attestazioni aggiornate. – warheat1990

risposta

5

non è possibile memorizzare i loro crediti nei confronti di biscotto, ma li applica su ogni richiesta per l'identità nelle prime fasi del pipeline. Dovrai modificare lo Startup.Auth.cs per farlo. Sto facendo solo quello here.

E qui è il nocciolo si può lavorare con:

public partial class Startup 
{ 
    public void ConfigureAuth(IAppBuilder app) 
    { 
     app.UseCookieAuthentication(new CookieAuthenticationOptions 
     { 
      Provider = GetMyCookieAuthenticationProvider(), 
      // other configurations 
     }); 

     // other usual code 
    } 



    private static CookieAuthenticationProvider GetMyCookieAuthenticationProvider() 
    { 
     var cookieAuthenticationProvider = new CookieAuthenticationProvider(); 
     cookieAuthenticationProvider.OnValidateIdentity = async context => 
     { 
      // execute default cookie validation function 
      var cookieValidatorFunc = SecurityStampValidator.OnValidateIdentity<UserManager, ApplicationUser>(
       TimeSpan.FromMinutes(10), 
       (manager, user) => 
       { 
        var identity = manager.GenerateUserIdentityAsync(user); 
        return identity; 
       }); 
      await cookieValidatorFunc.Invoke(context); 

      // sanity checks 
      if (context.Identity == null || !context.Identity.IsAuthenticated) 
      { 
       return; 
      } 


      // get your claim from your DB or other source 
      context.Identity.AddClaims(newClaim); 
     }; 
     return cookieAuthenticationProvider; 
    } 
} 

Gli svantaggi che è necessario applicare pretese su ogni richiesta e questo potrebbe essere non molto performante. Ma la giusta quantità di caching nel posto giusto aiuterà. Anche questo pezzo di codice non è il posto più facile da lavorare, in quanto è molto presto in cantiere ed è necessario direttore di te stesso DbContext e altre dipendenze.

I pregi sono che le rivendicazioni sono applicati subito per la richiesta di ogni utente e si ottiene immediato cambiamento dei permessi, senza dover effettuare nuovamente il login.