I have WCF REST Service...
Client accessing this service and I can see from Request headers what is the host and Origin of this request to my service.
But this can be tampered and I want to restrict my service to clients if the request to my service is coming from specified origin/domain/url?
Related
I was considering shifting my back
end rest api microservices to grpc servers. I use tyk as the api gateway to route http requests. How does an api gateway handle grpc requests?
With gRPC-Gateway, you can generate a reverse proxy that would translate REST into gRPC call via marshaling of the JSON request body into respective Go structures followed by the RPC endpoint call.
The gRPC-Gateway is a plugin of the Google protocol buffers compiler protoc. It reads protobuf service definitions and generates a reverse-proxy server which translates a RESTful HTTP API into gRPC. This server is generated according to the google.api.http annotations in your service definitions.
I have following scenario:
The client request for web content to the web server.
But sometimes the client use data from SAP server and make an OData request to SAP server.
How to forward OData request from the client through the webserver to SAP server? Is it possible?
U can recreate the request to the SAP server in your own web server. As soon as the client triggers the request your web service triggers the sap request. The web server waits for the response from the SAP server and return this response to the client.
I have an issue using HTTPS to access an ASP.NET OData endpoint. The ASP.NET site is hosted via OWIN. I am using the NuGet package Microsoft.AspNet.WebApi.OData for the OData (v3) part. The SSL termination takes place outside of the server in a separate load balancer.
Accessing the OData endpoints with a REST-client (e.g. Postman) works fine: https://api.my-domain.com/odata/v3
But when I use an OData-client (e.g. Excel or PowerBI), the access fails with the generic message, that the host forcibly closed the connection.
Further I found that when I access the endpoint https://api.my-domain.com/odata/v3 via Postman, I receive some XML metadata, which refers to the normal http endpoint (see below snippet), which is blocked by the LB.
<?xml version="1.0" encoding="utf-8"?>
<service xml:base="http://api.my-domain.com/odata/v3" xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
...
Further I sniffed the traffic from Excel/PowerBI with Wireshark and found that the clients are using the normal http endpoint (as shown in above metadata) after the initial request with https. I am not familiar with the OData protocol details, but I guess the clients are determining the address by the metadata.
For validation I unblocked port 80 in the LB and voila, Excel/PowerBI can successfully connect, regardless if I use http or https for the initial request.
But how to solve this issue (I don't want to allow traffic on http). Is it possible to instruct the ASP.NET OData middleware to generate metadata with https URIs?
As the title explains, I want to see the http requests that are sent by my android app client to my Jersey Web service.
Also, I'm using
https://github.com/kevinsawicki/http-request
class for sending the requests, but I'm not sure if they are SSL encrypted. Can I see if they are encrypted by looking at the http requests that arrive at my Web service?
If you have access to the server on which your web service is running, you can use Wireshark : https://www.wireshark.org/
This will trace and decode the tcp/ip protocol for you, and indeed show you if it's encrypted under SSL.
Assuming you own the server, and have full access, you can also install the Private Key from your server into Wireshark, and it will then show you decoded SSL traffic.
So I'm trying to implement the following scenario:
An application is protected by Basic Authentication. Let's say it is hosted on app.com
An HTTP proxy, in front of the application, requires authentication as well. It is hosted on proxy.com
The user must therefore provide credentials for both the proxy and the application in the same request, thus he has different username/password pairs: one pair to authenticate himself against the application, and another username/password pair to authenticate himself against the proxy.
After reading the specs, I'm not really sure on how I should implement this. What I was thinking to do is:
The user makes an HTTP request to the proxy without any sort of authentication.
The proxy answers 407 Proxy Authentication Required and returns a Proxy-Authenticate header in the format of: "Proxy-Authenticate: Basic realm="proxy.com".Question: Is this Proxy-Authenticate header correctly set?
The client then retries the request with a Proxy-Authorization header, that is the Base64 representation of the proxy username:password.
This time the proxy authenticates the request, but then the application answers with a 401 Unauthorized header. The user was authenticated by the proxy, but not by the application. The application adds a WWW-Authenticate header to the response like WWW-Authenticate: Basic realm="app.com". Question: this header value is correct right?
The client retries again the request with both a Proxy-Authorization header, and a Authorization header valued with the Base64 representation of the app's username:password.
At this point, the proxy successfully authenticates the request, forwards the request to the application that authenticates the user as well. And the client finally gets a response back.
Is the whole workflow correct?
Yes, that looks like a valid workflow for the situation you described, and those Authenticate headers seem to be in the correct format.
It's interesting to note that it's possible, albeit unlikely, for a given connection to involve multiple proxies that are chained together, and each one can itself require authentication. In this case, the client side of each intermediate proxy would itself get back a 407 Proxy Authentication Required message and itself repeat the request with the Proxy-Authorization header; the Proxy-Authenticate and Proxy-Authorization headers are single-hop headers that do not get passed from one server to the next, but WWW-Authenticate and Authorization are end-to-end headers that are considered to be from the client to the final server, passed through verbatim by the intermediaries.
Since the Basic scheme sends the password in the clear (base64 is a reversible encoding) it is most commonly used over SSL. This scenario is implemented in a different fashion, because it is desirable to prevent the proxy from seeing the password sent to the final server:
the client opens an SSL channel to the proxy to initiate the request, but instead of submitting a regular HTTP request it would submit a special CONNECT request (still with a Proxy-Authorization header) to open a TCP tunnel to the remote server.
The client then proceeds to create another SSL channel nested inside the first, over which it transfers the final HTTP message including the Authorization header.
In this scenario the proxy only knows the host and port the client connected to, not what was transmitted or received over the inner SSL channel. Further, the use of nested channels allows the client to "see" the SSL certificates of both the proxy and the server, allowing the identity of both to be authenticated.