Hide Forgot
Description of problem: I'm trying to set custom SAML2 paths with ipsilon-client-install and I'm seeing problems with the redirect. [root@client1 ~]# ipsilon-client-install --saml-auth /secure1 --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-base /base1 --saml-sp /base1/saml2 --saml-sp-logout /base1/saml2/logout --saml-sp-post /base1/saml2/postResponse --saml-idp-metadata https://idp.testrelm.test/idp/saml2/metadata Generating a 2048 bit RSA private key ........................+++ ..................................................+++ writing new private key to '/etc/httpd/saml2/client1.testrelm.test/certificate.key' ----- admin password: [root@client1 httpd]# !curl curl https://$(hostname)/secure1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>303 See Other</title> </head><body> <h1>See Other</h1> <p>The answer to your request is located <a href="https://client1.testrelm.test/mellon/login?ReturnTo=https%3A%2F%2Fclient1.testrelm.test%2Fsecure1&IdP=(null)">here</a>.</p> </body></html> Above it looks like the redirect points to IdP=(null). But, when I let install with default saml paths, it has something like: https%3A%2F%2Fidp.testrelm.test%2Fidp%2Fsaml2%2Fmetadata And, in ssl_error_log, I see this: [Fri Aug 14 14:29:04.916670 2015] [:error] [pid 25793] [client 192.168.122.73:40400] Error adding IdP to lasso server object. Please verify the following configuration directives: MellonIdPMetadataFile and MellonIdPPublicKeyFile. Version-Release number of selected component (if applicable): ipsilon-client-1.0.0-5.el7.noarch How reproducible: unknown Steps to Reproduce: 1. Install IPA Server and 2+ clients 2. ipsilon-server-install --ipa --info-sssd=yes --form=yes 3. Install SP with ipsilon-client-install ipsilon-client-install --saml-auth /secure1 --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-base /base1 --saml-sp /base1/saml2 --saml-sp-logout /base1/saml2/logout --saml-sp-post /base1/saml2/postResponse --saml-idp-metadata https://idp.testrelm.test/idp/saml2/metadata 4. setup web [root@client1 log]# cat /var/www/html/secure1/index.html <html><title>Secure</title>Hello there...from client1.testrelm.test ...<br> <a href="/base1/saml2/logout?ReturnTo=https://client1.testrelm.test/logged_out.html">Log out</a> <hr> <!--#printenv --> 5. check secure access for redirect curl https://$(hostname)/secure1 Actual results: message like above <p>The answer to your request is located <a href="https://client1.testrelm.test/mellon/login?ReturnTo=https%3A%2F%2Fclient1.testrelm.test%2Fsecure1&IdP=(null)">here</a>.</p> Expected results: More like other setup here: <p>The answer to your request is located <a href="https://client1.testrelm.test/saml2/login?ReturnTo=https%3A%2F%2Fclient1.testrelm.test%2Fsecure%2F&IdP=https%3A%2F%2Fidp.testrelm.test%2Fidp%2Fsaml2%2Fmetadata">here</a>.</p> Additional info:
Everything needs to be under the same base, including the protected site. So if you use --saml-auth /base1/secure1 instead of --saml-auth /secure1 it will work.
Yes, that worked: [root@client2 secure]# ipsilon-client-install --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-auth /base1/secure --saml-base /base1 --saml-sp /base1/saml2 --saml-sp-logout /base1/saml2/logout --saml-sp-post /base1/saml2/postResponse Generating a 2048 bit RSA private key ............................+++ ...........................................................................+++ writing new private key to '/etc/httpd/saml2/client2.testrelm.test/certificate.key' ----- admin password: [root@client2 secure]# systemctl restart httpd [root@client2 secure]# curl https://$(hostname)/base1/secure <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>303 See Other</title> </head><body> <h1>See Other</h1> <p>The answer to your request is located <a href="https://client2.testrelm.test/base1/saml2/login?ReturnTo=https%3A%2F%2Fclient2.testrelm.test%2Fbase1%2Fsecure&IdP=https%3A%2F%2Fidp.testrelm.test%2Fidp%2Fsaml2%2Fmetadata">here</a>.</p> </body></html> So this too works as expected. Should this be checked on the command line if paths don't match for those settings? And warn/fail if mismatched?
Yes. Some checking is done and even that is not exactly adequate. This is at least tangentially related to upstream ticket https://fedorahosted.org/ipsilon/ticket/145
Upstream ticket: https://fedorahosted.org/ipsilon/ticket/163
Merged upstream: 3b079b3735ea98b3b36b22b0f0353cb56f023dad
Verified. Version :; ipsilon-client-1.0.0-9.el7.noarch Results :: [root@client1 ~]# ipsilon-client-install --saml-auth /secure1 --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-base /base1 --saml-sp /base1/saml2 --saml-sp-logout /base1/saml2/logout --saml-sp-post /base1/saml2/postResponse --saml-auth must be a subpath of --saml-base. [root@client1 ~]# ipsilon-client-install --saml-auth /base1/secure1 --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-base /base1 --saml-sp /base2/saml2 --saml-sp-logout /base2/saml2/logout --saml-sp-post /base1/saml2/postResponse --saml-sp must be a subpath of --saml-base. [root@client1 ~]# ipsilon-client-install --saml-auth /base1/secure1 --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-base /base1 --saml-sp /base1/saml2 --saml-sp-logout /base2/saml2/logout --saml-sp-post /base2/saml2/postResponse --saml-sp-logout must be a subpath of --saml-sp
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-2319.html