Bug 1768785 - [4.2] Authentication attempts are failing with Request Header Authentication Provider
Summary: [4.2] 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: 3.9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.2.z
Assignee: Standa Laznicka
QA Contact: scheng
URL:
Whiteboard:
Depends On: 1764558
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-05 09:45 UTC by Standa Laznicka
Modified: 2019-11-20 13:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-19 13:49:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift oauth-server pull 21 0 'None' closed [release-4.2] Bug 1768785: RequestHeaders IdP: fix TLS handshake 2020-02-06 00:14:00 UTC
Red Hat Product Errata RHBA-2019:3869 0 None None None 2019-11-19 13:49:12 UTC

Description Standa Laznicka 2019-11-05 09:45:19 UTC
This bug was initially created as a copy of Bug #1764558

I am copying this bug because: reasons



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 2019-11-19 13:49:01 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:3869


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