Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1764558

Summary:	[4.3] Authentication attempts are failing with Request Header Authentication Provider
Product:	OpenShift Container Platform	Reporter:	Standa Laznicka <slaznick>
Component:	apiserver-auth	Assignee:	Standa Laznicka <slaznick>
Status:	CLOSED ERRATA	QA Contact:	scheng
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.1.z	CC:	aos-bugs, mfojtik
Target Milestone:	---
Target Release:	4.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: client CA certificate configured for the Request Header IdP was not being announced among other certificates during TLS handshake with the oauth-server Consequence: when login-proxies tried to connect to the oauth-server they would not use their client certificate, resulting in their request being unauthenticated, which in turn caused users of the IdP being unable to login to the cluster Fix: add the configured client CA among the rest in TLS configuration Result: authentication via RequestHeader IdP works	Story Points:	---
Clone Of:	1739262	Environment:
Last Closed:	2020-01-23 11:09:02 UTC	Type:	---
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:
Bug Blocks:	1739262, 1768785

Description Standa Laznicka 2019-10-23 10:25:45 UTC

This bug was initially created as a copy of Bug #1739262

I am copying this bug because: the process is suboptimal



Description of problem:

Authentication attempts are failing with Request Header Authentication Provider

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


How reproducible:

Always in the customer environment.

Steps to Reproduce:
1. Configure Request Header authentication provider as documented in ocp 4.1 DOCS.  Auth proxy (httpd) conf is provided in Additional info below.
2. Try to login from console or via oc cli as the SSO user
3. 

Actual results:

Authentication attempts via UI are failing and must-gather logs do not show any specific reason. must-gather attached along with logs from the httpd proxy.

OC Cli login attempts result "unexpected response: 500".  cli-login-linux.txt is attached.

If cusomer tries to authenticate directly with oauth-openshift providing the creds and certificates. request-header-config.txt is attached.



Expected results:


Successful authentication via UI and CLI.


Additional info:

Customer claims that the same procedure worked in 3.11


Customers httpd auth proxy config is as below:


#############
SSLProxyCACertificateFile /pki/authproxyca.crt

SSLCACertificateFile /pki/smartcard.crt
  SSLVerifyClient require
  SSLVerifyDepth 4
  SSLOptions +ExportCertData
#############



Here is the new file

############################################################
LoadModule request_module modules/mod_request.so
ServerName <other_stuff>

LogLevel trace6

LISTEN 8443
<VirtualHost *:8443>

  DocumentRoot /var/www/html
  SSLEngine on
  SSLCertificateFile /pki/web.crt
  SSLCertificateKeyFile /pki/web.key
  SSLCACertificateFile /pki/ca.crt

  SSLProxyEngine on
  SSLProxyCACertificateFile /pki/ca.crt
  # It's critical to enforce client certificates on the Master.  Otherwise
  # requests could spoof the X-Remote-User header by accessing the Master's
  # /oauth/authorize endpoint directly.
  SSLProxyMachineCertificateFile /pki/authproxy.pem

  # Send all requests to the console
  RewriteEngine              On
  RewriteRule     ^/console(.*)$     https://%{HTTP_HOST}/console$1 [R,L]

  # In order to using the challenging-proxy an X-Csrf-Token must be present.
  RewriteCond %{REQUEST_URI} ^/challenging-proxy
  RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
  RewriteRule ^.* - [F,L]

  <Location /challenging-proxy/oauth/authorize>
      ProxyPass https://<stuff>:443/oauth/authorize
      AuthName "SSO Login"
      # For Kerberos
      AuthType GSSAPI
      Require valid-user
      RequestHeader set X-Remote-User %{REMOTE_USER}s

      GssapiCredStore keytab:/krb5/auth-proxy.keytab
      GssapiBasicAuth On
      GssapiImpersonate  On
      GssapiConnectionBound On
    </Location>

    <Location /login-proxy/oauth/authorize>
    ProxyPass https://<stuff>:443/oauth/authorize

      AuthName "SSO Login"
      AuthType GSSAPI
      Require valid-user
      RequestHeader set X-Remote-User %{REMOTE_USER}s
      GssapiUseSessions On
      Session On
      SessionCookieName os_gssapi_session path=/private;httponly;secure;

      GssapiCredStore keytab:/krb5/auth-proxy.keytab
      GssapiBasicAuth On
      GssapiImpersonate On
      GssapiConnectionBound On

      ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/login-proxy/oauth/authorize"><body>Kerberos authentication did not pass.</body></html>'
    </Location>

</VirtualHost>

RequestHeader unset X-Remote-User

Comment 4 errata-xmlrpc 2020-01-23 11:09:02 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-2020:0062