Origin: Need option for Converting user's ID to uppercase/lowercase in group LDAP Sync

[mgjadoul]

In an Classical Enterprise using Active Directory + ADAM for authentication and authorization, login are case insensitive. In Unix / openshift the UID are case sensitive apparently. In AD, there is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later. We implemented an Apache config for authentication in Kerberos and including normalizing the login to uppercase. This resolved the issue for authentication.

Now we would like to implement group syncronization and the issue is basically the same issue. The UID we retrieve (from ADAM) is case insensitive and there are no guarantee the the case match the case in AD and in any case it is not always uppercase.
We need an option in oc adm group sync ... to allow converting uid to uppercase.

The output is currently:

apiVersion: v1
items:
- apiVersion: v1
  kind: Group
  metadata:
    annotations:
      openshift.io/ldap.sync-time: 2016-12-06T15:20:5900100
      openshift.io/ldap.uid: CN=G1,OU=myapp,OU=Apps,O=xxx
      openshift.io/ldap.url: ldapvip.xxx.corp:636
    creationTimestamp: null
    labels:
      openshift.io/ldap.host: ldapvip.xxx.corp
    name: G1
  users:
  - USER1
- apiVersion: v1
  kind: Group
  metadata:
    annotations:
      openshift.io/ldap.sync-time: 2016-12-06T15:20:5900100
      openshift.io/ldap.uid: CN=G2,OU=myapp,OU=Apps,O=xxx
      openshift.io/ldap.url: ldapvip.xxx.corp:636
    creationTimestamp: null
    labels:
      openshift.io/ldap.host: ldapvip.xxx.corp
    name: G2
  users:
  - USER2
  - user3
- kind: List
metadata: {}

Notice the user "user3" in lower case. We need an option to get the same output but with all users in upper case.

The lower case user does not exists in openshift:

$ oc get user USER3
NAME      UID                                    FULL NAME   IDENTITIES
USER3   5f9487ba-b716-11e6-9a1c-68b5996b6fee               requestheader:USER3
$ oc get user user3
Error from server: users "user3" not found

Where are you experiencing the behavior? What environment?

PROD in enterprise with ActiveDirectory Authentication and AD LDS authorisation.

Version

oc v3.2.1.17
kubernetes v1.2.0-36-g4a3f9c5

[enj]

cc @stevekuznetsov @liggitt

[liggitt]

We do not use user input as user names directly, but use that to look up data from LDAP. The attributes read from LDAP should be canonical.

[liggitt]

I'd rather see documentation for using attributes from LDAP as the username in Apache auth (should be possible with mod_lookup_identity), rather than trying to normalize the user-provided id in parallel ways in multiple components

[liggitt]

some documentation around mod_lookup_identity exists at https://docs.openshift.org/latest/install_config/advanced_ldap_configuration/configuring_extended_ldap_attributes.html

would like to see a reference configuration that pulls the uid from LDAP using that, which would remove the need for upper-casing in Apache, and would make group sync and auth agree

[mgjadoul]

We do not use SSSD (yet).... It could take some time as in our case it requires implementing IPA.
If you do a reference implementation based on this only.... Some won't be able to use it.

As far as I understand, your solution does not solve fully the issue .... As stated above: There is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later. Our Openshift Project is a small project and changing identity management processes is not in the scope.
If we do not make the uid uppercase, we would have to delete existing users and recreate them or at the end we would end with multiple users in openshift for the same person: UserX=userx=userX=USERX=....
And if users have role attached, you need to recreate those roles also.

NB: We have an httpd configuration able to do the same as mod_lookup_identity does: sending attribute from ldap. It is quite simple with mod_authz_ldap. The config bellow set a header for the email.

#Kerberos authentication.
    AuthType VAS4
    AuthVasUseBasic On
    AuthName Openshift
    AuthVasRemoteUserMap ldap-attr sAMAccountName
    AuthVasAuthz Off

#Ldap Authorization also providing mail attribute
    LDAPReferrals On
    AuthLDAPUrl "ldaps://<myldapurl>/O=acme?uid,mail?sub?(objectClass=*)"
    AuthLDAPBindDN CN=binduser,OU=Users,OU=Apps,O=acme
    AuthLDAPSubGroupClass group
    AuthLDAPBindPassword <...>
    AuthLDAPGroupAttributeIsDN on
    AuthLDAPCompareDNOnServer on
    AuthLDAPMaxSubGroupDepth 2
    Require ldap-group CN=developers,OU=Groups,OU=openshift,OU=Apps,O=acme

    RequestHeader set X-Remote-Email "%{AUTHORIZE_MAIL}e" env=AUTHORIZE_MAIL

[mgjadoul]

In the mean time we implemented a filter and calling it like this:

$ oadm groups sync --sync-config=rfc2307_config.yaml -o json | ./groupmember_to_upper.py | oc create -f -

The filter is basic: importing json, changing users to upper, exporting json.

[stevekuznetsov]

As far as I understand, your solution does not solve fully the issue .... As stated above: There is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later.

Could you expand on this? As I understand it, if you were to configure your authentication _via_ the LDAPPasswordIdentityProvider to report the LDAP entry DN with fidelity, there will be no issue. If the LDAP attribute used for naming OpenShift User objects is passed without processing from LDAP to OpenShift (through Apache, etc), when further data is requested from LDAP by the sync, the same attribute, again with no changes, will be used to denote group membership for users in OpenShift. If you can ensure that your authentication flow is passing canonical information from LDAP to OpenShift, the sync operation will require no such lower-casing option, or filters otherwise.

[mgjadoul]

Hello Steve,

Our AD, LDAP or more generally our corporate directories are only
publication of identity access information for applications. It is driven
by an Identity layers. This Identity Layer is composed from many historical
tools. It is continuously evolving depending the company evolution
(reorganization of the company, purchase of selling of companies,
implementation of new tool / processes, consolidation, .....). In addition
a user may be removed and then recreated tomorrow as another user (other
DN) for other external reason (user disabled/reenabled, ...). He would keep
its attributes but the DN would change.
The DN or the user is typically :
CN=X-140925131929508787857,OU=,OU=FR,OU=Persons,O=Acme

There is no garantee from the IAM Departement that the letter case of any
case insensitive attribute (including uid) will not change.

Regards,

Marc

On Sun, Dec 11, 2016 at 11:02 PM, Steve Kuznetsov [e-mail]
wrote:

As far as I understand, your solution does not solve fully the issue ....
As stated above: There is no guarantee if the ID will be upper case, lower
case or a mix. There is also no guarantee that it won't change later.

Could you expand on this? As I understand it, if you were to configure
your authentication via the LDAPPasswordIdentityProvider to report the
LDAP entry DN with fidelity, there will be no issue. If the LDAP attribute
used for naming OpenShift User objects is passed without processing from
LDAP to OpenShift (through Apache, etc), when further data is requested
from LDAP by the sync, the same attribute, again with no changes, will be
used to denote group membership for users in OpenShift. If you can ensure
that your authentication flow is passing canonical information from LDAP to
OpenShift, the sync operation will require no such lower-casing option, or
filters otherwise.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/issues/12169#issuecomment-266311531,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARLbSN8yw81STwcs_xG282qvuXX74Pjwks5rHHL8gaJpZM4LGfBO
.

[stevekuznetsov]

He would keep its attributes but the DN would change.

@liggitt will have more insight on this, but I think a core assumption for _any_ of the data stores backing an Identity Provider for use in OpenShift is that they should be stable, canonical sources of data.

[chrisruffalo]

Running into this option now. When using PIV/CAC authentication the smart card (not the user) supplies the data used for the username. At a particular site the LDAP has user names like abc1, def2, etc. But their LDAP has SOMETIMES all uppercase and SOMETIMES all lower case. It's my understanding that the group that issues the cards actually belongs to a different organization altogether. Coordination between these two is not likely (in other words).

The solution @mgjadoul proposes is interesting I think we'll need to look into that for the time being but this tool should probably allow for at least some simple transforms of this nature.

I just wanted to put it out there that people are still having issues with this.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[djlindstr]

liggitt wrote:

We do not use user input as user names directly, but use that to look up data from LDAP. The attributes read from LDAP should be canonical.

Although I personally agree that having usernames on a canonical form is to be preferred, I think this standpoint is too strict for interoperability with other systems. Especially since LDAP user IDs are case-insensitive in most implementations, in accordance with the LDAP specification.

Ref. https://tools.ietf.org/html/rfc4519#section-2.39
/remove-lifecycle stale

[stevekuznetsov]

Case insensitivity is only part of the problem here, LDAP would have to be giving _inconsistent_ casing for this to be a problem. Origin won't care if they are cased one way or another, just that LDAP is consistently putting them in the same case.

[mgjadoul]

Identity management in international large organization is on constant
evolution. It is large and complexe.
Companies merge.... Then one system is eliminated. And thus we have no
guarantee that a uid which is case insensitive won't change.
So we normalize both at user authentication and when we import groups for
authorization.
By precaution.
Marc.

Le ven. 16 févr. 2018 à 19:07, Steve Kuznetsov [e-mail] a
écrit :

Case insensitivity is only part of the problem here, LDAP would have to be
giving inconsistent casing for this to be a problem. Origin won't care
if they are cased one way or another, just that LDAP is consistently
putting them in the same case.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/issues/12169#issuecomment-366313139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARLbSASnlpUFQrVk279OvvmU5HFhdKazks5tVcPigaJpZM4LGfBO
.

[djlindstr]

Case insensitivity is only part of the problem here, LDAP would have to be giving inconsistent casing for this to be a problem. Origin won't care if they are cased one way or another, just that LDAP is consistently putting them in the same case.

Perhaps I should open a new ticket. I have some difficulties following the original post; it might be that I am mixing things up.

My problem can be summarized as follows: users are imported into Openshift from LDAP (AD). Authentication works regardless of case, since it's delegated to the LDAP backend. Authorization is case-sensitive, since it's done in Openshift. I would like the authorization to be case-insensitive. Would you say that this is the same issue, or a different issue?

[liggitt]

Authentication works regardless of case, since it's delegated to the LDAP backend. Authorization is case-sensitive, since it's done in Openshift. I would like the authorization to be case-insensitive. Would you say that this is the same issue, or a different issue?

How LDAP resolves the user-entered login name is entirely up to LDAP (and happens to be done case insensitively), but the user id attribute LDAP reports back to openshift is treated case sensitively. That is the value used for authorization.

There are no plans to make authorization case-insensitive.

[djlindstr]

There are no plans to make authorization case-insensitive.

Thank you for clearing that up (even though I don't agree with the decision :) ).

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close