aspnet / Security

[Archived] Middleware for security and authorization of web apps. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
1.27k stars 599 forks source link

Enhancement - Introduce cache to Cookie Authentication #436

Closed neurospeech closed 6 years ago

neurospeech commented 9 years ago

In previous ASP.NET, we were caching Authentication module to improve speed, e.g.

This is psedo code.

     context.User = HttpRuntime.Cache["FA-" + cookie.Value] as IPrincipal
     if(context.User == null){
           .. decrypt ticket... validate it etc.. renew ticket if required..
          IPrincipal user = DecryptAndValidateAndRenewTicket(cookie.Value);
          HttpRuntime.Cache.Add( "FA-" + cookie.Value, user .. timeout for 5 mins)
     }

This results in improved performance as we are reducing request life cycle's authentication part by caching it for 5 mins.

Instead of HttpRuntime.Cache, we can create a configurable MemoryCache, in Cookie Authentication module, that can cache authorizations in memory for short lived period. This reduces decryption and validation for small amount of time.

davidfowl commented 9 years ago

In previous ASP.NET, we were caching Authentication module to improve speed, e.g.

Do you mean you wrote your own AuthenticationModule that did caching?

Tratcher commented 9 years ago

Do you mean something like this? https://github.com/aspnet/Security/blob/dev/samples/CookieSessionSample/Startup.cs#L26 https://github.com/aspnet/Security/blob/dev/samples/CookieSessionSample/MemoryCacheSessionStore.cs

kevinchalet commented 9 years ago

IMHO, that's actually a very good idea.

The same caching concept should/could also apply to the bearer middleware. I remember the Thinktecture guys implemented a similar thing in their validation middleware, and it's definitely a great feature.

@Tratcher I guess it would be similar, but with a major difference: the session store you're mentioning is meant for reference cookies, which means that decrypting cookies won't work when the store is cleared. Caching doesn't have the same objective: it will only help reduce the CPU cost of the cryptographic operations required to verify/decrypt the ticket by caching the claims corresponding to a token/cookie, but will have no influence on the final size of the cookie/token. Verifying/decrypting the ticket should work even if the cache has been cleared.

Tratcher commented 9 years ago

@PinpointTownes I know they aren't the same, but the reference mode could be another way of avoiding the crypto overhead.

Another way of adding this would be as a wrapper around the ISecureDataFormat used in CookieAuthOptions.TicketDataFormat

kevinchalet commented 9 years ago

Sure, you can always implement that yourself, but I guess the OP was looking for a built-in thing.

Eilon commented 6 years ago

Closing this issue because we have no plans to implement this. If we are presented with concrete performance data we will reconsider.