Bug 1083380 - When using LDAP for remote auth to broker username is not case sensitive
Summary: When using LDAP for remote auth to broker username is not case sensitive
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 2.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Luke Meyer
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks: 1138462
TreeView+ depends on / blocked
 
Reported: 2014-04-02 05:53 UTC by Jason Shepherd
Modified: 2018-12-09 17:42 UTC (History)
7 users (show)

Fixed In Version: rubygem-openshift-origin-controller-1.23.10.9-1.el6op openshift-origin-broker-1.16.1.12-1.el6op openshift-origin-broker-util-1.23.8.11-1.el6op
Doc Type: Enhancement
Doc Text:
The broker previously handled logins with different letter cases as distinct user accounts. For example, the broker would store separate accounts for the logins "JDoe" and "jdoe". This issue caused confusion for users when applications were created under different accounts, among other problems. This enhancement allows administrators to enable a selection of default or custom methods on the broker to enforce user login normalization. When normalization methods are set, the broker now handles logins based on these settings. See the OpenShift Enterprise Administration Guide for more information.
Clone Of:
: 1138462 (view as bug list)
Environment:
Last Closed: 2014-08-26 13:52:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1095 0 normal SHIPPED_LIVE Red Hat OpenShift Enterprise 2.1.5 bug fix and enhancement update 2014-08-26 17:51:34 UTC

Description Jason Shepherd 2014-04-02 05:53:17 UTC
Description of problem:

Using the same username with different case authenticates to LDAP as a single user, but the Openshift broker treats them as distinct users.

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


How reproducible:


Steps to Reproduce:
1. Setup remote authorization of the broker as per Section "7.9.2.2. Authenticating LDAP" of the Deployment Guide
2. Create a domain with a user, eg. ttest01

   $rhc domain create mydomain -k
     Creating domain 'mydomain' ... done
     You may now create an application using the 'rhc create-app' command


3. Verify the domain and user:

   $rhc domain show -k
      Domain test (owned by ttest01)
      ------------------------------
      Created:            Apr 01  5:13 PM
      Allowed Gear Sizes: small

4. Change the username to a different case eg TTest01 and check the domain again:

   $rhc domain show -k
     In order to deploy applications, you must create a domain with 'rhc setup' or 'rhc create-domain'


Actual results:

   Users ttest01, and TTest01 are treated as distinct users

Expected results:

   Users ttest01, and TTest01 are treated as the same user

Additional info:

Comment 3 Jason Shepherd 2014-04-02 06:17:53 UTC
This problem also effects Openshift Enterprise 1.2

Comment 4 Brenton Leanhardt 2014-04-02 16:00:49 UTC
I suspect we're going to have to add a setting to the broken to normalize the usernames whenver apache plugins like mod_authnz_ldap are in use.  I spent a few hours this morning trying to find a way to have apache lowercase the REMOTE_USER but it really seems it's not possible.

Comment 5 Luke Meyer 2014-04-02 18:25:48 UTC
I don't think we can assume LDAP will be either case sensitive or insensitive. I think it varies by implementation/configuration of the LDAP server.

Have any customers actually reported this as a problem? If so, would this be something they couldn't configure on the LDAP side?

I'm asking mainly for priorization purposes. It does seem like it would make sense to offer the option for the remote user auth plugin to normalize usernames. I think it would make sense to normalize to lowercase by default, but allow the admin to specify that they don't want that. Something could also be useful for normalizing Kerberos logins with regards to @REALM suffix.

Comment 6 Brenton Leanhardt 2014-04-02 19:50:03 UTC
I think it's the case that the configuration can be made on the LDAP side.  However, my assumption is that large IT shops aren't going to want to change anything for an OpenShift installation.  I wouldn't be surprised if other applications in their company actually rely on that strange behavior.

Comment 7 Luke Meyer 2014-04-02 20:04:23 UTC
Yeah, I do think we need to do it anyway. It's just that at least some places might have the LDAP configuration route available.

Comment 8 Jason Shepherd 2014-04-04 01:22:34 UTC
In this case it's a customer, and they are using Red Hat Directory Server (RHDS). I'll check with the RHDS team is there is anything that can be done, although last time I asked them, they said it depends on what the client is using to connect to RHDS. I've checked out the Apache modules used, and I can't find anything myself. Do you know if we can change the configuration in Apache to ignore case?

Comment 9 Luke Meyer 2014-04-04 14:27:43 UTC
I'm fairly sure mod_ldap_authnz is just taking literally the login string the user enters and sending it off to LDAP for authentication. Then if it is authenticated, that is used (again, literally) as the user name. I don't see any way to specify via mod_ldap_authnz that the login should match case exactly, or be normalized first. I was kind of hoping there would be a way to specify in the URL to match exactly, or in LDAP server config. That doesn't appear to be the case for RHDS.

That means that LDAP may consider johndoe and JohnDoe the same user, but once they get to OpenShift they'll be considered different users with a different set of apps/domains/capabilites. So we need a way to normalize them via the remote-user plugin.

Comment 10 Luke Meyer 2014-04-17 19:52:46 UTC
I created an Enterprise story to enable normalizing user names.

https://trello.com/c/noKWhxNG/212-2-enable-custom-normalization-of-usernames-from-external-sources

Comment 12 Luke Meyer 2014-08-14 18:19:06 UTC
The story mentioned above is moving ahead. This bug may either be explicitly added to an advisory or just closed. Packages noted.

Relevant commits that were cherry-picked are:
commit 0aa857cab940064e5800713a748480d76118b8eb
Author: Luke Meyer <lmeyer>
Date:   Fri Aug 8 13:56:06 2014 -0400

    broker oo scripts: enable login normalization
    
    https://trello.com/c/noKWhxNG/212-2-enable-custom-normalization-of-usernames-from-external-sources
    
    This enables an administrator to define a custom method to normalize
    usernames before they are translated into cloud_user entries.
    
    Affected scripts:
    oo-admin-ctl-team
    oo-admin-ctl-app
    app_info.rb  (oo-app-info)
    oo-admin-ctl-user

commit dd248a60767de74e04acda3b900ef0058f89e2d9
Author: Luke Meyer <lmeyer>
Date:   Thu Jul 17 16:58:42 2014 -0400

    cloud_user: enable normalization of user logins.
    
    https://trello.com/c/noKWhxNG/212-2-enable-custom-normalization-of-usernames-from-external-sources
    
    This enables an administrator to define a custom method to normalize
    usernames before they are translated into cloud_user entries.
    
    For example, this method could downcase the login such that the login
    is case-insensitive; then case-insensitive authentication methods would
    not create multiple cloud_users for the "same" login just because the
    user capitalized it on one occasion and not another.

Comment 15 Ma xiaoqiang 2014-08-18 05:51:26 UTC
Check on puddle [2.1.z/2014-08-15.1]

1. Configure NORMALIZE_USERNAME_METHOD to lowercase in broker.conf
2. run 'rhc setup ' in different terminal
#rhc setup -l xiaom
#rhc setup -l Xiaom
3. Create a domain in the different terminal
#rhc domain create xiaom -l xiaom
#rhc domain create xiaod -l Xiaom
4. List domain
#rhc domain list -l xiaom
#rhc domain list -l Xiaom
#rhc domain list -l XIAOM 

All output in the step 5 contain both 'xiaod' and 'xiaom'.

Comment 21 errata-xmlrpc 2014-08-26 13:52:08 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.

http://rhn.redhat.com/errata/RHBA-2014-1095.html


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