You could do it several ways. The easiest would be with cookies, but it's still stored on the computer in clear text. The next would be session variables, which are stored on the server for the duration of the client's connected session. The last would be to do your own session tracking in a database, and store the values in there.
Cookies are easy to use, but not necessarily the most secure thing to do if your client is security concious.
Session variables are just as easy, and are stored on the server and not the client (so that makes them more secure), but limits your scalability of the system since sessions do not span web servers (so if you load balance your application, one server may initiate the session with the client computer, then the load balancer forwards a second request for content to a second server that has no knowledge of the existing session on the first web server).
DB managed sessions are a bit more tricky because you have to do all the tracking and clean up yourself. This may be more difficult, but solves the problem of a load balancer since all your web servers use the same SQL server or SQL server farm. In this instance, you'd create a DB with a session table to store the session ID and values of the session. When a user connects, you insert a new row to your session table which creates a session ID and passes it back to your app. Now your app can either stick that session ID in a cookie, or pass it in a URL from page to page. So as the user browses the site, you can pull the session ID, and touch the session table as needed to read or write values regarding their current session. Then when they log out, you simply delete the session from the table and clear the session ID in the cookie.
The trickiest part of a DB managed session may be the session clean up on abandoned sessions. You need to keep track of how long the session has been inactive (probably a datetime field in the session table that's updated each time the user hits a page). Then you need a process that runs regularly that checks the sessions' datetime field to make sure they have not been inactive for a lengthy period of time. If so, the process then kills the session. This could be done with a scheduled DTS package in SQL Server with a single SQL statement like "DELETE FROM tblSessions WHERE dtSessionUpdated < DATEADD(mi, -30, GETDATE())" (this would delete any session that hasn't been updated in the last 30 minutes). You would just need some ASP code that updates the session in the DB with the current date/time. If no records were touched with the Update, you know the session was deleted due to inactivity, and you can redirect them to the login page.
That which does not kill me postpones the inevitable.