CODEWITHSUNDEEP
c#web-servicessecuritysslencryption
kseen
kseen

Reputation: 397

How to force third party service respect the security?

I have to come up with an integration process to allow existing system to use external data providers. The system is a medical timetable web site, using ASP.NET MVC, that allows the patients to schedule their appointments to doctors.

As far as I go you can see on a figure below:

Basic schema of expected integration

All the providers must expose my contract ISuperIntegration which will be develop by me. I won't be developing External service 1 and External service 2, they will be developed by other companies.

Here the issue comes: basing on the concept of that I could require the way providers should setup their services to communicate with my website properly, I want to forbid for another third party clients consume "External Service 1" and "External Service 2", Or at least make it difficult to do that.

Here is a list of stuff I am setting:

  1. ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
  2. Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
  3. And could define some general recommendations but they could be easily avoided.

At the moment I'm thinking of using HTTPS with certificate authentication. It would require the implementer to setup their infrastructure so my web site could properly consume the data.

If I would go with basic HTTP, the implementer would just leave their service to be easily consumed by anyone else, which I don't want.

I hope my question is clear. Will be happy to give any other explanations you want.

I'll really appreciate any your responses, commits. Thank you!

Upvotes: 9

Views: 231

Answers (5)

atlaste
atlaste

Reputation: 31136

I'd always use HTTPS for things like this. Let's just say that's the cost of doing business. You simply cannot have anyone with a sniffer grab that kind of traffic out of the sky. There's a reason why all banking etc. use HTTPS for things that should be secure.

Apart from that, web services have pretty standard mechanisms for security, I'd recommend looking at OAuth over HTTPS. There are plenty of implementations for that.

If your talking about basic web sites, I'd use a standard security mechanism as well like group based security (which boils down to a username + password). Again, there are plenty of implementations for that.

Basically my main word of advice is: don't go inventing stuff when it comes to security. If you're not an expert, you're probably going to get it wrong, and end up with something that can be intercepted by a third party or (much) worse.

Upvotes: 7

marcin.malczyk
marcin.malczyk

Reputation: 1

As several people mentioned these earlier you can't guarantee that those external companies will expose your service with specific security settings, it's up to them.

If you are responsible for developing MVC application and WCF service you can only force someone to use specific security settings on the layer between your WCF services and those External 1 and 2 providers. Btw, here is a good tutorial that can be useful if you want to improve your knowledge about how to configure WCF security.

How External Services expose your service it's up to them. Just image that this is normal web 'proxy' behavior.

Maybe the architecture which your company adopted it is not the best for this solution

Upvotes: 0

user3277192
user3277192

Reputation:

Considering the privacy sensitivity of the data, IMHO it must be encrypted while in transport. Hence HTTPS not HTTP.

Authentication of your service to those providing services to you: well essentially it's up to them, not up to you who they expose it to, similarly how they want it protected is their call. Now assuming you do have a way to make them do the right thing...

Client certificates aren't that expensive nor prohibitive in setup to get up and running. But you do need to register the client certificate (every time it is renewed!) with the server in order to get the needed authorisation (just recognizing it's a valid cert isn't enough: anybody can apply for a (validly signed) certificate ...) .

But all that is relatively painless and rather well documented around the web, and it can be done on almost any platform of choice.

Upvotes: 0

Huy Nguyen Ngoc
Huy Nguyen Ngoc

Reputation: 26

You are like Oracle, they want people to develop in Java language but they also want to forbid competitors to run the Java compiled code on non Oracle's virtual machines, or at least make it difficult to do that :)

So you can do the same by protecting your interface with patent or copyright law. However, I doubt that it is patentable or copyrightable :)

Upvotes: 0

Max Kilovatiy
Max Kilovatiy

Reputation: 798

You have several options:

  1. Basic authentication over HTTP.
    PRO. Easy to implemet
    CON. UserCredentials was going in clear text throuh the network

  2. Implement WS-Security with WCF. For example, they can sign their requests.
    PRO. Easy to implement with WCF
    CON. Java clients can faced with problems

  3. You can force clients to use HTTPS.
    CON. You should setup your web server.

Upvotes: 0

Related Questions