I am using Sustainsys.Saml2 for authentication in my environment. It has worked well until I added a proxy into the loop.
The data flow is:
1) User navigates to site via proxy server (example.mysite.com)
2) Proxy forwards to internal application (example.internal.mysite.com)
3) Saml does its thing, forwards to service for authenticate and redirect
step
4) Weird part: The saml response is sent back to the original host hitting Saml2/Acs (example.mysite.com/Saml2/Acs) and responding as a 303 -- the assumption is that it should be 303'ing to example.mysite.com, but instead it's to the proxy host name at example.internal.mysite.com
Why is it doing that? It doesn't seem to be respecting the ReturnUrl (which is example.mysite.com). I see no evidence of the proxy URL from requests/responses during the auth process until #4.
The Sustainsys.Saml2 library builds various URLs from what it sees in the incoming HTTP Request. When a proxy is involved, that might not be the same URL as the client sees.
There's a setting PublicOrigin that you can set to handle this, that will override any host found in the request.
However, in The AspNetCore2 handler it is assumed that this has already been fixed in the Request object, before the handler is invoked. This is usually done automatically by the hosting environment if hosting in Kestrel behind IIS or similar.
Related
I have an Angular web app running on Cloud Run (nginx webserver) (more info here) from which I want to get access token from the GCP metadata server. I have tried to make a call to https://metadata.google.internal ( using curl from Cloud Shell) but the connection was rejected. Calls to HTTP are working well.
When I make the call from my app (which is loaded over https) to the metadata server over HTTP - logically I get a mixed content error. When trying to access the metadata server over HTTPS - I am getting error 504 Gateway timeout, I assume due to the reason that the metadata server refuses the calls on HTTPS.
I will really appreciate any idea of how to solve this issue.
The URL endpoint metadata.google.internal is only accessible from inside the instance (Cloud Run). This endpoint is not accessible outside of the instance such as via an HTTP or HTTPS call. A clue is the TLD (Top Level Domain) internal.
If you want to access this endpoint remotely via a web browser, you will need to make a request from the browser to Cloud Run (an endpoint in your code) which then makes the internal request to the metadata server and returns the response to the client.
I am trying to change the hub connection url in signalR so that all requests go through my custom load balancer.
The load balancer then redirects to original signalR web application and gives the response.
For this i am trying to create a new hub connection by changing the url like this
var signalR = $.signalR;
signalR.hub = $.hubConnection("http://localhost:64071/LoadBalancer.Web/NotificationWeb/signalr", { useDefaultPath: false });
The signalR tries to connect to this URL and in the negotiate request returns this response
{ "Url":"/WE.abcd.Web/signalr", "ConnectionToken":"raYdZtwHWMP50fYIxa4MxRtR8xZAmUhhdlXreYVlB3Meo+2VeZSk4wMEdbkCbVEAzo/+gFyNofqV ......
Then as you can see in the response, the URL contains original URL (i.e. WE.abc.web) so the communications happens directly to WE.abcd.Web instead of passing through my Load Balancer. Web even after overriding the URLs.
How can i force the negotiate request to return me the LoadBalancer.Web URL instead of original URL?
I think as long as SignalR is generating negotiate response URL using Request.LocalPath only solution is to load balancer modify negotiate response (rewrite URL) before returning it back to client. That's how reverse proxies work.
It should be possible to do that without changing load balancer code just using IIS URL Rewrite functionality
Sidenote: I don't know nothing about your requirements\production environment but if load balanced sites (hosting SignalR) are accessible from clients (not hidden behind firewall\proxy), described behavior is totally fine. As long as load balancer is balancin negotiate requests between all servers, it does't matter that subsequent connection request bypass load balancer - clients are still balanced. + less trouble as you don't need to balance Web sockets connections...
I have an IIS-hosted, WCF web service deployed on a UAT web server. In IIS, I have site bindings on this same web service--one for internal access (Ex: uat-nodotsinternalonly) and one for external access (Ex: mysvc.uat.mydomain.com).
When I use SoapUI to test against the internal host name (http://uat-nodotsinternalonly/MyService.svc), it calls the service and returns the response envelope as expected.
When I use SoapUI to test against the external host name (https://mysvc.uat.mydomain.com/MyService.svc), it calls the service and returns the WSDL HTML as would be seen in the web browser instead of the response envelope as expected.
We need to expose past our firewall for testing with a vendor. Our external client can browse to our web service using the external host name and receive the WSDL back in their web browser, but when they call it, it fails with a 302 error.
I’m far from an expert on security, but I believe our firewall is handling the security then forwarding over http to the UAT server. The redirect and variations seem as though there’s something to change in how DNS is managed or settings in IIS. Does anyone have suggestions as to how to narrow it down so that the call to the external service will work?
We too had a WCF service that in SoapUI was returning the WSDL HTML instead of the expected response when invoking a method. This was an SSL-enabled service, and the solution in our case was to edit the endpoint URL after creating the request so that it used https instead of http. This is because we found that for some reason it defaults to http even when you initially specify https when creating the request. Here's how to edit the endpoint URL in SoapUI:
In the request window, click the drop-down arrow on the URL.
Select [edit current..]
Change http to https, and then try your request again.
The problem with the client getting a 302 error was because the client was not sending a SOAP request envelope to our web service. The client was just sending XML.
Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx
I have developed an application with JSP and Flex. In that Flex application interact JSP with HTTP service. I deployed application in one server that server URL is with HTTP it is working fine. But when I deployed this project in another server (HTTPS) the application is not running. There in JSP session is not handled. Is there any server configuration whicn needs to be checked?
I have no idea what you're talking about with "session is not handled". Please elaborate the problem in developer perspective, not in enduser perspective. What exactly happens? What exactly happens not?
I can at least tell that sessions are usually backed by cookies. Cookies on its turn are usually bound to a specific domain and path. Cookies are not dependent from the protocol used. Roughly said, if the webcontainer has created a cookie to track the HttpSession, it will by default use the request.getServerName() as cookie domain and request.getContextPath() as cookie path.
So if you for example have this webapplication on http://example.com/context, then the cookie will be created for host example.com and path /context. Regardless of the protocol. But when you fire a request on http://example.com/anothercontext, then by default you won't get the same cookie back and thus also not the same session.
However, most webcontainers provides configuration options which can influence the cookie host and path. Tomcat, for example, supports an emptySessionPath attribute in the HTTP connector which causes that the cookie path is always /. This way the http://example.com/context and http://example.com/anothercontext will be able to share the same cookies and thus also the session.
This knowledge of how it all works "under the hood" must give a better understanding of your problem and thus also ease nailing down of the root cause.