I have a standard C# Web Api running on IIS that has a custom AuthorizeAttribute to properly authorize calls via a key in the request header variables. Recently, one of my clients calls to the API over SSL have started to fail with an 403 Forbidden error. He is successful when calling the non-SSL url.
The same call - same url, api key etc. works perfectly over SSL from my machine, and none of my other clients are having any issues with this. What could possibly be the issue for this specific client? I have checked some basic things like his client machine time settings etc. are all in order, not sure if this could be some kind of certificate related issue?
try the following:
1- check the proxy on his machine
2- since SSL is used to protect data and safety the data should not change in the way on the server. it could be changed by a virus on the machine (I have the same problem with one of my clients) make sure his system is clean
3- consider calling the API in other ways like (postman, browser, ...)
according to what you write clearly, there is something wrong with his machine. if you find the problem It would be nice to tell me too
Related
I've written a simple WebAPI Service (hosted with OWIN in a Windows Service) and put the [Authorize] attribute on the POST-method. As I understand, only "known" users can now access the service (don't worry, I know, all known users is not really safe yet).
My test client works fine so far when the host and the client are located on the same machine (f.ex. my workstation). However when I deploy the service on a server machine, and try again to call the service, I get a HTTP 400 failure when using the System.Net.Http.HttpClient and set httpClientHandler.UseDefaultCredentials=true, or a HTTP 401 when I use System.Net.WebClient and set webClient.UseDefaultCredentials=True.
So it seems the authentication mechanism acts different depending if the service is hosted local or remote.
For test reason I've also tried to set the credential explicit with user and password, but with exactly the same result.
However, what do I miss here? Any suggestions?
Thank you in advance!
verify the machine keys.
If the authorization server and the resource server are not on the same computer, the OAuth middleware will use the different machine keys to encrypt and decrypt bearer access token. In order to share the same private key between both projects, we add the same machinekey setting in both web.config files.
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
In .Net web-service hosting the IIS and used for the desktop application while login the app the person track and see all the input calls to service and response back into app.
Then analysis the issue and go through google and got solutions. to make HTTPS or ssl in webservice url.also encrypt and decrypt also doing both client and server side.
after that i check with fiddler they also tracking the web services call and responses .even they can able to break and run the app using this.
I was tired and make the protect the webservice calls. and unable to achieve the what i need.
I also attached screenshot below for your reference.
Guys plz help me...if any otherway to protect the service calls in Fiddler.
I see no screenshot. But if I understood correctly then you are saying that fiddler can decrypt your traffic.
Well that is because fiddler imports fake certificates into windows certificate store and then proxies data through itself. That is why it can actually decrypt data. I don't really see a point to try to protect web calls from Fiddler. But you can force direct connection and try not to use proxies with your application. But then again... you won't be able to use any proxies
We have self-hosted C# WCF service providing rest API over HTTPS.
Problem:Configuring the certificates for SSL requires admin rights. I assume it is to do with WCF depends on http.sys for http/https handling. The service is meant to be deployed on customer environments. So it would be nice if it can run without requiring admin rights.
Looks like WCF depends on http.sys,
Can I self-host an HTTPS service in WCF without the certificate store and without using netsh http add sslcert?
Like to know if any other embedded web server solution exist that support SSL and not requiring admin rights on the machine?
Checked so far,
http://nancyfx.org/
https://github.com/pvginkel/NHttp
Both doesn't seem to support SSL.
Most windows hosted web stacks rely on the HTTP Server API which is the API around the kernel HTTP stack (a.k.a HTTP.sys). The .Net HttpListener class does so as well (same as WCF, the OWIN self hosted asp.Net and so on which rely on it).
Just making sure, you do know you can authorize the identity you application runs under to bind to an HTTPS URL even if it's not running as an admin account, right? If you could gain admin right just for the installation phase that could solve you problem? (assuming you checked that already)
You can read more on a blog post i wrote about that here
To go into the effort of building an http stack on top of raw sockets would be a great effort and with little gain and so around .Net i doublt you would find anything like that.
Unless, it wished to be cross platform.
Any java based web server would probably do just that, using the JVM's http stack and relying on a java keystore to provide the required certificates for the SSL. (To keep it portable across different OS's)
If you wanna go java i am sure you can find many such web servers.
If you care to try and bind to a web server using CGI have a look at mongoose (Never used it to be honest).
Another option which comes to mind is to use an ssl proxy like Stunnel to stand in front of the web server. It would do the SSL part using non-windows certificate store.
I am building a client program that interacts with a WCF Service via Internet. Everything works as intended but I am wondering how I can protect my services so that only my client program can make use of it?
Right now everyone with the correct URL to my services can use it with WCFTestClient (e.g).
What is the best way to make it private so only my clients can make use of the service? Rotating token strings? Certificate? Password?
I have no idea and haven't found anything useful on the Internet.
Best regards
UPDATE: The client program is intended to be downloaded for the public (everyone). So it is not for internal use, it will be a service we are gonna provide, ones in official production.
My own thinking was like: Bind a certificate in my client programs (if thats possible even?). On the IIS where the WCF service is running, check for valid certificate. Is that possible? Or better solutions out there?
Protect .net Web Service URL
Along with the other answers, that can't be bad too,
and if you want to be super careful you can implement a token system, where the clients get the first token from you, each request returns a new token, and you always check a client vs it's current token (but that's being over careful in my opinion)
Update - because it's for the public, the client can have a way of generating a valid token to check on the server, you can have a token be valid for an interval of seconds, so even if people caught the request and found the token, it will not be valid after ..15 seconds or 30,etc
If you are using Form Authentication then you can leverage the ASP.NET to check for FormAuthentication Cookie by enabling AspNetCompatibilityRequirementsMode to Required
Or if your service is stand alone i.e is consumed by everyone then you can use oauth authentication you can read more about it Oauth Authentication
What you could do is there would be a consumer secret key which would be shared to all authenticated clients. The caller would sign some info using this key and server would also sign it using the same key and then compare it.
Hope it helps
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.