My application will capture private customer data, requiring secure access for my clients.
Is it possible to use HTTPS/SSL in Wakanda Cloud?
HTTPS/SSL is not a current feature of Wakanda Cloud. However, HTTPS/SSL is a feature of Wakanda Server when you host it yourself.
The Wakanda Cloud Roadmap is on Trello, which lists SSL/HTTPS Support as a proposed feature.
You can vote on proposed features at Trello.
You can also submit additional feature requests at Trello
HTTPS is available in the Wakanda Cloud. I have a medium instance using HTTPS right now.
Related
I am new to wechat development, as I can see from the documentation it requires setting up a server, getting a domain and ssl certificate. I am developing an app that sends a request to a server, fetches pdf file from database and downloads that file to user's phone. Since I am using pdf, I need to store binary data, so VPS hosting should be the best option here. But I am not sure if I can use it for WeChat, I noticed in most documentation and tutorials developers are using cloud services.
Of course.whatever serve provider is.
Would like to understand what is the difference between WAF and APIM (Like APIGEE or AZURE APIM).
What are capabilities of WAF and which needs to be choose to protect the backend web application.
Thank you in advance.
Aaditya
WAF protects your backend web server by stopping every request that having malicious values. Malicious requests can be SQL injection, Cross site scripting.
Modern WAF also protects server from blacklisted IPS (tor or bots).
You can also define rules like whitelist IP or regex match for parameters and header.
Regards,
Jaikey sarraf
Google Apigee plateform also has capabilities like whitelisting, security(OAuth, JWT, Basic and key based), CORS header and others.
I think that you should more focus on what kind of architecture you might need in order to support future requirement. As with Apigee, Google has great support for cloud as well(AWS, GCP and Azure) with support to almost all type of language and virtual target backend for complex mesh ups as well.
Apigee provides inbuild support for Analytics and Monetization services as well, which you might want to consider.
Apigee has 24X7 support for all your issue/concern for different level of environments.
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.
In APIM we need to have a key that a client knows about:
ocp-apim-subscription-key
What happens when traffic manager round robins to another server? Does the client need to know about the second subscription key?
Similar to Azure Traffic Manager and OAuth 2.0 , since Azure Traffic Manager operates at the DNS level, it is not a part of the client-server communication. Any authentication and key handoffs are transparent to Traffic Manager.
Please refer to https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#how-clients-connect-using-traffic-manager for more details
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.