Session variable, Profile or page-by-page check?

I'm currently building an Intranet application to track projects set up by my company. It's secured using Windows authentication, with the users allocated into various NT roles. Users should only be able to edit actions raised on them by a steering group, although they may view other people's actions. They may also be in one or more of the steering groups, each of which should only be able to approve projects specifically set up in their 'area'.

I was thinking of setting up a profile for each user, but I can't really see the point as it would just be duplicating data that's already held in the database. I could also retrieve them specifically on each page where they're needed and cache them, but that seems to be just replicating what Session variables would be doing.

So, if I create a couple of Session variables, one to hold the user's ID from a database table and the other to hold a list of which steering groups they're members of, assign them at Session_Start, then check these variables on the appropriate web pages and disable/ enable editing accordingly- is this a suitable way of controlling access? Will there be any problems with the session variables being lost, do I need to check if they're null on each page where they're used and re-retrieve them from my BLL if necessary? Is there a chance of the variables being 'hijacked'- ie should I be looking for a more secure way of storing them?

Thanks for any help.

A session variable to hold the user's Id and group list is good. If you are using ASP.NET 2.0, put the code to check for the user's id in the master page. Thus you do not have to check on any page that uses that master page.

You do need to allow for authenticated user's that are not in your database table and redirect to page with a message like "As user DOMAIN\FRED.BLOGGS you do not have access to this system, please contact the support line on XXXX if you require access.

Session variables will be lost if the user's session times out. It is tempting to increase the timeout, but unless you have a rigorous policy of locking unattended Pc's, leave it on the default of 20 minutes or even decrease it.

My preference is always to run cookieless and to hold session state either in memory or in SQL State.

Great, thanks very much. Do you have any strategy of dealing with timeouts?

>Do you have any strategy of dealing with timeouts?

The strategy depends on the environment. If the Windows policies will cause the PC go to a passworded screen-saver after say 5 minutes of non-use, then you can increase the timeout time with impunity, otherwise it is primarily a simple matter of user education.

Some reduction in susceptibility to timeouts can be achieved by adopting a multi-screen approach as opposed to a wizard, as the first screen can create a new record and the other screens merely update it.