Security Setup - Extranet

Results 1 to 3 of 3

Thread: Security Setup - Extranet

  1. #1
    Join Date
    Dec 1969

    Default Security Setup - Extranet

    I&#039;m creating an ASP extranet application where different users (I envisage a maximim of 10) will have access to details such as work we&#039;ve done for them, costs, and scheduled work.<BR><BR>I want to let each user view their own information, but not that of other users. All the information is stored in one database, so the stored procs would have the job of filtering out ONLY records relevant to that particular user. This would make sure that a user only sees what they are allowed to.<BR><BR>I envisage writing it as follows...<BR><BR>1) User navigates to our extranet login page.<BR>2) User enters username/password<BR>3) User details checked against SQL Server 2000 "logon" table, which holds, for each user:<BR><BR>a. ASPUserName - the username the user enters into the logon page.<BR>b. ASPPassword - the password the user enters into the logon page.<BR>c. DBUserName - the username the ASP page supplies as part of the database connection string.<BR>d. DBPassword - the password the ASP page supplies as part of the database connection string.<BR><BR>If the details entered by the user are matched to a record on the logon table, I will set the following session variables:<BR><BR>a. bAuthenticated - a boolean value = true<BR>b. sUserName = DBUserName (from the logon table)<BR>b. sPassword = DBPassword (from the logon table)<BR><BR>4) For all subsequent page requests a check is made to see if the user has been authenticated (the bAuthenticated session variable will be true if they have been authenticated). If authenticated, the session variables sUserName and sPassword will be supplied in the connection string for database access through stored procedures unique to them. If not authenticated, then the user will be redirected to the logon page.<BR><BR>As far as I can see, this will work quite well. The benefits will be that we do not have to hand over the actual username and password for the database, and the use of stored procs and views can be tied down exactly how we like by setting permissions on the SQL Server user accounts.<BR><BR>A disadvantage may be that I have to use session variables, but this application will never have enough concurrent users for this to become an issue. Another is that I have to maintain two sets of usernames and passwords for each user.<BR><BR>Can anyone suggest a better way of doing this? <BR><BR>Would you do it any differently? <BR><BR>For example - would you forget about having separate SQL Logins and just use the windows IUSER account for everyone. I could then set permissions for IUSER to ONLY stored procs on that db<BR><BR>

  2. #2
    Join Date
    Dec 1969

    Default I think your solution is good...

    ...and I can&#039;t really any serious security issues (other than the usual - brute force attack of username/password). I also like how you provide usernames and passwords that are different to the ones on the DB, since then the client can set their own usernames and passwords and you don&#039;t have to keep changing the DB if they want to change theirs. For exactly that reason I think it&#039;s better not to use the ISUER, otherwise you&#039;re tying them down again.<BR><BR>Anyway, that&#039;s only what I think. :-)<BR><BR>Oliver.

  3. #3
    Join Date
    Dec 1969

    Default Actually since you are asking

    , I think you are doing a little *too* much. ; )<BR><BR>No need to use all those session variables. The "sUserName" session variable will have be populated with a value if the person has been "authenticated" so why use "bAuthenticated" field which tells you the exact same thing.<BR><BR>For that matter, why use *both* ASPUsername/password and different DBusername/passwords for each person?! I think this is a little overkill for this app. If you are concerned about security, you are already using stored procedures so create one db id/password that only has permission to execute those procs. <BR><BR>Personally I wouldn&#039;t make the stored procedures specific to each "DBUserName", instead make them more generic with the ability to accept "ASPUserName" as a parameter (or better yet client id).<BR><BR>You said that this was to show details about work you&#039;ve done and yet to be done. So I&#039;m assuming these are clients and if yes I&#039;m hoping you&#039;ve designed your database around client id.<BR><BR>Obviously you have a good idea of what needs to be done and I know you are concerned about security, however I just don&#039;t want to see you unnecessarily create more for yourself. ; )<BR><BR>Remember you are talking a maximum of 10 users.<BR><BR>Good luck<BR>Pete<BR> <BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts