deploying web service and client, security

  • Thread starter Thread starter fred00
  • Start date Start date
F

fred00

I have been searching for information relating to what I want to do,
and I am assuming it is not a common issue. I have developed a web
service and a client for a customer. I need to give the customer both
the service to run on their machines, and the client. I need to hide
implementation details from the customer (and anyone else).

I see alot of information about how to require SSL through IIS, and
hide the WSDL through XML config files, but this obviously requires the
customer to take these steps. Is there a way to do these things from
inside the project? Does .NET provide an infrastructure for using web
services in this context?

I am developing using Visual Studio 2005/C#.

Can anyone give me some information, point me to some articles on the
subject, etc?
 
I have been searching for information relating to what I want to do,
and I am assuming it is not a common issue. I have developed a web
service and a client for a customer. I need to give the customer both
the service to run on their machines, and the client.
Click to expand...

When you say "give" it to them, do you mean give them access to the
webservice, which you will host remotely?
I need to hide
implementation details from the customer (and anyone else).
Click to expand...

Well, this is always the case with a web service, which is an interface.

I see alot of information about how to require SSL through IIS, and
hide the WSDL through XML config files, but this obviously requires the
customer to take these steps. Is there a way to do these things from
inside the project? Does .NET provide an infrastructure for using web
services in this context?
Click to expand...

Who are you trying to hide it from?

The customer, or the general public?

You can always use basic IIS blocking and only allow access via a
specific IP or range of IP addresses or domainname using IIS configuration.

In addition, you can add a Username/Password attribute that has to be
passed in the web service call ( I can post code if you don't already
know how to do this) that enables authentication (this only affects who
can access a web service/method, but it doesn't block the WSLD as above.

Can anyone give me some information, point me to some articles on the
subject, etc?
Click to expand...

It's more important at this point that you sit down and draw up a
spreadsheet or table about what exactly you're trying to protect/secure
and from whom.
 
John said:
When you say "give" it to them, do you mean give them access to the
webservice, which you will host remotely?
Click to expand...

No, I mean give them the web service (DLLs) which they will host on
their servers.

- I provide the server/client setup to the customers.
- The server is installed on their machines with a web service front
end.
- The client is installed on their machines and populates the server
database through the web service.
- The data is theirs, the server/client would be licensed
Well, this is always the case with a web service, which is an interface.



Who are you trying to hide it from?

The customer, or the general public?
Click to expand...

Everyone except me ;)

I want to control access to server functionality and the developement
of the clients.
You can always use basic IIS blocking and only allow access via a
specific IP or range of IP addresses or domainname using IIS configuration.
Click to expand...

This is my main problem. Control of the webservice is handled through
IIS and external XML files. If I could require SSL and block the WSDL
from within my code, the problem would be solved (I think).
In addition, you can add a Username/Password attribute that has to be
passed in the web service call ( I can post code if you don't already
know how to do this) that enables authentication (this only affects who
can access a web service/method, but it doesn't block the WSLD as above.
Click to expand...

I am beginning to think that authentication is my only hope. All the
implementation is still exposed though.
It's more important at this point that you sit down and draw up a
spreadsheet or table about what exactly you're trying to protect/secure
and from whom.
Click to expand...

I already know this. It is how to do it that is the problem.
 
Back
Top