2

I'm re-writing a website from the ground up for azure. Each user has ownership of a number of objects, and has a number of permissions. Together, these determine what they are authorized to do. The question is, how should this information be stored. I want to do the authentication myself, using custom logic.

For performance reasons, I'd like to cache these authorization lists for each user once they're logged in. Can someone give me a sample for how to store & access this session information securely and efficiently.

Edit

I looked into the App Fabric Access Control, but that seemed overkill as I was going to have to create a separate site for authentication, which doesn't seem to make sense. Would the claims based authentication make sense separately though? How would you do that if it does?

Would it make more sense to just keep the username in a cookie in the traditional way and then re-query table storage with each request to get the permissions etc.? How would storing the username work in Azure?

Cost is a big factor here as it's a very small site (by azure standards) but I want high performance for a small number of users.

ForbesLindesay
  • 10,482
  • 3
  • 47
  • 74
  • Do you map the permissions onto roles and then assign the users to roles or do you map the permission directly to the users. If you use the roles as an abstraction point and if the permissions/roles do not change, then you could hold the role/permission structure in memory - it would be the same across all instances. All you would then need is the authentication mechanism to priovide role claims for each user. – Mike Goodwin Nov 10 '11 at 18:07
  • Does it have to be on Azure? In some ways you'd be better off on a good hosting provider that supports StateServer session state mode. Since cost is a factor, the compute cost of Azure is a lot higher than the hosting cost of GoDaddy or similar. – Mike Goodwin Nov 10 '11 at 19:46
  • I'm partly doing it as an experiment in Azure, I also want the uptime guarantees. I also intend to share the hosting space on Azure with other websites I create and manage, which will make the cost of compute more reasonable. – ForbesLindesay Nov 10 '11 at 22:12
  • @Mike A claim should be able to hold a list of permissions anyway? I'm just not really sure how to create/store that claim so that it is persistent across requests? – ForbesLindesay Nov 10 '11 at 22:13

2 Answers2

1

Well, you could use the Azure App Fabric cache to store the session info. ASP.Net can be configured to use it as the backing store for its session state as like a normal custom session state provider.

This article from MSDN shows you how to configure it:

http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx

From your code you just use the normal ASP.Net way to get/set the state.

Be aware though - it could be expensive ($45/month for 128MB of cache).

Mike Goodwin
  • 8,810
  • 2
  • 35
  • 50
  • +1 for a good suggestion. Unfortunately that cost would be prohibitive and, given that I doubt I'd be using more than a than a tiny fraction of that, pretty wasteful. – ForbesLindesay Nov 10 '11 at 16:35
  • Sorry :o( The problem is that unless you're only using a single role instance, you need a distributed cache, or a persistent store like table storage and then you are back into performance issues. I'd be suprised is StateServer mode worked on Azure. But if you have a single role instance, you will not get the high availability guarantee and Azure seems like a bit of a waste. Tricky. – Mike Goodwin Nov 10 '11 at 17:59
1

If you want to run with a reasonable amount of availability you need to run your site with two instances. If you're running with two instances you need to use a session provider that's no the default InProc one. Your choices are:

  • AppFabric Caching (which you don't want to use because it's too expensive, fair enough)
  • Azure Storage Session Provider. Don't use this. It's an interesting experiment, but it's only sample code, it's slow and doesn't cope well in production.
  • SQL Server session provider.

If the permissions for a user weren't going to change while they were logged in, you could just store their permissions in session. This will probably be fast enough. However this information will need to be read from SQL for each request that uses session and it is overhead.

If you wanted to make things faster you could just store the user ID in session and load the permissions into a static dictionary (keyed on user ID) when needed. These items will need to be expired after a certain amount of time or lack of use.

Community
  • 1
  • 1
knightpfhor
  • 9,299
  • 3
  • 29
  • 42