Bug 1253821 - ipsilon client redirect not working with custom saml paths
ipsilon client redirect not working with custom saml paths
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipsilon (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rob Crittenden
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-14 15:36 EDT by Scott Poore
Modified: 2015-11-19 05:50 EST (History)
4 users (show)

See Also:
Fixed In Version: ipsilon-1.0.0-9.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 05:50:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Poore 2015-08-14 15:36:56 EDT
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&amp;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&amp;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&amp;IdP=https%3A%2F%2Fidp.testrelm.test%2Fidp%2Fsaml2%2Fmetadata">here</a>.</p>

Additional info:
Comment 2 Rob Crittenden 2015-08-18 15:21:54 EDT
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.
Comment 3 Scott Poore 2015-08-20 10:38:28 EDT
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&amp;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?
Comment 4 Rob Crittenden 2015-08-20 10:51:30 EDT
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
Comment 6 Rob Crittenden 2015-09-02 13:10:36 EDT
Upstream ticket:
https://fedorahosted.org/ipsilon/ticket/163
Comment 7 Patrick Uiterwijk 2015-09-04 12:44:06 EDT
Merged upstream: 3b079b3735ea98b3b36b22b0f0353cb56f023dad
Comment 10 Scott Poore 2015-09-08 19:18:03 EDT
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
Comment 11 errata-xmlrpc 2015-11-19 05:50:26 EST
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

Note You need to log in before you can comment on or make changes to this bug.