Last post Dec 20, 2016 07:02 PM by Taichung
Dec 07, 2016 11:31 PM|Taichung|LINK
Hi, I'm using VS2013, C# asp.net
I'm incorporating a colleague's web service, asmx project to my solution. Currently the method accepts userId and password in the web method as authentication. I'm not sure that is secure enough. Is there an attribute or a better method to implement the
I publish the web service as a separate application on IIS 7. So, how do I can I have SSL encryption for a web service? For a site, I just bind to a 443 port with a SSL cert but how do I do this for a web service?
Dec 08, 2016 06:20 AM|Chris Zhao|LINK
To build secure services, you will identify your security objectives; identify your threats and vulnerabilities; apply principles, patterns, and practices; and use security engineering techniques throughout your application life cycle. For more information,
see the following resources:
Simple Web Service Authentication
Web Service in ASP.Net (Security by SOAP Authentication)
HTTP Security and ASP.NET Web Services
Dec 13, 2016 11:21 PM|Taichung|LINK
Hi, The last link could have been very useful and is what I'm looking for except it's not written for IIS 7 on Win2008R2 server. I followed the instruction but can't find the Property menu item as it indicated in the article.
My web application and the web services are 2 different projects that I published to the IIS7. There is a binding option where I can select and configure SSL for a website application but how can I do that for the web service application that I published
to the IIS? Also, the web service application is not bind to a domain then how can users call the web service3?
Dec 14, 2016 08:30 AM|Chris Zhao|LINK
To configure Secure Sockets Layer (SSL) for a site in IIS 7, you could follow these steps.
Dec 14, 2016 08:58 AM|PatriceSc|LINK
Also for now the problem is a bi obscur. A web service is basically just a web site except that rather than process browser requests and returning HTML content for human consumption it process http requests coming from clients and returns a payload with
data processed by the client.
So I'm not sure why you can configure properly the web site you published but can't for your web service. This is just another web site..
Dec 14, 2016 09:08 AM|navneetmitawa|LINK
Dec 15, 2016 05:42 PM|Taichung|LINK
Hi, The website application are in the same solution but in 2 different project in VS2013. My bad for publishing to our Dev IIS server under Default web site so they're both just published as web applications under the default website.
I now copy over the published just the Web service application files to our Prod IIS 7, I can't publish using Web Deploy because Prod server has dual authentication using DUO and VS2013 Publish option doesn't seem to accommodate this yet.
So, now that the web service is published as a web site but it's just a web service application, do I need a domain name for it? I prefer not. So when I generate the CSR for the web service what should I put for the CN, FQDN? Do I just put in server FQDN/webServiceName
(no asmx extension)? Currently i have it bind to port 80 and I can access it using "FQDN/webServiceName.asmx"
The methods in the web service will validate the userid and password that callers pass in when calling. With SSL installed and credential validated, will this be enough to secure the web service? Oh, I can also configure the Domain and IP range access
limitation on IIS too. Will this be suffice?
Dec 16, 2016 04:27 AM|navneetmitawa|LINK
Yes it's enough to secure a web service which is run over HTTPS(secure channel) and with authentication.
If you want to publish web service in locally then doesn't need any domain but if you want to run over network then it must be you
have one static ip or domain for hosting web service.
HTTPS secures the transmission of the message over the network and provides some assurance to the client about the identity of the server. This is what's important to your bank or online stock broker. Their interest in authenticating the client is not in
the identity of the computer, but in your identity. So card numbers, user names, passwords etc. are used to authenticate you. Some precautions are then usually taken to ensure that submissions haven't been tampered with, but on the whole whatever happens over
in the session is regarded as having been initiated by you.
WS-Security offers confidentiality and integrity protection from the creation of the message to it's consumption. So instead of ensuring that the content of the communications can only be read by the right server it ensures that it can only be read by the
right process on the server. Instead of assuming that all the communications in the securely initiated session are from the authenticated user each one has to be signed.
There's an amusing explanation involving naked motorcyclists here:
So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. I know it's a bit of a cop-out
but the decisions about how much protection is actually justified (not just what would be cool to build) need to be made by those who know the problem intimately.
Dec 20, 2016 07:02 PM|Taichung|LINK
Thank you, that makes a lot of sense.