Bug 1269142 - RHEL 7 ipsilon-client generates redirect that leads to 400 Bad Request on Fedora 22 ipsilon-server
RHEL 7 ipsilon-client generates redirect that leads to 400 Bad Request on Fed...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipsilon (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: John Dennis
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-06 08:45 EDT by Jan Pazdziora
Modified: 2016-11-23 06:17 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-23 06:17:22 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 Jan Pazdziora 2015-10-06 08:45:53 EDT
Description of problem:

When ipsilon-client-1.0.0-11.el7.noarch and mod_auth_mellon-0.11.0-1.el7.x86_64 on RHEL 7.2 are configured against ipsilon-1.0.0-1.fc22.noarch on Fedora 22, the authentication redirect leads to 400 Bad request on the server side.

Version-Release number of selected component (if applicable):

Ipsilon client on RHEL 7.2:
ipsilon-client-1.0.0-11.el7.noarch
mod_auth_mellon-0.11.0-1.el7.x86_64

Ipsilon server on Fedora 22:
ipsilon-1.0.0-1.fc22.noarch

How reproducible:

Deterministic.

Steps to Reproduce:
1. Setup Ipsilon server on Fedora 22.
2. Setup Ipsilon client on RHEL 7.2.
3. Attempt to authenticate on the client.

Actual results:

400 Bad request on the server.

Expected results:

Logon form.

Additional info:

Setup with Fedora 22 to Fedora 22 or RHEL 7.2 to RHEL 7.2, and even Fedora 22 client to RHEL 7.2 server work.
Comment 3 Rob Crittenden 2015-10-06 10:21:16 EDT
So you are just trying to authenticate to the IdP when this happens?

Can you enable debugging on the Ipsilon server and attach the resulting access and error logs?
Comment 4 Jan Pazdziora 2015-10-08 10:44:21 EDT
Yes.

[Thu Oct 08 10:42:26.686086 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/util/cookies.py:64 SecureCookie.send()): Sending cookie f476d702-7957-4879-a8cb-06824bcc10b1
[Thu Oct 08 10:42:26.691687 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/util/cookies.py:56 SecureCookie._store()): Cookie op: Set-Cookie: f476d702-7957-4879-a8cb-06824bcc10b1=saml2; httponly; Max-Age=300; Path=/idp; secure
[Thu Oct 08 10:42:26.708632 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/util/trans.py:51 Transaction.create_tid()): Transaction: saml2 145c17f1-1721-4d40-a5de-3d8c6200fe18
[Thu Oct 08 10:42:26.719385 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/providers/common.py:93 Redirect.debug()): saml2: self.binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, transdata={u'origintime': u'2015-10-08 10:42:26.668016', u'cookie': u'f476d702-7957-4879-a8cb-06824bcc10b1', u'provider': u'saml2'}
[Thu Oct 08 10:42:26.735900 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/providers/common.py:35 InvalidRequest.__init__()): Invalid SAML Request: <lasso.Samlp2AuthnRequest object at 0x7f41d91e5fd0> (DsInvalidSigalgError() ['SAMLRequest=nZJRb9sgEMe%2FisW7bUzizEVJJNfppEjdViVrH%2FoyUXyJkTAwDmfttx921KnLQx76hHTcn%2BP30y1R9Nrxegid2cHvATAkr702yKeLFRm84VagQm5ED8iD5Pv62z1nGeXO22Cl1eRD5HpCIIIPyhqSbDcr8uuumNFF3SyaqqjKec1uZuzL7Ybe3ZRNdcsqSpIn8Bj7VyTGYwhxgK3BIEyIJVqUaUFTWv0s5nzOOFs8k2QTGZQRYUp1ITjked65tNVlVR5ZSovMdwEzMMfsxWLmoe1EyKTtc9W6fIRg%2BX7%2FI99BqzzIQJLGGoRx4jU2eW7icvA%2BnqnqnVZSxfhX6yVMilfkIDTCCPIQXagT%2FKvU72rGYUMPfg%2F%2BpCQ87u4vMGYVdUcwVUpZeuqjgEyLl0uUM4azGHaAbvwaWS%2FHIp8c%2BvUnn1zmHx9Zntfne5Sx3TzYyPs20vbiiqsiK6aKatPD1MoHgw6kOihoowet7Z%2FGgwjRTfADkHx9Hvr%2Fmq7%2FAg%3D%3D&RelayState=https%3A%2F%2Fsp-redacted.example.com%2Fprotected'])
[Thu Oct 08 10:42:26.740448 2015] [wsgi:error] [pid 25056] [08/Oct/2015:10:42:26]  DEBUG(ipsilon/providers/common.py:93 Redirect.debug()): saml2: "Invalid SAML Request: <lasso.Samlp2AuthnRequest object at 0x7f41d91e5fd0> (DsInvalidSigalgError() ['SAMLRequest=nZJRb9sgEMe%2FisW7bUzizEVJJNfppEjdViVrH%2FoyUXyJkTAwDmfttx921KnLQx76hHTcn%2BP30y1R9Nrxegid2cHvATAkr702yKeLFRm84VagQm5ED8iD5Pv62z1nGeXO22Cl1eRD5HpCIIIPyhqSbDcr8uuumNFF3SyaqqjKec1uZuzL7Ybe3ZRNdcsqSpIn8Bj7VyTGYwhxgK3BIEyIJVqUaUFTWv0s5nzOOFs8k2QTGZQRYUp1ITjked65tNVlVR5ZSovMdwEzMMfsxWLmoe1EyKTtc9W6fIRg%2BX7%2FI99BqzzIQJLGGoRx4jU2eW7icvA%2BnqnqnVZSxfhX6yVMilfkIDTCCPIQXagT%2FKvU72rGYUMPfg%2F%2BpCQ87u4vMGYVdUcwVUpZeuqjgEyLl0uUM4azGHaAbvwaWS%2FHIp8c%2BvUnn1zmHx9Zntfne5Sx3TzYyPs20vbiiqsiK6aKatPD1MoHgw6kOihoowet7Z%2FGgwjRTfADkHx9Hvr%2Fmq7%2FAg%3D%3D&RelayState=https%3A%2F%2Fsp-redacted.example.com%2Fprotected'])"
[Thu Oct 08 10:42:26.744792 2015] [wsgi:error] [pid 25056] 2620:52:0:2282:223:7dff:fe4c:9ae1 - - [08/Oct/2015:10:42:26] "GET /idp/saml2/SSO/Redirect?SAMLRequest=nZJRb9sgEMe%2FisW7bUzizEVJJNfppEjdViVrH%2FoyUXyJkTAwDmfttx921KnLQx76hHTcn%2BP30y1R9Nrxegid2cHvATAkr702yKeLFRm84VagQm5ED8iD5Pv62z1nGeXO22Cl1eRD5HpCIIIPyhqSbDcr8uuumNFF3SyaqqjKec1uZuzL7Ybe3ZRNdcsqSpIn8Bj7VyTGYwhxgK3BIEyIJVqUaUFTWv0s5nzOOFs8k2QTGZQRYUp1ITjked65tNVlVR5ZSovMdwEzMMfsxWLmoe1EyKTtc9W6fIRg%2BX7%2FI99BqzzIQJLGGoRx4jU2eW7icvA%2BnqnqnVZSxfhX6yVMilfkIDTCCPIQXagT%2FKvU72rGYUMPfg%2F%2BpCQ87u4vMGYVdUcwVUpZeuqjgEyLl0uUM4azGHaAbvwaWS%2FHIp8c%2BvUnn1zmHx9Zntfne5Sx3TzYyPs20vbiiqsiK6aKatPD1MoHgw6kOihoowet7Z%2FGgwjRTfADkHx9Hvr%2Fmq7%2FAg%3D%3D&RelayState=https%3A%2F%2Fsp-redacted.example.com%2Fprotected HTTP/1.1" 400 851 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0"

==> /var/log/httpd/ssl_access_log <==
2620:52:0:2282:223:7dff:fe4c:9ae1 - - [08/Oct/2015:10:42:26 -0400] "GET /idp/saml2/SSO/Redirect?SAMLRequest=nZJRb9sgEMe%2FisW7bUzizEVJJNfppEjdViVrH%2FoyUXyJkTAwDmfttx921KnLQx76hHTcn%2BP30y1R9Nrxegid2cHvATAkr702yKeLFRm84VagQm5ED8iD5Pv62z1nGeXO22Cl1eRD5HpCIIIPyhqSbDcr8uuumNFF3SyaqqjKec1uZuzL7Ybe3ZRNdcsqSpIn8Bj7VyTGYwhxgK3BIEyIJVqUaUFTWv0s5nzOOFs8k2QTGZQRYUp1ITjked65tNVlVR5ZSovMdwEzMMfsxWLmoe1EyKTtc9W6fIRg%2BX7%2FI99BqzzIQJLGGoRx4jU2eW7icvA%2BnqnqnVZSxfhX6yVMilfkIDTCCPIQXagT%2FKvU72rGYUMPfg%2F%2BpCQ87u4vMGYVdUcwVUpZeuqjgEyLl0uUM4azGHaAbvwaWS%2FHIp8c%2BvUnn1zmHx9Zntfne5Sx3TzYyPs20vbiiqsiK6aKatPD1MoHgw6kOihoowet7Z%2FGgwjRTfADkHx9Hvr%2Fmq7%2FAg%3D%3D&RelayState=https%3A%2F%2Fsp-redacted.example.com%2Fprotected HTTP/1.1" 400 851

==> /var/log/httpd/ssl_request_log <==
[08/Oct/2015:10:42:26 -0400] 2620:52:0:2282:223:7dff:fe4c:9ae1 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /idp/saml2/SSO/Redirect?SAMLRequest=nZJRb9sgEMe%2FisW7bUzizEVJJNfppEjdViVrH%2FoyUXyJkTAwDmfttx921KnLQx76hHTcn%2BP30y1R9Nrxegid2cHvATAkr702yKeLFRm84VagQm5ED8iD5Pv62z1nGeXO22Cl1eRD5HpCIIIPyhqSbDcr8uuumNFF3SyaqqjKec1uZuzL7Ybe3ZRNdcsqSpIn8Bj7VyTGYwhxgK3BIEyIJVqUaUFTWv0s5nzOOFs8k2QTGZQRYUp1ITjked65tNVlVR5ZSovMdwEzMMfsxWLmoe1EyKTtc9W6fIRg%2BX7%2FI99BqzzIQJLGGoRx4jU2eW7icvA%2BnqnqnVZSxfhX6yVMilfkIDTCCPIQXagT%2FKvU72rGYUMPfg%2F%2BpCQ87u4vMGYVdUcwVUpZeuqjgEyLl0uUM4azGHaAbvwaWS%2FHIp8c%2BvUnn1zmHx9Zntfne5Sx3TzYyPs20vbiiqsiK6aKatPD1MoHgw6kOihoowet7Z%2FGgwjRTfADkHx9Hvr%2Fmq7%2FAg%3D%3D&RelayState=https%3A%2F%2Fsp-redacted.example.com%2Fprotected HTTP/1.1" 851
Comment 6 Patrick Uiterwijk 2015-10-12 11:50:25 EDT
This looks like a bug in Fedora 22 mod_auth_mellon, since the request does not contain any signatures.
Comment 7 Jan Pazdziora 2015-10-12 12:34:31 EDT
(In reply to Patrick Uiterwijk from comment #6)
> This looks like a bug in Fedora 22 mod_auth_mellon, since the request does
> not contain any signatures.

What would be the reason then that when run against Fedora 22 ipsilon, the authentication passes?
Comment 8 John Dennis 2015-10-12 13:40:57 EDT
I don't know if this is the issue or not, but there is an optional flag that can appear in the IdP metadata

WantAuthnRequestsSigned

which defaults to false. The SP is supposed to examine this flag before sending an AuthnRequest to the IdP and sign the request if the flag is present and true. On the receiving end the IdP checks it's flag in it's copy of it's metadata the demands a signature if the flag is present and true.

What could be going on is a mismatch of the metadata between the SP and IdP.

I just check the source code for ipsilon and on master branch we set the WantAuthnRequestsSigned flag to True.

Just to make life interesting we've seen cases where the metadata is not identical between the SP and the IdP.

By any chance do you still have the metadata files from both the SP and IdP you could attach to this bz? Looking for a mismatch in the metadata is the first step in diagnosing the problem.
Comment 9 Jan Pazdziora 2015-10-13 12:37:04 EDT
Running

curl -Lksi https://idp.example.com/idp/saml2/metadata | grep WantAuthnRequestsSigned

against IdP running ipsilon-1.0.0-1.fc22.noarch does not yield anything. That's the URL I pass to ipsilon-client-install's --saml-idp-metadata (the client is ipsilon-client-1.0.0-11.el7.noarch).

Where would the copy of the IdP metadata be on the client? Might it be that Fedora 22 server does not set that flag in the metadata but requires the signature internally?
Comment 10 Jan Pazdziora 2015-10-13 13:30:12 EDT
I don't see that WantAuthnRequestsSigned in /idp/saml2/metadata of RHEL 7.2's Ipsilong server either.
Comment 12 John Dennis 2015-10-13 16:11:54 EDT
re comment 9, locating the metadata files

grep -r /etc/httpd * 'Mellon.*MetadataFile'
Comment 13 Jan Pazdziora 2015-10-15 10:35:09 EDT
(In reply to John Dennis from comment #12)
> re comment 9, locating the metadata files
> 
> grep -r /etc/httpd * 'Mellon.*MetadataFile'

On client (SP machine):

# grep -r 'Mellon.*MetadataFile' /etc/httpd
/etc/httpd/conf.d/ipsilon-saml.conf:    MellonSPMetadataFile "/etc/httpd/saml2/client.example.com/metadata.xml"
/etc/httpd/conf.d/ipsilon-saml.conf:    MellonIdPMetadataFile "/etc/httpd/saml2/client.example.com/idp-metadata.xml"

# grep WantAuthnRequestsSigned /etc/httpd/saml2/client.example.com/idp-metadata.xml | wc -l
0

# sha1sum /etc/httpd/saml2/client.example.com/idp-metadata.xml
570508a260aa1a03c86569ac42acdbcf754d1392  /etc/httpd/saml2/client.example.com/idp-metadata.xml

On IdP:

# curl -Lks https://$(hostname)/idp/saml2/metadata | sha1sum 
570508a260aa1a03c86569ac42acdbcf754d1392  -

There is no WantAuthnRequestsSigned on either side.
Comment 15 Martin Kosek 2016-11-23 06:17:22 EST
Red Hat Enterprise Linux 7.2 introduced the Ipsilon identity provider service for federated single sign-on (SSO). Subsequently, Red Hat has released Red Hat Single Sign-On as a web SSO solution based on the Keycloak community project. Red Hat Single Sign-On provides greater capabilities than Ipsilon and is designated as the standard web SSO solution across the Red Hat product portfolio.

Therefore, as mentioned in the RHEL-7.3 Release Notes:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.3_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.3_Release_Notes-Deprecated_Functionality.html
Ipsilon is now obsolete in RHEL and all existing Ipsilon users are recommended to migrate to Red Hat SSO product:
https://access.redhat.com/products/red-hat-single-sign-on
Please approach the Customer Service for advice.

Given above, this Bugzilla is now closed as WONTFIX.

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