Bug 1391809

Summary: [DOCS] Form-Based Authentication allow the user with incorrect password to login
Product: OpenShift Container Platform Reporter: Takayoshi Tanaka <tatanaka>
Component: DocumentationAssignee: brice <bfallonf>
Status: CLOSED CURRENTRELEASE QA Contact: Vikram Goyal <vigoyal>
Severity: low Docs Contact: Vikram Goyal <vigoyal>
Priority: low    
Version: 3.3.0CC: aos-bugs, george.goh, jokerman, mfojtik, mmccomas, sgallagh, tatanaka
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-18 06:17:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Takayoshi Tanaka 2016-11-04 05:29:44 UTC
Description of problem:
When I set up form-based authentication for signing into the OpenShift Container Platform web console [1], the user can log into the web console even though the user input the incorrect password. The web console shows the username as "(null)" and the user can create a new project.



Version-Release number of selected component (if applicable):
NA

How reproducible:
Confirmed at OpenShift 3.2. However the document isn't updated at 3.3.

Steps to Reproduce:
1.Setting up form-based authentication following "Configuring Form-Based Authentication" in the document [1].
I use free ipa demo [2] as an LDAP server.
2.Open OpenShift Web console. Input user and incorrect password into the login form then click "Log In".


Actual results:
The user log into the web console and the usernames is "(null)". 

Expected results:
The user can't log into the web console when the user input the incorrect password.

Additional info:
We can set up the similar login proxy server following another document [3].

[1] https://docs.openshift.com/container-platform/3.3/install_config/advanced_ldap_configuration/configuring_form_based_authentication.html
[2] http://www.freeipa.org/page/Demo
[3] https://docs.openshift.com/container-platform/3.3/install_config/configuring_authentication.html#RequestHeaderIdentityProvider

Comment 5 George Goh 2016-11-09 08:22:41 UTC
I can also reproduce this problem on my setup.

The mappingMethod I've used is 'claim'.

  - name: LDAP Proxy
    challenge: true
    login: true
    mappingMethod: claim
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://ose-lb.int.spodon.com/challenging-proxy/oauth/authorize?${query}"
      loginURL: "https://ose-lb.int.spodon.com/login-proxy/oauth/authorize?${query}"
      clientCA: /etc/origin/proxy/proxyca.crt
      headers:
      - X-Remote-User

Comment 6 Jordan Liggitt 2016-11-09 09:26:14 UTC
Mapping method is unrelated to the auth proxy setting a "(null)" header value for an unauthenticated user

Looks like the doc is missing the env=REMOTE_USER condition when setting the request header:


RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER

Comment 7 Jordan Liggitt 2016-11-09 09:37:54 UTC
Opened https://github.com/openshift/openshift-docs/pull/3183 to update docs

Comment 8 George Goh 2016-11-09 11:11:30 UTC
I've tested this on 2 environments, and it correctly returns to the login screen when a wrong user/password combination is provided.

Comment 9 Vikram Goyal 2016-11-18 06:17:16 UTC
The PR has merged [1]. Moving this bug to CLOSED --> CURRENTRELEASE.

[1] https://docs.openshift.com/container-platform/3.3/install_config/advanced_ldap_configuration/sssd_for_ldap_failover.html#phase-2-step-2-sssd-configuration