1

I'm trying to get PingAccess set up as a proxy (let's call the PA host pagateway) for a couple of applications that share a Web Session. I want all access to come via the PA pagateway and use HTTPS, but the back end systems are not HTTPS.

I have two sites defined, app1:8080 and app2:8080. Both are set to "secure" = no and "use target host header" = yes.

I have listeners defined on ports 5000 and 5001 that are both set to "secure" = yes.

The first problem I found is that when I access either app in this way (e.g. going to https://pagateway:5000), after successfully authenticating with PingFederate I end up getting redirected to the actual underlying host name (e.g. http://app1:8080), meaning any subsequent interactions with the app are not via PingAccess. For users outside the network they wouldn't even be able to do that because the app1 host wouldn't even be visible or accessible.

I thought maybe I needed to turn off "Use target host header" to false but Chrome prompts me to download a file that contains NAK, ETX, ETX, NUL, STX, STX codes, and in the PA logs I get an SSL error:

2015-11-20 11:13:33,718 DEBUG [6a5KYac2dnnY0ZpIl-3GNA] com.pingidentity.pa.core.transport.http.HttpServerHandler:180 - IOException reading sourceSocket
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
    at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
    ...

I'm unsure exactly which part of the process the SSL error is coming from (between browser and pagateway, or pagateway and app1). I'm guessing maybe app1 is having trouble with the unexpected host header...

In another variation I turned off SSL on the PA listener (I also had to change the PingAccess call-back URL in the PingFederate client settings to be http). But when I accessed it via http://pagateway:5000 I got a generic PingFederate error message in the browser and a different error in the PA logs:

2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:148 - Invoking request handler: Scheme Validation for Request to [pagateway:5000] [/]
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:200 - Exception caught.  Invoking abort handlers
com.pingidentity.pa.sdk.policy.AccessException: Invalid request protocol.
    at com.pingidentity.pa.core.interceptor.SchemeValidationInterceptor.handleRequest(SchemeValidationInterceptor.java:61)

Does anyone have any idea what I'm doing wrong? I'm kind of surprised about the redirection to the actual server name, to be honest, but after that I'm stumped about where to go from here.

Any help would be appreciated.

Ian
  • 4,227
  • 18
  • 19
ChrisC
  • 2,393
  • 2
  • 18
  • 24

2 Answers2

1

Have you contacted our support on this? It's sounding like something that will need to be dug into a bit deeper - but some high level suggestions I can make:

Take a look at a browser trace to determine when the redirect is happening to the backend site. Usually this is because there's a Location header in a redirect from the backend web server that (by nature) is an absolute URL but pointing to it instead of the externally facing hostname.

A common solution to this is setting Target Host Header to False - so it will receive the request unmodified from the browser, and the backend server should know to represent itself as that (if it behaves nicely behind a proxy).

If the backend server can't do that (which it sounds like it can't) - you should look at assigning rewriting rules to that application. More details on them are available here: https://support.pingidentity.com/s/document-item?bundleId=pingaccess-52&topicId=reference%2Fui%2Fpa_c_Rewrite_Rules_Overview.html. The "Rewrite Response Header Rule" in particular will rewrite Location headers in HTTP redirects.

FYI - The "Invalid request protocol." error you're seeing at bottom of your description could be due to a "Require HTTPS" flag on your defined Application.

Scott T.
  • 6,152
  • 1
  • 26
  • 32
  • Thanks @Scott T. I haven't contacted support yet as we're on the trial licence, orders are in progress and prod support kicks in on 1st December. With "Use Target Host Header" enabled the browser trace shows a redirect to `https://pagateway:5000/webapp`, followed by a redirect to `http://app1:8080`. If I turn off "Use Target Host Header" it shows the same redirect to `https://pagateway:5000/webapp`, followed by a redirect to `http://pagateway:5000/webapp`. The problem here is that the PA listener is expecting HTTPS but because it's doing a redirect from HTTPS to HTTP it fails. – ChrisC Nov 22 '15 at 21:35
  • Thanks for the tip on the URL response rewriting - if I leave the "Use Target Host Header" enabled and put in a URL rewriting rule it successfully handles the protocol change between HTTPS and HTTP and also leaves the browser pointing to the PA proxy! I will still follow up with Ping support though because I think there's something a bit funky with this - it shouldn't take a rewriting rule to make this work. – ChrisC Nov 22 '15 at 21:49
0

Do you have the same issue if you add a trailing slash at the end (https://pagateway:5000/webapp/)? Your application server will rewrite the URL based on what it thinks is the true host. This is to get around some security related issues around directory listing.

Which application server are you using? All app servers are unique, but I'll provide instructions on how to resolve this with Tomcat.

  1. Add a global rule that forces the application server to use the external facing host name. Here is a sample Groovy script:

def header = exc?.request?.header;

header?.setHost("pf.pingdemo.com:443");

anything();

  1. In Tomcat's server.xml, add scheme="https" to the connection:
<Connector port="8080" protocol="HTTP/1.1"

           connectionTimeout="20000"

           redirectPort="443" scheme="https" />

Cheers, Tam

Tam Tran
  • 1
  • When I say "add a global rule" I mean "Add a global PingAccess rule to the application" – Tam Tran Nov 24 '15 at 06:50
  • Hi Tam, from what I can tell the trailing slash doesn't seem to change the behaviour. In fact the trailing slash seems to disappear when the PingAccess callback URL responds with a redirect, e.g. an initial request with `/webapp1/` becomes `/webapp1` from the PA callback. Also isn't your Groovy script effectively doing the same thing as leaving the "Use Target Host Header" box unticked? I agree though, it seems that either the underlying app server needs to be HTTPS or I need URL and response rewriting rules to do the mapping. – ChrisC Nov 24 '15 at 22:42