Bug 1414156

Summary:	Using default ports produces bad request error
Product:	Red Hat OpenStack	Reporter:	John Dennis <jdennis>
Component:	keycloak-httpd-client-install	Assignee:	John Dennis <jdennis>
Status:	CLOSED ERRATA	QA Contact:	Rodrigo Duarte <rduartes>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	apevec, extras-qa, jdennis, jjoyce, jschluet, lhh, mlopes, rhos-maint, sclewis
Target Milestone:	z2	Keywords:	Rebase, Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	keycloak-httpd-client-install-0.5-1.el7ost	Doc Type:	Bug Fix
Doc Text:	Prior to this update, setting --mellon-https-port to the default 443 port would result in a `HTTP 503 Bad Request` error during authentication. This was due to a mismatch between the `Destination` attribute and the `Assertion Consumer Service` URL. With this update, authentication now proceeds correctly if port 443 is used.	Story Points:	---
Clone Of:	1410938	Environment:
Last Closed:	2017-03-01 13:38:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1410938
Bug Blocks:	1410940, 1414152, 1414154

Description John Dennis 2017-01-17 22:08:52 UTC

+++ This bug was initially created as a clone of Bug #1410938 +++

Explicitly specifying a default port (e.g. http://example.com:80 or
https://example.com:443) will cause Mellon to fail. This occurs
because the port gets embedded into the location URL for each endpoint
in the SP metadata (e.g the Assertion Consumer Service). The IdP sets
the Destination attribute in the SAML response by looking it up in the
SP metadata, thus the Destination will have the default port in it
(e.g. 443). Upon receiving the SAML response the SP compares the URL
of the request to the Destination attribute in the SAML response, they
must match for the response to be considered valid. However when
Mellon asks Apache what the request URL was it won't have the port in
it thus the URL comparison fails causing the server to return a 503
Bad Request error. So why is the port absent? It turns out that most
(all?) browsers will strip the port from a URL if it matches the port
for the scheme (e.g. 80 for http and 443 for https). Thus even if you
include the port in the URL it will never be included in the URL the
browser emits. This also includes stripping the port from the HTTP
host header (which Apache uses to reconstruct the URL).

The fix is to have keycloak-httpd-client-install recognize when a
default port has been specified and remove it from the mellon host
URL so it does not get embedded into any of the SAML endpoints.

--- Additional comment from Fedora Update System on 2017-01-06 18:05:29 EST ---

keycloak-httpd-client-install-0.5-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d3ca5b534b

--- Additional comment from Fedora Update System on 2017-01-07 20:19:38 EST ---

keycloak-httpd-client-install-0.5-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d3ca5b534b

--- Additional comment from Fedora Update System on 2017-01-16 15:49:45 EST ---

keycloak-httpd-client-install-0.5-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 1 John Dennis 2017-01-17 22:17:27 UTC

This should be fixed by rebasing to keycloak-httpd-client-install-0.5

Comment 10 errata-xmlrpc 2017-03-01 13:38:19 UTC

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/RHBA-2017-0355.html