saml-auth-proxy dropping URI part of backend-url

[ohaya]

Hi,

So we've been continuing to work with your saml-auth-proxy, and I have been doing tests with different scenarios, e.g. one test is where the backend-url is a simple Apache hosted HTML page and we set the backend-url to the URL of that HTML page and that works.

Now I am testing with backend-url set to an a simple Apache hosted HTML page, but where the URL for that page is protected by OAM, and it is ALMOST working, but when it finally gets through part of the protocol where OAM has already authenticated the user (using a cert), it is not sending the request to the URL in the backend-url parameter. Instead, it appears to be sending the request to the URL that is the backend-url parameter, BUT with the URI part missing.

For example, I have:

-backend-url https://pxy.west.XXX.com:8443/ootbx509/index.html \

but instead of sending the final request to:

https://pxy.west.XXX.com:8443/ootbx509/index.html

it is ending the request to:

https://pxy.west.XXX.com:8443/

FYI, I also tried a test where I had both the backend-url and the new -static-relay-state set to the desired URL but when I tested with that, I got a 403/Forbidden when I tested.

Also FYI, I think we are "pretty close" because I did another test with just the backend-url parameter and again, it went to the "/" URI, then I manually added the /ootbx509/index.html to the URL in the address bar, and I got the desired test page back (i.e., OAM did allow the desired target request through).

Please advise.

Thanks,
Jim

[itzg]

I don't know what OAM is but are you saying you have two layers of authentication: SAML and OAM?

This is way beyond my area of expertise. The best I could do is add more debug logs. Maybe someone can contribute that change.

[ohaya]

Hi,

Ok, sorry... "OAM" is Oracle's "Oracle Access Manager" product. It provides authentication, authorization, single-sign on, etc., and with it you can "protect" URLs ("protect" == force an authentication before allowing access).

I think more debug output would be helpful.

When I tested, and have the chrome or firefox web developer enabled, I can see the final request being sent, but the URI part of the URL is chopped off. It would be helpful if there was debugging showing the URL when the saml-auth-proxy is processing redirects, etc., because not all of them are visible in web developer (or not even in Wireshark), to try to see when the URI is being dropped.

Thanks,
Jim

P.S. I've been doing some searching, and I think that what I was referring to as the "URI part" of the URL is usually called the "Path" part of the URL in GO language discussions.

So, basically what I am seeing is that when the saml-auth-proxy is supposed to be the final request to the URL that is in the backend-url, it is not including/dropping the Path part of the URL.

We don't know why, or even where, this is happening. It could be in the GO code or in the sequence of requests/responses/redirects in the OAM "protocol", but if we could see the URL at various points in the processing, it might help us identify where/when in the process the Path part is being dropped and that might help us figure out what to look at.

[ohaya]

Hi,

I'm not sure if this makes sense, but, I was wondering: Would it be possible that the saml-auth-proxy saved the value of the backend-url, then when it subsequently processes a request, that when it gets to the point that it is supposed to send a request to the backend-url URL, it just substitutes the URL that it had saved initially, then does the final request?

The reason I am saying that is that when I test, as I said, the browser is ending up at the URL that was in the backend-url parameter, but without the path part, and I can actually manually add the path to the address in the browser address bar, and then I get the page that we wanted (i.e., I can manually simulate what I am asking for, and it works).

Thanks,
Jim

[ohaya]

Hi,

I think that you already had a paramter to do what I suggested last above!!

-auth-verify-path string

I just tried a test and if I set that " -auth-verify-path string" param to "/ootbx509/index.html", then test to the proxy, it actually went to the path after the succcessful authentication!!

If you can confirm that, then I think you can close this issue after that.

Sorry that I missed this :(!!

Jim

P.S. I know you are thinking "RTFM" :)!!!

[ohaya]

Hi,

CANCEL or at least correct what I said above about that parameter. That parameter did work in the case where the proxy backend-url was going to a simple protected static page/URL, but I just tried another example where the URL was to a URL that was "in" a portal-type app:

-auth-verify-path /all-consumers/consumer?consumer=123

and in this case the proxy dropped that path part when it did the final request :(...

Jim

[ohaya]

Ok, you are probably going to disbelieve me, but now, even when I set that auth-verify-path, it is dropping the path all the time, even for simple protected static page/URL :(...

[ohaya]

Hi - I acknowledge what you said earlier about this being open-source, but we are not that familiar with GO, and one of my colleagues is trying to step through the code to try to figure out why the Path part of the URL is being dropped when it makes the last request, so, since you are obviously more familiar than any of us with the code and with GO, I was wondering if you might give us some ideas about where (which module and maybe method) we should consider for modifying to get the Path part to not be dropped from the last request?

Thanks,
Jim

[itzg]

I might have time to get those logs added this weekend.

[ohaya]

Hi,

One of my colleagues was able to step through the proxy code and figured out how to get the proxy to use the Path. What he found was that when a request is made to the proxy, the proxy post-pends the path of the incoming URL to the URL of the outgoing URL.

So for instance, if the backend-url is "https://test.foo.com/foo1/index.html", and we make a request to the proxy:

http://<PROXY_IP>:8080/whatever/index.html

Then the proxy will send the request to:

https://test.foo.com/whatever/index.html

I think that you can close this issue now...

Jim