Bug 1744995

+++ 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:
100%

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:
```
  identityProviders:
  - name: testreqheader
    requestHeader:
      ca:
        name: my-ca-cm
      headers:
      - 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
```
  unsupportedConfigOverrides:
    servingInfo:
      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