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:
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:
ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
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!
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.
You have several options:
Basic authentication over HTTP.
PRO. Easy to implemet
CON. UserCredentials was going in clear text throuh the network
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
You can force clients to use HTTPS.
CON. You should setup your web server.
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 :)
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.
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
Related
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I have a web api 2 that I want to host on azure-app-service. The service should be called by javascript applications so as far as I know it has to be open to public (right?).
However, if I let it be totally open it is vulnerable to DOS. What is the best way to do that?
The first thing that came to my mind was to implement a custom IP Filter that keeps requests from last x minutes and let the one with less than y occurrence pass.
Is there any other way? Is there any specific way to do it on the azure without writing code?
This is not a broad question! I think it is clear what I am asking!
I have a service on Azure and I want to protect it from overusing. How broad is that?!?!
If it's a public API (ie. something a mobile app would talk to), it has to be.. well, public of course. :)
If your users have to sign up before consuming your API (or if this is an option), you could use API keys. That does not prevent DoS, and is not a form of authentication if given to clients, but at least you can quickly revoke offending keys to somewhat mitigate DoS.
Other than that, your primary concern with regard to DoS is application level DoS. You should try to avoid API calls that put a strain on your backend, limit response sizes (which probably implies paging on a client), etc. With these things done in your API, let your provider deal with the network level stuff.
By default azure services are protected against DDOS,MITM attacks and all communication is via https and encrypted.
As far the application design goes you need to take care of the following ;
SQL Injection,Session hijacking, Cross-site-scripting, Application-level MITM and Application-level DDoS.
Further you can do vulnerability check on your app services using Tinfoil security scanning tests.
https://azure.microsoft.com/en-us/blog/web-vulnerability-scanning-for-azure-app-service-powered-by-tinfoil-security/
Also using azure API management service you can use the API gateway to control API calls, routing, enforce usage quotas and also do throttling based on the traffic to the API.
https://azure.microsoft.com/en-in/documentation/articles/api-management-howto-product-with-rules/
I’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny
I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.
I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.
As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.
Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.
HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.
I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.
Can anybody tell me what is meant by web services?
How do they work?
and more information about it.
Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. --Wiki
Wiki has a good article on Web Services, you'll find a load of information there.
http://en.wikipedia.org/wiki/Web_service
As Andrew Tanenbaum and Maarten van Steen say in Distributed Systems - Principles and Paradigms, 2nd Edition: "a Web service is nothing but a traditional service (e.g., a naming service, a weather-reporting service, an electronic supplier, etc.) that is made available over the Internet". The main idea is that you have a client application that can use services provided (published) by a server application.
There are a couple of important things you should look into: one is the directory service which stores service descriptions, which should adhere to the UDDI standard. Another thing is that web services are described by the means of formal language (WSDL). And last, but not least, you need to specify how communication takes place: SOAP is a widely (probably most well-known) protocol in this sense.
Also, as can be noticed, be really careful about the standards (protocols, formal description language etc.), when implementing web services.
The ideas above have been taken from the aforementioned book (Distributed Systems - Principles and Paradigms, 2nd Edition, Andrew S. Tanenbaum, Maarten van Steen, 2007). For more programming language oriented books, you can check "Java Web Services: Up and Running" by Martin Kalin, O'Reilly, 2009 (did not read this but it is by a good publisher and it is new) and I am sure there are a lot of other good books out there.
Web services are just like a kind of framework, that you access over the Internet. That can be used for authentication, single sign-on, data access, etc. For instance, imagine a Twitter client. It can be a web application, a desktop application, or a mobile application. They all need to authentify a user, get the timeline, get the user tweets, and allow the user to post a new tweet. The aplication receives the data from the user, and transmit it to Twitter, by their web service. This is done by calling an URL on twitter.com with some parameters, depending on the web service format (soap, rest, etc). Then Twitter can process the action.
Web services allows applications to use, interact with, and communicate with other aplications. That way, you van have many apps, but only one data source.
Fahrenheit to Celsius - Simple Example Web Service (ASP.NET)
You can get started with Web Services # W3Schools.com.
Your first C# Web Service - Code Project
And most of your questions are answered in a 15seconds article.
in web application web-service used for transfer data using Ajax technologies without refreshing all page.
also i prefer to you this article with sample Create a JSON WebService in ASP.NET 2.0 with a jQuery Client link text wroted by Ajay Singh link text
If you are familiar with calling a subroutine (method/procedure/function/etc) with parameters and get a result back, then "web services" is one of many ways to call a subroutine located "elsewhere" and get a result back. "Elsewhere" is typically on another computer under the control of somebody else but you.
It has been tried several times before but I believe that Web Services have become so popular due to several reasons:
The communication can be done over http (like a browser). This means that a lot of infrastructure can be reused, and as http is simple, that infrastructure can be simple. This includes proxies, firewalls, debug tools etc.
Web Services include a "contract" - WSDL - saying exactly which things are provided, where they are, and what arguments they take, and what is returned. That contract allows building helping tools, proxies, creating a tool that simulates the other end, and much more.
Microsoft likes it. This results in good support on Windows, which gives many programmers an easy way in.
But, the answer to your question is "web services are subroutines located on other computers".
Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. isma