Comments (19)
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
from saml-auth-proxy.
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
from saml-auth-proxy.
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
from saml-auth-proxy.
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
from saml-auth-proxy.
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.
from saml-auth-proxy.
Hi,
I don't understand what you said. Can you clarify?
Thanks,
Jim
from saml-auth-proxy.
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 likehttps://pxy.west.int.XXXX.com:8443
from saml-auth-proxy.
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
from saml-auth-proxy.
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.
from saml-auth-proxy.
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.
from saml-auth-proxy.
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?
from saml-auth-proxy.
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.
from saml-auth-proxy.
Hi,
Yes, got it! I do appreciate the help that you have provided.
Jim
from saml-auth-proxy.
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
from saml-auth-proxy.
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)
from saml-auth-proxy.
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:
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
from saml-auth-proxy.
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
from saml-auth-proxy.
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
from saml-auth-proxy.
I think that you can close this issue now.
from saml-auth-proxy.
Related Issues (20)
- Enhance for Traefik's ForwardAuth feature? HOT 4
- Support Allow IDP Initiated HOT 4
- Configurable cookie domain HOT 4
- azure adfs HOT 1
- Config to change cookie name HOT 2
- Request tracker cookie domain
- Traefik forward_auth protocol HOT 6
- Error when with websockets HOT 1
- Get "http://locahost:3000/": dial tcp: lookup locahost on 127.0.0.53:53: server misbehaving HOT 2
- Trying it out: Does not access Grafana automatically HOT 3
- Is it possible to have the proxy go to a URL (Relaystate)? HOT 9
- Attempted URL that needed authentication might not be getting restored
- saml-auth-proxy dropping URI part of backend-url HOT 9
- after login, the /_verify check redirects to the wrong URI HOT 2
- Just plain THANK YOU! HOT 1
- Feature Proposal: Support anonymous access to the backend HOT 6
- `SAML_PROXY_NAME_ID_MAPPING` does not work with forward auth mode HOT 1
- IdP metadata from local file HOT 3
- Redirects are not propagated HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from saml-auth-proxy.