Bug 1744995 - [4.1] Request Header Identity provider configuration is not working
Summary: [4.1] Request Header Identity provider configuration is not working
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.1.z
Assignee: Stefan Schimanski
QA Contact: Chuan Yu
Depends On: 1741822
Blocks: 1739262
TreeView+ depends on / blocked
Reported: 2019-08-23 12:54 UTC by Standa Laznicka
Modified: 2019-09-20 12:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1741822
Last Closed: 2019-09-20 12:29:24 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift origin pull 23660 'None' 'closed' 'Bug 1744995: Request headers fix x509 [4.1]' 2019-12-03 02:49:03 UTC
Red Hat Product Errata RHBA-2019:2768 None None None 2019-09-20 12:29:38 UTC

Description Standa Laznicka 2019-08-23 12:54:29 UTC
+++ This bug was initially created as a clone of Bug #1741822 +++

Description of problem:
Configuring the Request Header IdP for 4.x clusters won't work

Version-Release number of selected component (if applicable):
4.1, master

How reproducible:

Steps to Reproduce:
1. generate a CA cert, sign a client cert with it (has to have clientAuth EKU)
2. configure the request header identity provider by modifying the cluster-scoped oauth/cluster object's spec field to include e.g. the following config:
  - name: testreqheader
        name: my-ca-cm
      - X-Remote-User
      loginURL: https://prdel.com/authorize?${query}
    type: RequestHeader

3. use the client cert/key pair to try to connect to the /oauth/token/request endpoint of the oauth server with curl specifying all that should be required:
$ curl -L -k -I -H "X-Remote-User: franta" --cert ~/rootCA/client.pem 'https://<OAUTH_SERVER_HOST>/oauth/token/request'

Actual results:
You get `401 unauthorized` response, oauth-server pod logs show

Unable to authenticate the request due to an error: x509: certificate signed by unknown authority

Expected results:
Either 200 and a token or at least start a flow that would end by receiving a token after properly providing requested information

Additional info:
Modifying the spec of authentication.operator/cluster object with
      clientCA: /var/config/user/idp/0/configmap/v4-0-config-user-idp-0-ca/ca.crt
gets us a bit further, the above curl command progresses as such:
302 (/oauth/authorize?client_id=openshift-browser-client&redirect_uri=https%3A%2F%2F<OAUTH_SERVER_HOST>%2Foauth%2Ftoken%2Fdisplay&response_type=code) -> 302 (/oauth/token/display?code=lWoRmUQmGk8BYZML8ZsluyOP512BRV466UDTQHbqKao&state=) -> 405 Method Not Allowed (since don't allow GET on /oauth/token/display anymore)

specifying -XPOST for the curl does similar
302 -> 302 -> 400 Bad Request (this is closer to what we'd expect but would need some better handling requests)

--- Additional comment from Standa Laznicka on 2019-08-16 09:55:46 CEST ---

Additional additional information:
after setting the unsupportedConfigOverrides, an identity for the user specified in the request header is getting created

--- Additional comment from Standa Laznicka on 2019-08-16 12:40:51 CEST ---

--- Additional comment from Standa Laznicka on 2019-08-16 18:04:43 CEST ---

We've found the source of the bug, I'll have a fix on Monday

Comment 4 errata-xmlrpc 2019-09-20 12:29:24 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.


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