Web Services Security

[Brent]

Hi everyone, im about to start to design an application where security will
be a must. I am starting to develop a web service that will be used for
winform applications either from the local lan or from the internet. Also, i
might use the same thing in an asp.net web site. I will pass a dataset to
the client from the web service where they can modify the data and send the
dataset back to the server for insert/update/deletes. I might also add some
methods so you don't have to return allow you to return just one entry from
the database instead of everything. Also, allow you to update one entry
without setting the entire dataset back over the line. I am probably going
to use the cryptogaphy functions allong with TripleDES to encrypt
everything. I don't think it will be to bad. What is how do i handle
authentication since there will be no state? When the user enters the
application they will be prompted for a password. This will check their
password compared to a hash that i will store on the DB. Ok everything is
fine and dandy but now how do i make sure they are authenticated before they
call any methods on the web service? I don't want any unauthenticated users
calling this web service. Do i need to pass there password every time? I
know i could probably use SSL but i don't want to overhead of SSL if its
preventable.

One a side note, i contemplated using http based remoting instead of web
services but i already have iis running on my server and i don't want to
have to open another port on my firewall for the remoting piece. I wanted to
still be able to use port 80.

I guess my main question was with the authentication part but does anyone
see any other flaws in my design?

thanks,
Brent

 

[Joseph Bittman MCSD]

August 5, 2005

I would probably create a ticket-based system. After the person is
auth'ed, then I would create a cookie, stick a GUID in it, and then encrypt
it with the TripleDes or something, and then send the cookie to the client.
This cookie should be based each time the user makes a call, and the GUID
should be retrieved, decrypted, compared at a list (maybe an in-memory list
if calls are often enough) and then the method should be executed. Now, some
people might say that you are authenticating again, but it shouldn't be THAT
big of a deal unless you are really having to scale and have a load of
users.

I agree that a web service should be used instead of remoting. If you think
you might use this for an ASP.Net project, then I would probably seperate
all the authentication classes into a "Business" layer which would call into
the data components layer. This way, the web service, the asp.net service,
and any other future ones all call into the same code which does the same
work which checks the same way. Then you don't have as much maintance (as
far as updating it in many places if the code changes) and all your other UI
interfaces can be implemented with ease. Hope this helps and have a great
day! (Ask more questions if you have any!)

--
Joseph Bittman
Microsoft Certified Solution Developer

Web Site: http://71.39.42.23
Static IP

 

[Dominick Baier [DevelopMentor]]

Hello Brent,

you have two options for authentication -

a) use a password/SSL based approach
b) use WS-Security

a) not a bad approach at all - you rely on transport security - you get server
authentication out of the box (after all that is the machine your clients
are sending the credentials to) - yes you have a SSL overhead, but to be
honest, this overhead is totally comparable to implementing encryption yourself.
But SSL is a proven and tested mechanism. As a side note - network traffic
gets slightly smaller with SSL because the protocol already includes compression.
For real high volume sites, where you might think SSL sucks too much CPU
power, IIS6 supports crypto hardware to speed up the math. This requires
that your users have windows accounts.

b) another option - supports auth/encryption/signatures over an unsecured
transport. Supports several types of authentication mechanism - password/certificate
or kerberos based. Can be used to authenticate against a database.

I wouldn't go for a cookie based approach, because a) this is not normal
web service behaviour b) if not using SSL the cookie is transported in clear,
open to replay/hijacking attacks.

both approaches are valid. I urge you not to implement your own authentication
scheme. Take what other have done for you (and is already tested by a lot
of people).

you may want to have a look at the WSE2 library from Microsoft, this gives
you WS Security support.

general notes:

DataSets are .NET only - if you ever need to support non .NET clients - you
will have a hard time. Generally, don't use datatypes that can not be expressed
in the WSDL file. If you go for datasets, you should use strongly typed ones
(this will give clients the schema of the data at proxy generation time).
If this is a concern, consider packaging the data in a different data structure
(like array of objects)