i have designed an intranet and want to implement some user level security.

lets say for example there are 5 asp pages and 3 users. i want one of the 

user to have full access , one user to view only 2 pages and other to view 

other 3 asp pages.

Can i achieve this??

if yes then plz let me know the procedure to do it.

i would be greaful to you

i am using win2K server 

thanks in advance

Create security groups for the different levels of access; create 3

different folders; assign group 1 permission over all 3 folders, group 

2

permission over 2 folders, and group 3 permission over 1 folder.  Then 

put

your ASPs into the appropriate folder according to which groups can 

access

them.  Disable anonymous access, enable some form of authentication and 

your

there.



However, you will probably want to build some kind of logic into your

application that will identify which group someone is in, and only show 

them

the links for what they can access.



Alternatively, you don't have to use NT security at all - you can build 

your

own security model.  Have a database of users, and a level of access

associated with each user.  Then you can easily display the correct 

links

for each user, and in each ASP have a line that tests the level of 

access

and redirects to an error page if its wrong.





-----Original Message-----

From: taherm@f...

[mailto:taherm@f...]

Sent: 20 June 2001 10:16

To: ASP Web HowTo

Subject: [asp_web_howto] "ASP Security Issue"





i have designed an intranet and want to implement some user level 

security.

lets say for example there are 5 asp pages and 3 users. i want one of 

the

user to have full access , one user to view only 2 pages and other to 

view

other 3 asp pages.

Can i achieve this??

if yes then plz let me know the procedure to do it.

i would be greaful to you

i am using win2K server

thanks in advance

Here is my login process.  I wasn't to sure that I should post this, 

but

here it is.  This sets up my STATE and also leads into my application

specific security.  The application security is not posted here, but by

following the login process just about any type of page, system, 

application

security can be enabled.



Overall Process

The header page is an asp includes file and is part of every page in an

application.  It's used to keep track of STATE for the user only for 

that

application or domain name.  Other applications on the same server use 

their

own header files but they can share the same STATE information because 

of

the domain name.  These are the processes of the header file.  These

processes have nothing to do with application security.  Application

security is another topic and handled after the login/logout process.



1) Checks to see if the web client supports and has enabled the use of

cookies.  If not, the user is redirected to a page, which explains the

problem. (Session cookies have not been added to process this yet)

2) Calls a function (isLogin) to see if the user is already logged in.

=B7 isLogin checks for a GUID (global unique identifier) store in a 

cookie.

If found it looks up the persons ID number based upon the GUID matching

another GUID stored in the database at login time.

3) If the user is logged in then a logoff button is displayed along 

with the

user login name. The user is allowed to continue processing the page.

4) If the user is not logged in then the login screen is displayed and 

the

application stops.

Login Process

1) The header file displays the login prompt.

2) The user enters the login name and the password or checks a box for

'email my password' and hit enters.

3) The header file sees that a person is trying to login.

4) It deletes any old GUIDs in either the cookie or the DB based on the

login. (clean start)

5) If the user checks the checkbox 'email my password' the password, 

and

email for the account is found.

=B7 The header files calls a COM object to decode the password.

=B7 Email is sent to the user.

6) The header files calls a COM object with the login, password.

=B7 The COM file pulls the account and password from the DB.

=B7 It encrypts the password by the user and compares it to the stored

password.

=B7 Any errors (up to 5) can be passed back from the COM object to the 

ASP

page.

7) The header file checks for errors.

8) No errors then a 36 character GUID is generated.

9) The new GUID is stored in the cookie and the database.

10) If everything was created and stored okay the user is assigned a 

login

status and allowed to proceed with the page.

11) If logged in, the persons style information is pulled; fonts sizes,

colors, etc...

12) If no style is specified then a default style is assigned.

Logout Process

1) The login status cleared.

2) The GUIDs are deleted.

3) GUIDs are checked to make sure they were removed.

4) Login page is presented.

Dependicies

1) OLE DB is used instead of ODBC because of faster performance.

2) Browser support of cookies is enabled.

3) SSL is used.  The header file also controls the use of SSL. If SSL 

is

turned on for an application then any attempts to connect using http 

are

switched over to https.  If SSL is turned off for an application the 

any

attempts to connect using https are switched over to http.

4) A nightly (timed) process should be created to remove the GUIDs left 

in

the database.

Pros of this process

1) The users only needs to login once a day or until the cookie are set 

to

expire.

2) All communications are using SSL and can not be adverted.

3) Passwords are stored in the database with encryption.

4) Stored passwords are never decrypted to match the password entered.  

The

entered password is encrypted then checked for a match against the 

stored

password.

5) This process can be used on the Intranet or Internet.

6) Email containing the passwords can be sent to the users if they 

forget

it.  Although, the decryption algorithm can not guarantee that it can

decrypt the passwords.  The encryption program is set up to insert 

special

characters if certain other characters are found.  A 64-bit key stored 

in

the Com Object generates the special characters.

7) A COM object is used for checking all login/password information.  

This

COM object is compiled and somewhat protected from hacking by general

developers and users.

8) To drop all users from any applications I can just delete the GUIDs

stored in the database. Mostly for maintenance, upgrades, etc...

9) To see who is accessing applications I can just look up any GUIDs 

stored

in the database.  This isn't too accurate because the cookies last for 

a day

but it gives me an idea.  It's not much different or better then trying 

to

use a log file with times.

10) Using SSL the cookies can not be hijacked off the network.

11) STATE can now be maintained either by the database or the cookie.

Depends on the application and its security requirements.

12) Multiple instances of the same browser can be opened and used by 

the

client using for any application running on the domain name.

Cons of this process

1) All browsers must be able to support and have cookies enabled.

2) If a users walks away from their browser without logging off there 

is a

potential security risk.

3) The cookie could be hijacked off the client's computer.  If one was

hijacked the easiest way to stop its use is for the user to click the 

logoff

button in the application.  This removes the GUID from the database and

forces a new login.

4) Two different browsers on the client can not be opened using the

applications on a domain name. (i.e. IE and NS)



-----Original Message-----

From: taherm@f...

[mailto:taherm@f...]

Sent: Wednesday, June 20, 2001 5:16 AM

To: ASP Web HowTo

Subject: [asp_web_howto] "ASP Security Issue"





i have designed an intranet and want to implement some user level 

security.

lets say for example there are 5 asp pages and 3 users. i want one of 

the

user to have full access , one user to view only 2 pages and other to 

view

other 3 asp pages.

Can i achieve this??

if yes then plz let me know the procedure to do it.

i would be greaful to you

i am using win2K server

thanks in advance

If the application itself is very simple one may not want to write a very

complicated log-in procedure.



I would like to propose the following:

1. Receive user name and password by using Request.Form.

2. Check whether this password matches the username stored in the db.

3. If it does, then set Session("useraccess") for example, depending on

which pages this user is allowed to view.

4. Start each of the pages (or do it in a header file) by checking the value

of Session("useraccess") and then deciding whether to show the page content

or not.



I suppose this is a very low security way to log a user onto the

application. Are there strong, negative, views on using Session("") to keep

track of specific users?





/David



----- Original Message -----

From: "Morgan, Rob" <Rob.Morgan@o...>

To: "ASP Web HowTo" <asp_web_howto@p...>

Sent: Wednesday, June 20, 2001 1:31 PM

Subject: [asp_web_howto] RE: "ASP Security Issue"





Here is my login process.  I wasn't to sure that I should post this, but

here it is.  This sets up my STATE and also leads into my application

specific security.  The application security is not posted here, but by

following the login process just about any type of page, system, application

security can be enabled.



Overall Process

The header page is an asp includes file and is part of every page in an

application.  It's used to keep track of STATE for the user only for that

application or domain name.  Other applications on the same server use their

own header files but they can share the same STATE information because of

the domain name.  These are the processes of the header file.  These

processes have nothing to do with application security.  Application

security is another topic and handled after the login/logout process.



1) Checks to see if the web client supports and has enabled the use of

cookies.  If not, the user is redirected to a page, which explains the

problem. (Session cookies have not been added to process this yet)

2) Calls a function (isLogin) to see if the user is already logged in.

· isLogin checks for a GUID (global unique identifier) store in a cookie.

If found it looks up the persons ID number based upon the GUID matching

another GUID stored in the database at login time.

3) If the user is logged in then a logoff button is displayed along with the

user login name. The user is allowed to continue processing the page.

4) If the user is not logged in then the login screen is displayed and the

application stops.

Login Process

1) The header file displays the login prompt.

2) The user enters the login name and the password or checks a box for

'email my password' and hit enters.

3) The header file sees that a person is trying to login.

4) It deletes any old GUIDs in either the cookie or the DB based on the

login. (clean start)

5) If the user checks the checkbox 'email my password' the password, and

email for the account is found.

· The header files calls a COM object to decode the password.

· Email is sent to the user.

6) The header files calls a COM object with the login, password.

· The COM file pulls the account and password from the DB.

· It encrypts the password by the user and compares it to the stored

password.

· Any errors (up to 5) can be passed back from the COM object to the ASP

page.

7) The header file checks for errors.

8) No errors then a 36 character GUID is generated.

9) The new GUID is stored in the cookie and the database.

10) If everything was created and stored okay the user is assigned a login

status and allowed to proceed with the page.

11) If logged in, the persons style information is pulled; fonts sizes,

colors, etc...

12) If no style is specified then a default style is assigned.

Logout Process

1) The login status cleared.

2) The GUIDs are deleted.

3) GUIDs are checked to make sure they were removed.

4) Login page is presented.

Dependicies

1) OLE DB is used instead of ODBC because of faster performance.

2) Browser support of cookies is enabled.

3) SSL is used.  The header file also controls the use of SSL. If SSL is

turned on for an application then any attempts to connect using http are

switched over to https.  If SSL is turned off for an application the any

attempts to connect using https are switched over to http.

4) A nightly (timed) process should be created to remove the GUIDs left in

the database.

Pros of this process

1) The users only needs to login once a day or until the cookie are set to

expire.

2) All communications are using SSL and can not be adverted.

3) Passwords are stored in the database with encryption.

4) Stored passwords are never decrypted to match the password entered.  The

entered password is encrypted then checked for a match against the stored

password.

5) This process can be used on the Intranet or Internet.

6) Email containing the passwords can be sent to the users if they forget

it.  Although, the decryption algorithm can not guarantee that it can

decrypt the passwords.  The encryption program is set up to insert special

characters if certain other characters are found.  A 64-bit key stored in

the Com Object generates the special characters.

7) A COM object is used for checking all login/password information.  This

COM object is compiled and somewhat protected from hacking by general

developers and users.

8) To drop all users from any applications I can just delete the GUIDs

stored in the database. Mostly for maintenance, upgrades, etc...

9) To see who is accessing applications I can just look up any GUIDs stored

in the database.  This isn't too accurate because the cookies last for a day

but it gives me an idea.  It's not much different or better then trying to

use a log file with times.

10) Using SSL the cookies can not be hijacked off the network.

11) STATE can now be maintained either by the database or the cookie.

Depends on the application and its security requirements.

12) Multiple instances of the same browser can be opened and used by the

client using for any application running on the domain name.

Cons of this process

1) All browsers must be able to support and have cookies enabled.

2) If a users walks away from their browser without logging off there is a

potential security risk.

3) The cookie could be hijacked off the client's computer.  If one was

hijacked the easiest way to stop its use is for the user to click the logoff

button in the application.  This removes the GUID from the database and

forces a new login.

4) Two different browsers on the client can not be opened using the

applications on a domain name. (i.e. IE and NS)



-----Original Message-----

From: taherm@f...

[mailto:taherm@f...]

Sent: Wednesday, June 20, 2001 5:16 AM

To: ASP Web HowTo

Subject: [asp_web_howto] "ASP Security Issue"





i have designed an intranet and want to implement some user level security.

lets say for example there are 5 asp pages and 3 users. i want one of the

user to have full access , one user to view only 2 pages and other to view

other 3 asp pages.

Can i achieve this??

if yes then plz let me know the procedure to do it.

i would be greaful to you

i am using win2K server

thanks in advance

If you are on an NT domain it is really easy.  Disallow anonymous access

and then set ntfs permissions on the files or directories.

----- Original Message -----

From: <taherm@f...>

To: "ASP Web HowTo" <asp_web_howto@p...>

Sent: Wednesday, June 20, 2001 9:16 AM

Subject: [asp_web_howto] "ASP Security Issue"





> i have designed an intranet and want to implement some user level

security.

> lets say for example there are 5 asp pages and 3 users. i want one of

the

> user to have full access , one user to view only 2 pages and other to

view

> other 3 asp pages.

> Can i achieve this??

> if yes then plz let me know the procedure to do it.

> i would be greaful to you

> i am using win2K server

> thanks in advance

>