Auth in a WS over the internet

[Toble Rone]

I now that this can be a completely newbie question, but and a bit confused
on this.

I currently in a new project where i need to expose a lot of "sql
functionality" to users using a WinForms rich client. That app need to
access several tables and querys. So... exposing the sql server to the
internet is the "natural" but unwanted option due to security risks.
So, i guess that the way to go is to create (one or more) web services to
serve those information to the clients. But now im on the security seide of
all this. How is the correct way to protect the access to the WS's with some
sort of authentication?, becouse i have the whole internet with this
scenario.
I'd saw a lot of examples on this, but with integrated security (windows)
for Intranets. And i'd also saw some examples with WS calls that use a token
in their parameters (probably over a https channel).... but.... i dont want
to send all the sensitive parameters over the internet AND the token.

Any help will be apreciated.

Thnx in advance.

[Henk de Koning]

Hi,

There are a couple of options to handle this. First and foremost, a web
forms app would probably be best suited for this sort of app, but I'm going
to presume you have good reasons to do this as a smart client.

The thing with web services is that usually the client is a computer
program, not a human being. This is where authentication is going to be a bit
different (in that with web services you cannot assume your process -- or
thread -- token to be a conveniant place to get credentials from). Most
samples you'll find that use the HttpRequest oriented stuff
(SoapHttpClientProtocol is HttpRequest-ish) will use integrated security
because the client is a user logged in to some domain and it's so darn easy
to just grab the current credentials.

However, you can use the same technique to supply your own credentials, as in:

_proxy.Credentials = new NetworkCredentials("username", "pwd");

This will allow you to do basic auth (over ssl, of course ...) with a
SoapHttpClientProtocol derived proxy.

If you decide to go the WSE2 route, there's absolutely no reason to send a
token as parameter. The normal usage style is to send the token as a header
(in WSE this means it's implemented as a filter). What you do to get the same
sort of thing as basic auth in WSE is at the client side is create a username
token (with password option SendPlainText, again, over ssl) and add it like
_proxy.RequestSoapContext.Security.Tokens.Add(_myT oken). At the server side
WSE will (by default) try to map the username and password to an existing
account.

Anyhow, see the WSE2 docs for details because there's any number of
possibilities ..

HTH,

-- Henkk
"Toble Rone" wrote:

I now that this can be a completely newbie question, but and a bit confused
on this.

I currently in a new project where i need to expose a lot of "sql
functionality" to users using a WinForms rich client. That app need to
access several tables and querys. So... exposing the sql server to the
internet is the "natural" but unwanted option due to security risks.
So, i guess that the way to go is to create (one or more) web services to
serve those information to the clients. But now im on the security seide of
all this. How is the correct way to protect the access to the WS's with some
sort of authentication?, becouse i have the whole internet with this
scenario.
I'd saw a lot of examples on this, but with integrated security (windows)
for Intranets. And i'd also saw some examples with WS calls that use a token
in their parameters (probably over a https channel).... but.... i dont want
to send all the sensitive parameters over the internet AND the token.

Any help will be apreciated.

Thnx in advance.