Using cookies for custom role provider

Hallo,

I'm still undecided about the architecture to implement on my framework but since I want to extend default roles with other functionalities (like tasks and assigning pages/folders to roles programmatically) I guess I have to write my custom role provider.

I already have the idea of what I need to store. At first I was reluctant to store roles and permission related information on cookies but then I found out that asp.net already stores the username in the authentication ticket. So if this is considered "secure" using encryption maybe I should feel less paranoid with roles in cookies. That's because if someone finds a way to "create" a fake authentication ticket with the user name of an admin (for example) that's enough to take over roles and every other permission.

Now I'm facing a couple of choices. Storing roles and additional permissions (task, pages and so on) in SQL Server and retrieve them right after authentication in each single request and assign them to the context to be accessed. This should be no big issue compared to lazy initialization of the default provider since when the user is logged in there will be a role check almost in every page (for personalized menues and other GUI elements and such).

With this approach I will have no limits on the amount of stuff I can retrieve and I can use this unique query per page to retrieve additional data so to mimic session storage as well and completely ignore sessions.

The other approach would be to store those info in in-memory (not permanent) encrypted cookies, or using the user-data in the authentication ticket for additional info and the default roles cokies for roles. This means that I have a size limit of 4KB total and the overhead of encryption/decryption.

With this second approach I will only have one roundtrip to the db for user and then just access cookies.

My main concerns on this second option are about the total size of the cookie (how many real characters could I store in them, considering the encryption overhead?). And if it's really more performant and scalable to decrypt 4kb of cookies and sent them over the wire on each request or just make a direct query on SQL Server based on ID ( where ID = ...).

Assuming an ipothetical 100 concurrent users per second, wich solution will perform best? And wich will perform best if user base grows? How many real bytes/char can I store in 4Kb encrypted cookies? And how to do the encryption/decryption, can I use the FormsAuthentication.Encrypt() function for a non ticket cookie?

Any other hints or issues that I'm not considering?

Thanks in advance

Re: Using cookies for custom role provider

Windows Identity Foundation provides a rich API for modeling user information. It uses Claims as its basis and is better model than just roles. Also, WIF caches the user claims in cookies but it has a cookie splitting algorithm in case the cookie is too small. Dominick adapted this to forms, so it might be worth checking out.

Re: Using cookies for custom role provider

Thank you Brock! I had a fast overview on it and it was still buzzing in my head for some good reason it seems. Going to check.

So you think the "cookie" solution should be viable performance/scalability wise, better then the SQL select on each request.

Re: Using cookies for custom role provider

manight

Thank you Brock! I had a fast overview on it and it was still buzzing in my head for some good reason it seems. Going to check.

Yea, security is hard/tricky... and there's a lot to keep in mind. It's also a lot of fun :)

manight

So you think the "cookie" solution should be viable performance/scalability wise, better then the SQL select on each request.

So the cookie approach is fine for most desktop-browser scenarios. If you're talking about mobile devices, then having 2 or 3 maxed out cookies then you might just want to do that caching in-memory on the server and rebuild the user's roles/claims/whatever on each request (which is also fine). Correctness first, then performance :)

Re: Using cookies for custom role provider

I gave a first glance at your link and it's intriguing :) Just 2 things I don't understand:

"Implements caching of the principal on the server side (aka session mode) if configured in an AppSetting."

Why cache if you can access the cookie? To avoid let's say 16/20kb roundtrip on the wire right? Does it use sessions to cache?

OT: One question (since you've been so kind with me in the other posts too!) is an empty asp.net session 5kb as it used to be in classic asp or an empty session would just be some bytes for the sessionid?

The second things I'm concerned about is the multiple cookies. Shouldn't be 4kb TOTAL per domain considered safe? Or the actual browser will tolerate multiple 4kb cookies? (btw this won't be an issue since I won't exceed the 4kb limit for my purprose)

Re: Using cookies for custom role provider

manight

"Implements caching of the principal on the server side (aka session mode) if configured in an AppSetting."

Why cache if you can access the cookie? To avoid let's say 16/20kb roundtrip on the wire right? Does it use sessions to cache?

So this means that you only put an identifier in the cookie and then the actual bulk of user info/claims are in-memory on the server (like the dedault session state with all its warts). Again, sometimes you don't want all that bulk in a cookie since even with simple claims I've seen it need at least 2 cookies for overflow).

It does not use session state for the caching and that's the comment about "extensible" -- you can implement your own caching so you can support web farms, app domain recycles, etc.

manight

OT: One question (since you've been so kind with me in the other posts too!) is an empty asp.net session 5kb as it used to be in classic asp or an empty session would just be some bytes for the sessionid?

Session isn't really 'allocated' until you store something in it, so across multiple requests from the same user you won't get a cookie and the server side session ID will be different on multiple requests. I know this isn't what you asked, but it seemed somewhat relevant.

As for the overhead (once you've put something into session), I don't know. I never use session state.

manight

The second things I'm concerned about is the multiple cookies. Shouldn't be 4kb TOTAL per domain considered safe? Or the actual browser will tolerate multiple 4kb cookies? (btw this won't be an issue since I won't exceed the 4kb limit for my purprose)

The spec says 4K per cookie, 20 cookies per host.

Re: Using cookies for custom role provider

Thank you again Brock! I will try to stick to my previous framework attitude and avoide session as well, I will leave them as a possibility with SQL Server (or in-proc based on the needs) for plugging in third party stuff wich uses session.

On my classic asp framework (without sessions) I had a db call on each page to check user identity against the cookie and retrieve the permission.

Now with asp.net, even if you have to customize a lot to obtain what you really want, I must say it gives you infinite possibility, it's funny, Visual Studio IDE is astonishing... well I'm feeling like a baby in candy store :) The risk is that you gather so much infos that your mind is next to blow up :) But I think this phase of gathering is well worth before even starting to code, to start in the right direction and avoid having to recode the core of your framework later (as far as this is possible)

Thanks again