security : a good approach ?

[Hernán Castelo]

hi
how much overhead
or performance i lose
with the next configuration ? :

1- IIS starts the USER_X.asp page
[ with exec permissions for IUSR ]
2- USER_X.asp creates an out-of-proc object called PROXY_X
[ PROXY_X runs under a PROFILE_X account ]
[ IWAM has exec permissons for PROXY_X ]
3- USER_X.asp invoke "sp_userx_..." stored procedures thru PROXY_X
[ PROXY_X has exec permissions for "sp_userx_..." ]
4- and the same again for every user type x, y, z

it has not the big scalability
but its enough in my case

this is intended for security reasons
i neer to know your opinions about
this configuration please

thanks

 

[Egbert Nierop \(MVP for IIS\)]

Re: security : a good approach ?

yes, it's a good one. But seldomly it is needed, to protect your SQL server
against IUSR_x and against IIS using COM+ impersonation.

COM+ impersonation in fact, never is recommended to increase security, it is
used to have IUSR_x doing things on ACTive Directory, (for instance) that
IUSR_ is not allowed to do.

 

[Hernán Castelo]

ja, good
(& excuse me to the news for the twin post)

i must run stored proc on sql srv
under different roles
but the logon is always IUSR_...

i understand IUSR_ will be a less permisive account
just capable of make a connection,
then how can i map from that connection
to the specific sql role?
i will need to exec an st.proc.
giving the user type and then
(i don't know how) restrict or permit
permissions for concerned st.proc. ...
but does it is secure?
anyway, how can i shift to the corresponding role?

thanks again

 

[Egbert Nierop \(MVP for IIS\)]

ja, good
(& excuse me to the news for the twin post)

i must run stored proc on sql srv
under different roles
but the logon is always IUSR_...

i understand IUSR_ will be a less permisive account
just capable of make a connection,
then how can i map from that connection
to the specific sql role?
i will need to exec an st.proc.
giving the user type and then
(i don't know how) restrict or permit
permissions for concerned st.proc. ...
but does it is secure?
anyway, how can i shift to the corresponding role?

you cannot really use SQL server roles if you impersonate. But if you
disable impersonation through a single user (IUSR_ or a COM+ user), resource
pooling is disabled.
The best is to create your own roles. If you switch to ASP.NET, this is
**very** easy using forms authentication.

 

[Hernán Castelo]

well, i say
without using COM+ objects
and ...trusting in the IUSR .......

unafortunately i can't move to .net

 

[Egbert Nierop \(MVP for IIS\)]

well, i say
without using COM+ objects
and ...trusting in the IUSR .......

unafortunately i can't move to .net

This means that you'll have to create your own roles in a separate table. It
is not that hard to do...

Success

 

[Hernán Castelo]

hi
i don't understand well
those "in a separate table"
did you mean "in a separate dbs"?
can you explain me a bit more
or post a link

thanks again

 

[Egbert Nierop \(MVP for IIS\)]

hi
i don't understand well
those "in a separate table"

Create a new SQL server table
for instance

roles
roleId
name
and a table named

users
userId
password
name
and a third table

userroles
userroleid
userId
roleId


Then you need some stored procedures, that handle login and member ship
checks.
etcetera.
Maybe www.sourceforge.org has some samples...