I read that request SAP making HTTPS requests to REST service and is written : "For making HTTPS calls, you also need to import the certificate of your service provider into the system".
But what means with "service provider"? Who is the service provider in this context?
I have to make HTTPS calls to google maps using ABAP, but now it's not allowed to do it without API-KEY, I need to use HTTPS.
Your service provider is google for your maps api. You need to install google SSL certificate to SAP with STRUST t-code. Also HTTPS must be enabled for using it. Check below for example guideline:
https://wiki.scn.sap.com/wiki/display/SWAPI/Importing+StreamWork+SSL+certificate+into+ABAP+systems
Related
From my research I'm not getting an answer after referencing:
Custom SSL doesn't show when using CloudFlare
How to append SSL Origin Certificate with CloudFlare's Root Certificate?
Assets not loaded when using CloudFlare SSL
Cloudflare SSL issue: Request origin does not match request base_url
CloudFlare SSL refused on HTTP access
Wildcard SSL Certificates, Custom Domain Names, and Cloudflare
In my domain register I point my domain nameservers to Cloudflare and under Cloudflare's Crypto set SSL to Full. When I add the URL under Client ID for web application -> Restrictions -> Authorized JavaScript origins and Authorized redirect URIs should I be using HTTP, HTTPS, or both?
My understanding Cloudflare's SSL is a shared SSL and not a dedicated SSL. From Google's documentation I am unaware or able to find when using the Google Login API if the API will work successfully using a shared SSL.
The app is a web application written in Node using Google's Login API and hosted with a custom domain on Heroku. I am able to get the application to work locally and with Heroku's generated URL but I'd like to also implement Cloudflare I'm just unsure what is the correct way to use a shared SSL.
So to sum up, if I own the domain foobar.com in Google's Restrictions should I be using:
http://foobar.com
http://www.foobar.com
or
https://foobar.com
https://www.foobar.com
if the SSL is a shared SSL from Cloudflare?
It depends how do you want to expose your domain to users. Both protocols http/https can be allowed.
However you are trying to use "Google's Login API" = probably Open ID Connect client (SAML client is different), which needs encryption -> so actually, you need to allow only https protocol and then you will have safe configuration.
I want to call a third party web service from TIBCO BW6.X via SOAP over HTTPS by using basic authentication.
I can do it with SOAPUI just by adding authorization as a HTTP header with the key (like Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1) and it works fine. But using BW, I have to create an SSL resource with certifcates to use HTTPS.
My question is : Can I connect to a web service using HTTPS URL without SSL/certificates? If yes, then how? else, why can I do it with SOAPUI?
Thanks.
The answer depends on the soap client you are using. Basically you need just ignore the certificate validation as far as i interpret your question.
Example for php:
Disable certificate verification in PHP SoapClient
Say, for example, I have an Azure web app named MyApp and is hosted on Azure as MyApp.azurewebsites.net. It's my understanding that there is nothing I need to do to secure the URL with SSL, as it's done, by default, with a single certificate. So I can already have my users access the app via https://MyApp.azurewebsites.net, and it will be secure right out of the box.
However, say I have another URL named www.MyApp.com that I want to point (redirect) to https://MyApp.azurewebsite.net. Do I have to secure www.MyApp.com with a certificate?
Do I have to secure www.MyApp.com with a certificate?
Yes, we could get more detail info from the official document .
To secure your custom domain name with HTTPS, you bind a custom SSL certificate to that custom domain in Azure.
Before binding a custom certificate, we need to do the following:
Configure the custom domain - App Service only allows adding a certificate for a domain name that's already configured in your app. For instructions, see Map a custom domain name to an Azure app.
Scale up to Basic tier or higher App Service plans in lower pricing tiers don't support custom SSL certificates. For instructions, see Scale up an app in Azure.
Get an SSL certificate - If you do not already have one, you need to get one from a trusted certificate authority (CA).
Yes, if you use a custom host name, then you will need to have a certificate for it. There is really no way around this, based on how SSL works.
Background:
I'm trying to use WSO2 ESB within a corporate setting to provide authenticated access to underlying REST API backend providers located either within the enterprise, or on the internet.
My goal is to selectively grant access, e.g. to REST API provider P1 only to REST client C1 and to to REST API provider P2 only to REST client C2.
Using WSO2 ESB with the "<api>" as described into http://wso2.com/library/articles/2012/10/implementing-restful-services-wso2-esb/ seems to impose to redefine every resource, which can be very large and error prone for complex APIs (e.g. vmware vcloud director REST API https://www.vmware.com/support/vcd/doc/rest-api-doc-1.5-html/landing-user_operations.html)
Using the WSO2 ESB "<proxy>", as described into
https://docs.wso2.org/display/ESB481/Using+REST+with+a+Proxy+Service#UsingRESTwithaProxyService-RESTClientandRESTService ("REST Client and REST Service") imposes that the URIs exposed to HTTP clients will be modified modified w.r.t. to the original backed uri. Typical proxy URIs will be of the following form with the services prefix and a specific port http://<wso2_host>:8280/services/CustomerServiceProxy/customers/123
While having modified exposed URIs is fine when the client can be controlled (typically an in house custom REST API). It is problematic when the REST API is an industry standard and the client is an SDK, or an off-the-shelf application which is outside of the control of WSO2 users (e.g. AWS S3 API, or vmware vcloud director REST API)
In addition, some custom clients/SDKs may verify server-side SSL certificates against a public key embedded into the SDK/client.
The usual solution to preserve the HTTP REST API as-is and add some authentication on top of it is to expose the API through an HTTP proxy (possibly authenticating clients through HTTP proxy authentication), i.e. client send a CONNECT request prior to sending their original request. This preserves the full URIs and also the SSL certificates.
Question:
Is there a way to have WSO2 ESB play the role of an HTTP(S) proxy for mediating incoming REST API requests, preserving original URIs and server SSL certificates ?
I'm thinking about a new "<http-proxy>" syntax, I haven't yet spotted. I.e. it would listen to http://<wso2_host>:3128/ and respond to CONNECT requests. The mediation would then have the ability to accept or not the CONNECT depending on the CONNECT request inputs (proxy authentication, requested host), and other http transport headers). Once the CONNECT request is granted, it might even be possible to act on subsequent individual proxified requests
Best specs describing the CONNECT behavior seem https://datatracker.ietf.org/doc/html/draft-luotonen-web-proxy-tunneling-01 (1999 draft that seems adopted) and https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p2-semantics-22#page-29 proposed standard.
For HTTPS URI, there might be limited ability within the WSO2 mediation: the HTTP request is SSL encrypted and only the domain can be known if SNI (Server Name Indication) is specified in the request. At least this would enable to grant/deny some host names to a set of clients depending on proxy authentication.
You may wish to try the <property name="preserveProcessedHeaders" value="true"/> in your <inSequence>. This property will pass all security headers through the proxy. I'm not sure about server certificates.
Here is an example of that property in use:
https://docs.wso2.org/display/ESB481/Sample+153%3A+Routing+Messages+that+Arrive+to+a+Proxy+Service+without+Processing+Security+Headers
I hope tlevel for API usehat helps. You may also want to look into the wso2 API manager, which lets you selectively grant access to APIs.
I would like to implement REST APIs with the OAuth protocol for my web service. However I noticed that you must send datas over the internet that give the correct permissions to users.
The question that arose spontaneously is: how much is it insecure to send data without an HTTPS connection?
Any data not sent over https is ripe for being collected by some third party router between the web server and the end client.
Incidentally, you can use HTTPS with RESTful services.
Using OAuth 1.0 or 1.1 without HTTPS may well be insecure (although it was made to be used this way because of extra precautions taken when getting tokens and authorisation), but using OAuth 2.0 (the one used by facebook and most stuff now-adays) if totally insecure and actually goes against the specification for OAuth 2.0
It should be used and accessed over a HTTPS connection.