Bug 1750809 - [4.1] RequestHeader IdP - `oc login` fails because oauth-server sets incompatible headers
Summary: [4.1] RequestHeader IdP - `oc login` fails because oauth-server sets incompat...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.1.z
Assignee: Standa Laznicka
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On: 1750786
Blocks: 1739262
TreeView+ depends on / blocked
 
Reported: 2019-09-10 14:00 UTC by Mo
Modified: 2019-10-16 18:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1750786
Environment:
Last Closed: 2019-10-16 18:07:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift origin pull 23767 0 'None' closed Bug 1750809: [4.1] Fix bootstrap IdP challenges ruining RequestHeaders IdP 2020-08-12 17:46:39 UTC
Red Hat Product Errata RHBA-2019:3004 0 None None None 2019-10-16 18:08:08 UTC

Description Mo 2019-09-10 14:00:57 UTC
+++ This bug was initially created as a clone of Bug #1750786 +++

Description of problem:
When RequestHeader IdP is configured for challenges, authentication requests fail because the oauth-server sets incompatible headers (Location and WWW-Authenticate).

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

How reproducible:
always

Steps to Reproduce:
1. configure ReqeustHeader IdP as challenger
2. curl -k -H "X-Csrf-Token: 1" 'https://<oauth-server-host>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'

Actual results:
Error: redirect header (Location: https://oauth-proxy-httpd.usersys.redhat.com/challenging-proxy/oauth/authorize?client_id=openshift-challenging-client&response_type=token) and challenge header (WWW-Authenticate: Basic realm="openshift") cannot both be set

Expected results:
Redirect to a server which will authenticate the user to openshift with a request with a required header

Comment 1 Standa Laznicka 2019-09-10 14:27:29 UTC
Adding as blocking to another BZ w/ customer case as without this fix, the Request Headers IdP won't work for them.

Comment 4 Chuan Yu 2019-09-29 02:21:33 UTC
Verified on 4.1.0-0.nightly-2019-09-27-171543

$ curl -k -H "X-Csrf-Token: 1" 'https://oauth-openshift.apps.chuyu.qe.devcluster.openshift.com/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -v
*   Trying 10.0.96.164:443...
* TCP_NODELAY set
* Connected to oauth-openshift.apps.chuyu.qe.devcluster.openshift.com (10.0.96.164) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.apps.chuyu.qe.devcluster.openshift.com
*  start date: Sep 29 02:07:50 2019 GMT
*  expire date: Sep 28 02:07:51 2021 GMT
*  issuer: CN=ingress-operator@1569722870
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: oauth-openshift.apps.chuyu.qe.devcluster.openshift.com
> User-Agent: curl/7.65.3
> Accept: */*
> X-Csrf-Token: 1
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Location: https://oauth-proxy-httpd.usersys.redhat.com/challenging-proxy/oauth/authorize?client_id=openshift-challenging-client&response_type=token
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Sun, 29 Sep 2019 02:19:51 GMT
< Content-Length: 0
< 
* Connection #0 to host oauth-openshift.apps.chuyu.qe.devcluster.openshift.com left intact

Comment 6 Anand Paladugu 2019-10-14 12:31:26 UTC
@ Standa

Now that this is verified,  can I assume that 1739262 is also fixed ?

Thanks

Anand

Comment 7 Standa Laznicka 2019-10-14 12:48:23 UTC
I would expect that, yes.

Comment 9 Anand Paladugu 2019-10-15 17:42:15 UTC
Thanks

Comment 10 errata-xmlrpc 2019-10-16 18:07:59 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://access.redhat.com/errata/RHBA-2019:3004


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