Just have a quick a question regarding best practices.
I am connecting to a 3rd party api via soap over HTTPS.
To do this I have simply added a service reference to my application by entering the 3rd party wsdl address.
In my C# application I have simply instantiated the service passed in my api key and can successfully retrieve data.
I am aware that this would of failed if the servers ssl certificate didn't meet the following requirements.
the URL in the certificate matches the URL I'm posting to
the certificate is valid and trusted
the certificate has not expired
However, is this secure enough? Is it possible for the ssl certificate to be hijacked or faked? Do I need to store a copy of the valid certificate locally and check the server certificate against the local copy?
Thanks
Ant
Related
I want to import the wsdl from some private server on azure. They (server owners) have issued us a certificate and also have whitelisted the outbound IP's of my Azure service. I added private key certificate on my Azure service.
After that I followed this article and created a new API management instance and tried to import the wsdl file from their server URL but its giving me following error "Unable to download specified file. Please ensure the URL is valid and file is publicly accessible."
It was quiet easy if I had a VM and with whitelisted IP's. I could've used SoapUI testing tool on the whitelisted IP machine in which I can provide the p12/pkc certificate as well, but I'm not able to do it on azure. Any help will be appreciated!
Since only the outbound IPs of your App Service have been whitelisted, the request to the private server can only come from there. Both APIM (and the CORS proxy used to load the WSDL) have different IPs.
One way to approach this would be to have a simple proxy app on your App Service which proxies requests to the private server (with some security of course) and use that URL to load the WSDL. Also, in APIM, you would have set the backend of your imported API to the proxy endpoint.
Another approach would be to whitelist your APIM IP instead but loading the WSDL would still fail because of the CORS proxy used. In this case, you could either
Acquire the WSDL file manually and upload it
Create an API in APIM which just returns the WSDL
Also, do note that the outbound IPs for both APIM and App Service may change with specific configuration changes.
It's been a week already and I'm still not fully comfortable with implementing ASP.NET Membership Provider with WCF. I'm wondering:
We already have a website which is running under HTTPS protocol. We are working on a new application which will have a WCF service and is going to replace our old application (with HTTPS). Now my question is, since we already have a secured website, do I have to get another certificate just for the WCF service?
If yes, then do I have to get certificates for clients as well? (As I was looking on the web, most of the answers I found were "yes".)
If no, can I use the existing certificate to authenticate my service?
To answer your 2nd question, you only need client certificates if you want your WCF service to support mutual (2-way) SSL authentication, in which both the server and client sides are authenticated by their respective certificates.
Refer to this question for further information on mutual ssl and wcf.
how to implement 2-way SSL certificate for WCF
You have to have 1 SSL Certificate per domain unless you purchase a wildcard certificate. So, if your current SSL Certificate is for subdomain.mydomain.com and you want to host the WCF service at anothersubdomain.mydomain.com (or even www.anotherdomain.com), then you'll need another certificate. If this is something that would happen fairly frequently, then I'd suggest you purchase a *.mydomain.com SSL certificate.
Another option would be to host the WCF service under the current subdomain with a URL like subdomain.mydomain.com\myservice\service.svc.
I can't answer your second question but I doubt you are using client side certificates.
Here's a link to a Beginner's guide on SSL Certificates.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.
Here is a scenario:
Desktop application
Installed from the web
Needs to call a WCF webservice
Transferred data needs to be encrypted from Client to Server and Server to Client
Is there a well understood solution for this that is:
Secure
Easy to manage and deploy
I guess what this comes down to firstly is whether https encryption happens in both directions... Does it? Or do you need mutual authentication for that?
Try using HTTP over SSL
HTTPS is what you're after - it does provide end-to-end encryption (client-to-server and server-to-client).
So long as you can generate and install a server certificate, and be sure that your clients 'trust' the issuing authority of your certificate, then you're good to go. Note that this is not mutual authentication - your clients know that they have contacted the correct server, but the server does not know who has contacted it.
It can offer mutual authentication through the use of client-side certificates, but I would argue that does not fall under the 'easy to deploy' requirement.
HTTPS works...
I was confusing Encryption with Authentication and they are two different things. Simple Https which is the most common only authenticates the server to the client which is sufficient in many cases. An additional step (where the client also has a certificate) can be required to authenticate the client to the server but this is not required. In both scenarios, data with Https is encrypted from both the server to the client and client to the server using a session key once the SSL handshake has been completed. This is all described here:
Description of the Secure Sockets Layer (SSL) Handshake
I'd like to use client certificates to verify the identity of administrative callers to my web service. Then I can issue certificates only to the people I want to call my web service and be pretty sure noone else can call it. This is in a very controlled scenario where only one or two people will get the client certificate, so distribution isn't a hard problem.
This article provides a good example of how to call a web service using a client certificate.
But how can I check details of the client certificate from within my web service? This old article talks about configuring IIS to do it, but I'd like to do it programmatically within my app. I think?
thanks for any suggestions!
The incoming Request has a ClientCertificates collection that you can interrogate -- you can check the various fields in the cert or check the actual raw byte data (perhaps against a datastore or other source) if you want to completely validate it.
Note, if you issue the certs from your own private CA, you will need to install the CA's cert on your webserver into a store that is visible to all users, otherwise IIS won't request those certs from the user (due to the nature of how the server/client interaction works.)