Bug 1764558 - [4.3] Authentication attempts are failing with Request Header Authentication Provider
Summary: [4.3] Authentication attempts are failing with Request Header Authentication ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.3.0
Assignee: Standa Laznicka
QA Contact: scheng
URL:
Whiteboard:
Depends On:
Blocks: 1739262 1768785
TreeView+ depends on / blocked
 
Reported: 2019-10-23 10:25 UTC by Standa Laznicka
Modified: 2020-01-23 11:09 UTC (History)
2 users (show)

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
Clone Of: 1739262
Environment:
Last Closed: 2020-01-23 11:09:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift oauth-server pull 19 'None' closed Bug 1764558: RequestHeaders IdP: fix TLS handshake 2020-03-27 13:27:03 UTC
Red Hat Product Errata RHBA-2020:0062 None None None 2020-01-23 11:09:34 UTC

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


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