August 4, 2003 at 5:30 pm
Greetings - Advice sought here... I posted this in security, maybe that was not the correct place.
I am about to re-work a web site which uses IIS 5, ASP 3 and SQL Server 2000. IIS is set up as Integrated Windows Security. Users are authenticated against a domain controller (NT 4) and in the SQL Server database, there is a Users table with the UserIDs of the persons allowed to access this intranet application - along with other permissions for the application...
This intranet site is eventually going to become a client extranet which will be accessed via the public Internet by pre-authorized clients/customers of the company. New users will have to be manually approved and then added - they can not add themselves. However, for now, the re-worked site will continue to live on the intranet - but not for long as the intention is to remove the need for VPN access to the company''s network.
My guess is that SQL Server logins SHOULD be used in this case. Can anyone point me in the direction of a good resource to show how exactly to log in a user via SQL Server in ASP -OR- is it as simple as making sure that the USERID and PASSWORD entered on the Login.asp page (IF validated as a SQL Server ''user''), and if so, then use that USERID/PASSWORD for all database connection strings, for that user throughout the session?
Any ideas or tips would be greatly appreciated. I do not think that the current method of simply storing the valid users in a Users TABLE is going to be secure enough for the public Internet. But this is sort of new to me and I am seeking any and all advice.
Thanks!
August 5, 2003 at 6:28 am
As you are saying, there is a user table which maintains security information.
Hence one alternative is as follows.
In Login.Asp Page
- Let us say user details are stored in strUid and strPwd.
- Use a single fixed userid/pwd to connect to sql*server database for all users.
(This will help in connection pooling also)
- After connecting to database validate the strUid and strPwd against the user table.
- If the validation succeeds then allow user to continue to use the system.
- Use the strUid to verify permissions
There are few issues with this approach, one of them is mentioned below
if your application uses USER() etc system functions in the SQL Queries and stored procedures then these need to be changed to use the strUser (other wise all users will be internally treated as single user!)
Hope this helps.
August 5, 2003 at 6:47 am
Yes, that is definitely helpful. Thanks! I will be making use of the USER() function and other pertaining to the currently logged on user (who create, last modified the row, in triggers for auditing, etc) - so I will have to consider the latter information you posted.
Thanks!
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply