Proxy not forwarding after SAML Response about saml-auth-proxy

[ohaya]

Hi,

Here is the saml-auth-proxy command line that he is using to test:

./saml-auth-proxy_1.9.0_linux_x86_64  \
        -base-url https://${BASE_FQDN}:8080  \
        -backend-url https://pxy.west.int.XXXX.com:8443/f5_test.html \
        -bind ${BASE_FQDN}:8080  \
        -name-id-format persistent \
        -sp-cert-path /home/users/dm01/samlTest/il_cert.pem \
        -sp-key-path /home/users/dm01/samlTest/il_key.pem \
        -idp-ca-path /home/users/dm01/samlTest/il_cert.pem \
        -idp-metadata-url=file:///home/users/dm01/samlTest/access.YYYYY.int.XXXX.com.xml \
        -authorize-attribute uid \
        -attribute-header-mappings UserID=x-webauth-user

This line:

       -backend-url https://pxy.west.int.XXXX.com:8443/f5_test.html 

Has the URL that they want to go to after the authentication is done.

Thanks,
Jim

[ohaya]

I did some testing, and what they meant by "not forwarding" what that the browser was being sent to:

-base-url https://${BASE_FQDN}:8080 \

which was causing the browser to do a request to:

https://${BASE_FQDN}:8080/saml/acs

BUT that 8080 port is NON-SSL.

So by "not forwarding" they meant they were getting an SSL error from the browser :(...

We have fixed that and are having another problem now (some problem with the cert in the IdP side, I think). I'm waiting to hear back.

Jim

[ohaya]

Still waiting, but did some more testing... here is what is happening:

• The browser is being sent to http://BASEHHOST:8080/saml/acs and then is getting 302/redirect to "//BASEHOST:8080/"

That is LITERALLY what I am seeing in the saml-tracer... the "http:" part of the URL is MISSING?

I will do some checking, but any idea what might cause that?

Jim

[ohaya]

I've checked the command line and it looks ok to me, so I don't know where that weird "//BASEHOST:8080" URL is coming from?

we have the -bind parameter as I posted above:

-bind ${BASE_FQDN}:8080 \

so I don't understnad why it is redirecting to a URL that is missing the "http:" part of the URL?

BUT then in saml-tracer I see the next request as a GET to "http://BASEHOST:8080", which then causes a 502/bad gateway response, AND the browser shows the following message:

Get "https://https://pxy.west.int.XXXX.com:8443/": x509: certificate signed by unknown authority

And that ends it.

Any ideas why that request would cause the 502 error?

Jim

[itzg]

Looks like the use of base-url and backend-url is flipped. Browsers will only know about base-url. The backend-url refers to the internal network.

[ohaya]

Hi,

I don't understand what you said. Can you clarify?

Thanks,
Jim

[itzg]

Here's a diagram I'll include in the docs at some point:

So

• -backend-url has nothing to do with ${BASE_FQDN}
• -bind has nothing to do with ${BASE_FQDN}
• -base-url should be the one that is like https://pxy.west.int.XXXX.com:8443

[ohaya]

Hi,

So:
re. -bind:
- if 0.0.0.0 that mean proxy listens on all IPs that the machine that the saml auth proxy is running on, correct?
- could also be [IP ADDRESS OF MACHINE SAML AUTH PROXY IS ON], correct?
- examples: 0.0.0.0:8080 or 1.2.3.4:8080 ??

re. - backend-url
- I don't understand what "private URL" means?
- From your example, you had " --backend-url http://localhost:3000 " - so when you said "private URL" did you mean that the backend target has to be on the same physical machine (i.e., on "localhost") as the saml-auth-proxy is on?

re. -base-url
- You said "Should be browser-accessible address that DNS resolves to the host running saml-auth-proxy", but you also said "should be the one that is like https://pxy.west.int.XXXX.com:8443", but in our case, the saml-auth-proxy is physically on one machine, and the target/backend is on a completely different machine. This kind of goes back to what I mentioned above for backend-url, i.e., it seems that your assumption is that both the saml-auth-proxy and the proxied service are on the same physical machine?

Jim

[itzg]

Hi,

So:

-bind:

- if 0.0.0.0 that mean proxy listens on all IPs that the machine that the saml auth proxy is running on, correct?

- could also be [IP ADDRESS OF MACHINE SAML AUTH PROXY IS ON], correct?

- examples: 0.0.0.0:8080 or 1.2.3.4:8080 ??

Correct

• backend-url

  • I don't understand what "private URL" means?

It's the "resource" in this definition https://en.wikipedia.org/wiki/Proxy_server

- From your example, you had "  --backend-url http://localhost:3000 \" - so when you said "private URL" did you mean that the backend target has to be on the same physical machine (i.e., on "localhost") as the saml-auth-proxy is on?  

No, it can be anywhere. I would expect it to be typically in a private network so that people on the public network don't just skip the SAML authentication.

[ohaya]

I may have confused you with something in the parameters I posted earlier. The host with hostname "pxy..." is NOT the machine where the saml-auth-proxy is hosted on. Rather it is actually another machine where the target service is on. I am wondering/guessing if you interpreted that because the hostname was "pxy..." you might have thought I was referring to the machine where the saml-auth-proxy was hosted"?

With that in mind, then ""should be the one THAT IS LIKE https://pxy.west.int.xxxx.com:8443/"" still be the case? Or can backend-url the target URL, wherever the target is... even on a different machine?

And, BTW, you were correct, our networking would be such that the actual targets that the backend-url points to would not be directly reachable from outside our network.

[ohaya]

Here's where we are. I run the saml-auth-proxy using this command line:

./saml-auth-proxy_1.9.0_linux_x86_64  \
        -base-url http://ilwsvc01.XXXX.com:8080  \
        -backend-url https://pxy.west.int.XXXX.com:8443/f5_test.html \
        -bind 0.0.0.0:8080  \
        -name-id-format persistent \
        -sp-cert-path /home/users/dm01/samlTest/il_cert.pem \
        -sp-key-path /home/users/dm01/samlTest/il_key.pem \
        -idp-ca-path /home/users/dm01/samlTest/il_cert.pem \
        -idp-metadata-url=file:///home/users/dm01/samlTest/access.YYYYY.int.XXXX.com.xml \
        -authorize-attribute uid \
        -attribute-header-mappings UserID=x-webauth-user
        ```
        Then I point a browser to http://ilwsvc01.XXXX.com:8080

That causes a 302/redirect response to the browser, which causes the browser to do a GET to the Oracle OAM IdP and I see a cert popup and I select a good client user cert and click OK
   This request includes a samlp:AuthnRequest as a query param

Then it looks like the browser gets a response with a 200/OK response code
    The response includes a bunch of Set-Cookies 

Then the browser (automatically) does a POST to http://ilwsvc01.XXXX.com:8080/saml/acs
   This POST has a SAMLResponse and a RelayState as query params (I think)


The browser gets a 302/redirect response to http://ilwsvc01.XXXX.com:8080
    The response includes a Set-cookie for a cookie named "token"


The browser does a GET to http://ilwsvc01.XXXX.com:8080 and includes the "token" cookie


The browser gets a 502/Bad Gateway response code.
     I think the browser also gets a response message 
     ```
     Get "https://pxy.west.int.XXXX.com:8443/": x509: certificate signed by unknown authority
     ```
     NOTE: that response message is what appears in the browser window at the end.


I am not 100% where that response message is coming "from", but I am *GUESSING* that maybe the browser is 
invisibly making a request to the "https://pxy.west...:8443" host (REMEMBER that "pxy...:8443" is the "backend-url"), 
and that request is not appearing in the saml-tracer output.  

That "pxy:8443" is a reverse proxy and is configured to do SSL, BUT it is only doing 1-way SSL, so it does not make sense that
that reverse proxy would be complaining about a cert.

So maybe the message is coming from the saml-auth-proxy itself, i.e., maybe when the saml-auth-proxy attempts to connect 
to the "pxy...:8443" the reverse proxy is sending a server cert that the saml-auth-proxy is not aware of?

[itzg]

No, you didn't confuse me, but I'm afraid I have provided more than enough effort and information for what is one of several open source projects I maintain in my personal time.

This proxy conforms to typical SAML scenarios, so you are responsible for resolving remaining issues that are specific to your network situation.

Keep in mind, this is free software and you're welcome not to use it if it doesn't work in your situation.

[ohaya]

Hi,

Yes, got it! I do appreciate the help that you have provided.

Jim

[ohaya]

Hi,
Sorry, I know that you said that you couldn't provide much more support, but I've been doing some testing, and something strange is going on.

So remember the bridge error was puzzling me earlier, because I wasn't able to discern what was sending that?

So, as a test, I changed the backend-url to a URL that I found that looks like it is simply serving an HTML page (request-response), no authentication and no SSL. This is the URL:

http://www.brainjar.com/java/host/test.html

and it just returns a simple HTML page.

Then, I tested doing a request to the saml-auth-proxy and I get this response:

Get "http://www.brainjar.com/": dial tcp 64.41.87.38:80: i/o timeout

So I did some googling and found info like this stackoverflow thread:

https://stackoverflow.com/questions/65545585/dial-tcp-i-o-timeout-with-http-get-request

and if I am reading what is in that thread, it seems like some kind of interaction with GO and docker that is preventing the connection, e.g.:

Local environment, firewall not allowing golang to dial tcp..
It still allowed the url to be resolved to an ip though (DNS)

Have you run across this before?

I am thjinking that maybe the easiest thing to at least test this, is to try to run the saml-auth-proxy outside of docker, just to check if the problem goes away, and was wondering if that is possible and if so, how?

Thanks, and sorry to have to ask another one :(...

Jim

[itzg]

I am thjinking that maybe the easiest thing to at least test this, is to try to run the saml-auth-proxy outside of docker, just to check if the problem goes away, and was wondering if that is possible and if so, how?

You already are doing that in your own comment #49 (comment)

[ohaya]

Hi,

I think (but not sure) that I may have found the reason for the problem we are having. The problem is basically that that backend-url is an SSL URL:

-backend-url https://pxy.west.int.XXXX.com:8443/f5_test.html \

I don't have any experience with programming in GO, but it sounds like when you connect to an SSL endpoint using GO, that can cause the "certificate signed by unknown authority", because even though (in our case) the server certificate itself is not self-signed, the ROOT CA cert IS (ALWAYS) a self-signed cert.

This is discussed in this stackoverflow thread:

https://stackoverflow.com/questions/47464161/golang-http-x509-certificate-signed-by-unknown-authority-error

LIke I said I hve no experience with GO, but is there something that we can do (FYI< we are running the proxy on Redhat)? Or, is this something that can be worked around in saml-auth-proxy itself?

Thanks,
Jim

[itzg]

It doesn't require programming, just install the appropriate certificate chain. That's always required with self-signed certs. There's many resources out there. Here's one

http://gagravarr.org/writing/openssl-certs/others.shtml#selfsigned-openssl

[ohaya]

Hi,

PERFECT!! I did the (on RHEL7) and it worked!! Now, when I send a request (using browser) to the saml-auth-proxy URL, the browser ends up on the expected page :)!!!

Phew ;)!

Thanks a lot for your help and patience!

FYI, this first test page is an "unprotected" (not protected by OAM ) so now that we got this far, they'll need to do more testing, e.g., of OAM-protected pages, etc.

Will let you know how it goes!

Jim

[ohaya]

I think that you can close this issue now.