Security based on session, what's wrong?

[Matt]

Hello,

I'm working on a portal derived from IBuySpy, and I have changed

I check username and pwd against a database, then I make a
Session["User"]= UserID (the ID I get from the database, if it
exists).
Now I create all the pages based on that ID stored in a session
variable.
If that user is authorized to see a certain tab, module or content,
the page is created that way. All the auth info (user/contents) are
stored in another database table.

Everything works fine without use fo forms authentication.
Is there something wrong with it? should I use forms authentication?
why?

Thanks,
Mattia

 

[Brock Allen]

You can always go and build your own authentication and authorization mechanism.
The intent of Forms is that much of the routine checks and identity management
is done for you. Of course there are pieces you have to fill in, such as
the login page and the database of usernames/passwords, but the check on
every page is done for you to see if the user is logged in and if they're
allowed to access the pages. The cool thing is that this is declarative with
the <authorization> elements in web.config, and there's typically little
or no access checks you have to write in your own code.

 

[Matt]

Ok, then if I just create my authorization mechanism, and just rely
from page to page to the Session["IDUser"] to create my page, is not
less safe than using the Forms authentication mechanism?

Sometimes I have the feeling that Session (I use InProc) expires
earlier than the specified n minutes of the web.config (my app found
Session["IDUser"] empty and resets to the login page)
I use a sWindows2003 server with IIS6, with multiple asp.net portals
with the same codebase running on it.
I know that with forms auth you have to specify different form name
instead of the default ASPAUTH, is the same for session cookie?

Thanks,
Mattia