ASP.NET "Custom" Security

[RMT]

Hi, my application goes like this:



Windows Forms (client)
|
|
|
ASP.NET (IIS 5.0) or APACHE (vanilla SOAP for example)
|
|
|
SQL Server, DB2, MySQL, Oracle, (whatever)



My schema on the database contains a "Users" table, which contains bits set
or cleared according to whether that user can execute the given method, e.g.
"dbo.DeleteNode" stored procedure can only be executed by a user with this
bit set in a field in the Users table. I don't want to use ASP.NET
security model, basically because I will be writing a generic SOAP concrete
class to be returned from my ConnectionFactory class and I won't know it's a
Windows server at the other end. What I want to do, if you people think it
sounds reasonable, is to just pass a username/password with every method I
attempt to execute, to be authenticated by the stored procedure against the
database.

Question 1: Is this a reasonable security model? i.e. just a single U/P
evaluated inside a stored procedure on the database.
Question 2: In order to pass the username/password safely, I have to host it
with HTTPS, correct?
Question 3: If I don't use HTTPS, how can I achieve encryption/decryption?
Question 4: What are the implications for allowing anonymous access, but
stopping unauthorized access inside the stored procedure?
Question 5: Is this a flimsy model and should I have another layer of
security somewhere?
Question 6: What if as well as sending a username/password, I sent a network
card address (unique!)

To be honest, I find security a nightmare to think about - especially with
all of the options available, it's complexity in some scenarios and what
goes on in the underlying system that I don't see (ie. Windows
Authentication, how does that work?). I have a large brain it's true, but
the Security Lobe is rather atrophied. Can I have some advice here please?

Thanks,



Robin.

 

[Joe Kaplan \(MVP - ADSI\)]

You can certainly do what you are suggesting here. Essentially, you are
creating a straight "delegated" model security system where the backend
enforces security instead of using the "trusted subsystem" model, where the
middle tier enforces security. There are good points and bad points for
each model.

For your delegation, you are using plaintext credentials to identify and
authenticate your users. This gives you a lot of flexibility, especially
with x-platform where you can't assume Windows security features like
Kerberos delegation, but also adds the additional responsibility of both
collecting those credentials and transmitting them securely. That should
not be taken lightly. However, given that you plan to have your own set of
credentials on the backend for your users, there doesn't seem to be any
advantage to trying to leverage Windows security here since your db isn't
going to consume those credentials anyway.

Using HTTPS is your only "universal" way of transmitting that data securely
at the transport level. If you want to do something message level, you will
either need to role your own encryption code in your clients and servers or
use a framework designed to implement message level soap extensions like
WS-Security (in WSE or WCF). I'd suggest sticking with HTTPS here, as you
are certainly likely to get yourself in trouble implementing your own crypto
at the message level with the level of skill you have professed to have and
using WS-Security might not be easy for x-platform again.

For the anonymous question, that would depend completely on the sproc's
implementation, now wouldn't it?

It is going to be hard to get excellent advice on how to proceed from a
newsgroup question as you are asking pretty broad architectural questions
that would require a fair amount of knowledge about your environment and
requirements to get a good answer to. If you don't feel comfortable making
these choices yourself or getting yourself educated on security and you
really care about this product, you might be well-suited to hiring someone
with these skills.

Joe K.

 

[RMT]

Thanks very much for the response. I think I feel much more comfortable
developing the prototype in this case.