I followed the tutorial deploy and run Service Stack application on Ubuntu Linux and I got my API quickly up and running. So far it's all plain-text though. I'd like to secure the API with SSL, especially the service receiving username and password, but maybe everything.
I'm using the regular CredentialsAuthProvider together with JwtAuthProvider at the moment, if it's relevant. Using a 3rd party OAuth2/OpenID Connect would solve the login problem, but not securing the remaining contents.
Also wonder how to selectively choose which services require SSL.
The stack is: mono, nginx and HyperFastCGI (and C# ServiceStack)
You'll want to configure SSL on nginx, i.e. your external-facing Web Server. What ASP.NET Web framework you're using is irrelevant as SSL will be terminated at nginx and any downstream Web Applications will still be receiving plain-text requests.
Related
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
I am working with CoAP protocol on IoT but also I need a web service. I implemented the web service on Apache with HTTP protocol and a Proxy that converts CoAP-HTTP request and responses. But I don't want to use the Proxy to convert CoAP-HTTP. I want to implement directly CoAP web service. Do you have any idea about that. On Apache or different things. Just any idea?
As you wrote On Apache or different things, I will here talk about the second option :). To implement the CoAP server itself, I would recommend either
NodeJS with the CoAP package
Java implementation Californium, from Eclipse.org
More complete list available at http://coap.technology/impls.html#server-side, see Server-side
And then handle the communication with your Apache HTTP server via WebSockets and REST APIs.
coap.me is also great to run tests during development.
If SSL is handled by a load balancer, do I still need to configure it in the WCF serviceCertificate node? My scenario is to use message level security. If someone can explain how load balancing with wcf and ssl works, that would be very nice.
WCF requires security tokens to be passed over a secure transport if the message itself is not signed/encrypted. Since traffic is HTTP between your Big-IP and your individual web servers, you need a way to have security tokens that you know are secured between the client and the Big-IP up front still be passed to your server farm. There's a couple ways to do that depending on what version of WCF you're using:
If you're using WCF 4.0 you can just create a custom binding and set the AllowInsecureTransport property on the built in SecurityBindingElement to signify that you don't care that the transport isn't secure.
If you're using WCF 3.5 you have to "lie" about security with a custom TransportSecurityBindingElement on the server side. You can read my old post about this here.
FWIW, they created a hotfix release for 3.5 SP1 that adds the AllowInsecureTransport to that version, but I don't know if your company will allow you to install custom hotfixes.
If you want to use message security then each message is encrypted and signed separately - there is no secure connection and load balancer behaves as with any other HTTP transport. Loadbalancer doesn't know about security and doesn't need certificate.
There are two gotchas:
All load balanced application servers hosting your WCF service must use the same certificate
You must ensure that your WCF binding doesn't use sessions (reliable, security) otherwise you will need load balancing algorithm with sticky sessions (all request for single session always routed to the same server)
It doesn't. Don't bother with this. You will be in a world of hurt. Just install the certs on each machine. We've recently been through this fiasco. WCF is not worth the effort it thinks it needs SSL but sees that it doesn't have it. Take a look at openrasta or something else if you want to do all your SSL on the loadbalancer. #microsoftfail
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?
Here is my scenario:
I have a proxy that actually has the SSL Cert installed and this sits in front of a load balanced web farm. Each IIS server does not have SSL so I can't use transport security via wsHttp binding. I have not investigated basicHttp because we want to provide SOAP 1.2 going forward w/ this solution. In addition to this, my network team won't allow any use of certs to encrypt at the message level. (this alone would solve my dilemma i'm sure)
My security group has a requirement that we use Forms Authentication (membership provider).
The final solution must allow SSL via the front proxy, yet some type of WCF binding to keep complexity encapsulated in a config file.
I was working with a custom binding that allowed for username/password sent via clear text, but when I try to connect via https i get the usual "http expected" uri error.
How can I use SSL via the proxy to connect securely from client app to web service, but not have SSL installed on IIS and leverage the WCF stack + forms authentication?
I'm not new to WCF, but this very custom setup seems to have me unsure if the requirements allow for any type "easy" solution.
Thank you in advance!
EDIT: I did finally get this working and decided to write a short blog post with complete source code required to write the custom binding.
I think this is similar to a problem many have had when wanting to provide WCF services over SSL when the actual service in IIS is behind an SSL-offloading device. In which case, the following two pages should help you out:
http://blog.hackedbrain.com/archive/2006/09/26/5281.aspx
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/87a254c8-e9d1-4d4c-8f62-54eae497423f/
Basically you need to lie to WCF and say that the service is secure, even though the traffic will be conducted over HTTP (between the service and the proxy).