Bug 1434983 - [3.4] Can't login to Jenkins application when ENABLE_OAUTH=true and RequestHeaderIdentityProvider is used
Summary: [3.4] Can't login to Jenkins application when ENABLE_OAUTH=true and RequestHe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.4.z
Assignee: Jordan Liggitt
QA Contact: Chuan Yu
URL:
Whiteboard:
Depends On:
Blocks: 1439221 1439222
TreeView+ depends on / blocked
 
Reported: 2017-03-22 20:10 UTC by Jordan Liggitt
Modified: 2020-04-15 15:32 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1421629
: 1439221 1439222 (view as bug list)
Environment:
Last Closed: 2017-04-19 19:42:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0989 0 normal SHIPPED_LIVE OpenShift Container Platform 3.4, 3.3, 3.2, and 3.1 bug fix update 2017-04-19 23:42:19 UTC

Description Jordan Liggitt 2017-03-22 20:10:21 UTC
+++ This bug was initially created as a clone of Bug #1421629 +++

Description of problem:
Error message "The requested URL /oauth/approve was not found on this server" returns, when accessing Jenkins application created by default template "jenkins-persistent".

Version-Release number of selected component (if applicable):
OpenShift Master: v3.4.1.2
Kubernetes Master: v1.4.0+776c994

How reproducible:
Always

Steps to Reproduce:
1. Configure server with RequestHeaderIdentityProvider
2. Create Jenkins application using default template "jenkins-persistent"("OAuth OpenShift integration" is enabled);
3. After all the pods are running well, check if Jenkins can be accessed or not.

Actual results:
3. After clicking "Login with Openshift", error message "The requested URL /oauth/approve was not found on this server" returns.


cluster is using RequestHeaderIdentityProvider:
...
  identityProviders:
  - challenge: false
    provider:
      headers:
      - Remote-User
      kind: RequestHeaderIdentityProvider
      nameHeaders:
      - Remote-User-Name
      loginURL: https://auth-proxy.example.com/mod_auth_mellon/?${query}
      apiVersion: v1
      clientCA: /etc/origin/master/ca.crt
    mappingMethod: lookup
    login: true
    name: myidp
...

--- Additional comment from Jordan Liggitt on 2017-02-14 12:45:18 EST ---

Currently, two URLs are accessed during the OAuth flow that require authentication information:

  $master/oauth/authorize
  $master/oauth/approve

When using a RequestHeaderIdentityProvider, all authentication information must come from the auth proxy.

loginURL is used to specify the URL that proxies to $master/oauth/authorize

There is no option to configure the URL that proxies to $master/oauth/approve (this was an oversight). When approval is needed during an OAuth flow, a redirect to /oauth/approve is done.


Temporary workaround:
1. Change the auth proxy to proxy https://auth-proxy.example.com/oauth/* to $master/oauth/*
2. Change the origin config to
  loginURL: https://auth-proxy.example.com/oauth/authorize?${query}


This "fixes" the issue by making the auth proxy paths match the /oauth/* paths on the API server, and makes the auth proxy proxy both /oauth/authorize and /oauth/approve

Long term, we have a couple options:
1. Add another config option to specify the approve proxy path, and make the proxy explicitly set up a proxy rule for /oauth/approve

2. Move /oauth/approve under /oauth/authorize/approve and depend on the loginURL proxy path proxying subpaths as well

--- Additional comment from Jordan Liggitt on 2017-02-14 13:03:57 EST ---

See https://github.com/openshift/request-header-saml-service-provider/pull/7 for changes to the SAML pod to support the temporary workaround

--- Additional comment from Jordan Liggitt on 2017-02-14 14:46:28 EST ---

verified with the changes in https://github.com/openshift/request-header-saml-service-provider/pull/7 we can run grant approval through the auth proxy

--- Additional comment from Troy Dawson on 2017-02-16 17:29:31 EST ---

Should be fixed in openshift3/saml-service-provider:1.0-5 which is available in testing areas.

--- Additional comment from Jordan Liggitt on 2017-02-16 17:36:14 EST ---

the following config changes are needed when deploying that version:

for the saml pod, instead of:
OSE_API_PUBLIC_URL=https://api.example.com/oauth/authorize
set
PROXY_PATH=/oauth/
PROXY_DESTINATION=https://api.example.com/oauth/


for the apiserver, change the master-config.yaml loginURL to:
loginURL: https://auth-proxy.example.com/oauth/authorize?${query}

Comment 1 Jordan Liggitt 2017-04-04 18:36:42 UTC
The workaround for this issue is to make the auth proxy paths match the API server paths for these paths:

These are the paths that require proxying currently:
  https://api.acme.com/oauth/authorize (and subpaths)
  https://api.acme.com/oauth/approve

The auth proxy paths would be:
  https://auth.acme.com/oauth/authorize (and subpaths)
  https://auth.acme.com/oauth/approve

The master-config.yaml would be:
...
oauthConfig:
  identityProviders:
  - name: ...
    login: true
    ...
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      loginURL: "https://auth.acme.com/oauth/authorize?${query}"
      ...


https://github.com/openshift/origin/pull/13569 will move the approval flow to /oauth/authorize/approve so there is a single root that auth proxies need to proxy.

Comment 3 Chuan Yu 2017-04-10 05:57:54 UTC
Tested in 3.4 latest puddle, the issue should be fixed, here is my steps:
1.setup openshift with saml auth mothod
2.create jenkins instance in my namespace
3.login to jenkins successfully with openshift login info.

# openshift version
openshift v3.4.1.16
kubernetes v1.4.0+776c994
etcd 3.1.0-rc.0

Comment 5 Chuan Yu 2017-04-10 07:53:35 UTC
Verified, see the #c3.

Comment 7 errata-xmlrpc 2017-04-19 19:42:47 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-2017:0989


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