RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1269142 - RHEL 7 ipsilon-client generates redirect that leads to 400 Bad Request on Fedora 22 ipsilon-server
Summary: RHEL 7 ipsilon-client generates redirect that leads to 400 Bad Request on Fed...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipsilon
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: John Dennis
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-06 12:45 UTC by Jan Pazdziora
Modified: 2016-11-23 11:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-23 11:17:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan Pazdziora 2015-10-06 12:45:53 UTC 
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 14:21:16 UTC 
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 14:44:21 UTC 
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 15:50:25 UTC 
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 16:34:31 UTC 
(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 17:40:57 UTC 
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 16:37:04 UTC 
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 17:30:12 UTC 
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 20:11:54 UTC 
re comment 9, locating the metadata files

grep -r /etc/httpd * 'Mellon.*MetadataFile'
Comment 13 Jan Pazdziora 2015-10-15 14:35:09 UTC 
(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 11:17:22 UTC 
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.