User Experience: Authentication
Closed, ResolvedPublic4 Estimated Story Points
Actions

Assigned To

Authored By

	• EChetty
	May 5 2022, 3:50 PM

Project Tags

Referenced Files

	F35138630: image.png
	May 13 2022, 4:31 PM

	F35135730: image.png
	May 12 2022, 3:58 PM

	F35135079: image.png
	May 12 2022, 1:48 PM

	F35134440: image.png
	May 12 2022, 11:25 AM

Subscribers

Description

Problem statement

As a datahub user, I want to be able to log into datahub using an auth-method that I use for other foundation services.

Primary Task

Standardise how users authenticate with datahub

Key tasks:

Have auth linked to a consistent identifier everyone has access to
Define roles and access rules based on your auth

Update

We have created an upstream bug report in the DataHub project: https://github.com/datahub-project/datahub/issues/4915
This bug currently prevents us from using our preferred identifier, which is a person's cn attribute from their LDAP entry.

Until that bug is fixed, or possibly T305874: Switch DataHub authentication to OIDC is implemented, we will have to keep using the uid value, which does not contain whitespace.

Details

Related Changes in Gerrit:

	Subject	Author	Repo	Branch	Lines +/-
	Update the LDAP authentication for DataHub	Btullis	operations/deployment-charts	master	+2 -2

Customize query in gerrit

Related Objects

Mentioned In: T305874: Switch DataHub authentication to OIDC
T309382: DataHub rights assignment is case-sensitive
Mentioned Here: T309382: DataHub rights assignment is case-sensitive
T305874: Switch DataHub authentication to OIDC

Event Timeline

• EChetty created this task.May 5 2022, 3:50 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 5 2022, 3:50 PM

• EChetty moved this task from Backlog to Next Up on the Data-Catalog board.May 5 2022, 3:58 PM

• EChetty set the point value for this task to 4.May 5 2022, 4:15 PM

• EChetty updated the task description. (Show Details)May 10 2022, 3:43 PM

• EChetty moved this task from Next Up to MVP on the Data-Catalog board.May 10 2022, 5:25 PM

@BTullis: I'm doling out these tasks per our grooming session today, just to expedite the process. We decided there's only a few of us and we can stay in a tight loop. This was the top infrastructure thing we needed to look into. Emil said he validated that users without ssh access can login to datahub, but that it's confusing knowing which username to use. I guess maybe some clarity on the approach here, like a simple wiki article that we can link to, would be useful? Ping me if you want to brainbounce.

The next thing would be the datahub upgrade process, feel free to grab that one or anything else from the Groomed column.

Milimetric moved this task from Next Up to In Progress on the Data-Engineering-Kanban board.May 10 2022, 8:24 PM

Change 791061 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Update the LDAP authentication for DataHub

https://gerrit.wikimedia.org/r/791061

gerritbot added a project: Patch-For-Review.May 11 2022, 5:10 PM

I have a patch for this so that instead of using the uid value from the LDAP directory, which corresponds to the user's SSH login name, it uses the cn (or common name) value, which corresponds to the Wikitech username.
The patch also successfully enables filtering by group membership of the wmf or nda groups, so that's a bonus.

In testing this has worked in the majority of cases, but unfortunately it fails in cases where the Wikitech username contains a space.

Here are three test cases, showing the dn, uid, and cn values.

btullis@seaborgium:~$ ldapsearch -LLL -x uid=btullis dn cn uid
dn: uid=btullis,ou=people,dc=wikimedia,dc=org
uid: btullis
cn: Btullis

btullis@seaborgium:~$ ldapsearch -LLL -x uid=ntsako dn cn uid
dn: uid=ntsako,ou=people,dc=wikimedia,dc=org
uid: ntsako
cn: Nmaphophe

btullis@seaborgium:~$ ldapsearch -LLL -x uid=echetty dn cn uid
dn: uid=echetty,ou=people,dc=wikimedia,dc=org
uid: echetty
cn: Emil Chetty

uid	cn	working
btullis	Btullis	yes
ntsako	Nmaphophe	yes
echetty	Emil Chetty	no

The following error is shown in the datahub-frontend logs from the prototype (on stat1008) where this was tested.

May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] search-first mode; SSL enabled
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] user provider: ldaps://ldap-ro.eqiad.wikimedia.org:636/ou=people,dc=wikimedia,dc=org
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] searching for entry belonging to user: Emil Chetty
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] found entry: uid=echetty,ou=people,dc=wikimedia,dc=org
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] attempting to authenticate user: Emil Chetty
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] authentication succeeded
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] added LdapPrincipal "uid=echetty,ou=people,dc=wikimedia,dc=org" to Subject
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] added UserPrincipal "Emil Chetty" to Subject
May 12 10:32:36 stat1008 playBinary[23376]:                 [LdapLoginModule] added UserPrincipal "echetty" to Subject
May 12 10:32:36 stat1008 playBinary[23376]: 10:32:36 [application-akka.actor.default-dispatcher-142] ERROR akka.actor.ActorSystemImpl - Internal server error, sending 500 response
May 12 10:32:36 stat1008 playBinary[23376]: java.lang.IllegalArgumentException: Cookie value contains an invalid char:

I have found an upstream bug report in the Play framework which explains it perfectly, in that spaces need to be encoded before being put into a cookie: https://github.com/t2v/play2-auth/issues/180

However I haven't found such a bug report in DataHub yet.
I raise the question with DataHub in our channel on their Slack.

For reference I checked how many of our users would be affected by this issue. Out of 437 valid users, 126 have spaces in their Wikitech usernames.

btullis@seaborgium:~$ ldapsearch -x "(&(objectClass=inetOrgPerson)(|(memberof=cn=nda,ou=groups,dc=wikimedia,dc=org)(memberof=cn=wmf,ou=groups,dc=wikimedia,dc=org)))" cn|egrep "^cn: .*"|wc -l
437
btullis@seaborgium:~$ ldapsearch -x "(&(objectClass=inetOrgPerson)(|(memberof=cn=nda,ou=groups,dc=wikimedia,dc=org)(memberof=cn=wmf,ou=groups,dc=wikimedia,dc=org)))" cn|egrep "^cn: .* .*"|wc -l
126

• EChetty moved this task from MVP to In Progress on the Data-Catalog board.May 12 2022, 12:58 PM

Here is a link to my question in the DataHub Slack: https://datahubspace.slack.com/archives/C033H7EMDQ8/p1652353659591429

In simple terms it would be a lot easier if everyone were able to use their posix user name as their primary identifier in DataHub.
This is the same as the instance shell account username in Wikitech, as shown here: https://wikitech.wikimedia.org/wiki/Special:Preferences#mw-prefsection-personal

That will already work and I think that I can also get the group filtering (wmf or nda members only) working now.

John Joyce from DataHub has acknowledged our issue and is aware of a path to fix, but hasn't yet committed to a fix.

I've offered to report the bug on GitHub if it would help.

I have created an upstream bug report, as per John's request: https://github.com/datahub-project/datahub/issues/4915

Change 791061 merged by jenkins-bot:

[operations/deployment-charts@master] Update the LDAP authentication for DataHub

https://gerrit.wikimedia.org/r/791061

I am merging this patch which retains the use of uid as the primary identifier, but it now correctly filters for wmf or nda group membership.
I see this as a benefit that should be deployed even without the switch from uid to cn, which we currently can't do because of the known bug.

Maintenance_bot removed a project: Patch-For-Review.May 16 2022, 1:31 PM

I added some more information to https://wikitech.wikimedia.org/wiki/Analytics/Systems/DataHub#Accessing_DataHub which explains clearly which username must be used for DataHub and how to ascertain what it is.

Have auth linked to a consistent identifier everyone has access to

Technically this is done, in that everyone has a uid and they have access to it. I understand that we would prefer to use the cn value, but until the upstream bug in DataHub is fixed we can't make use of it.

Define roles and access rules based on your auth

This is already possible, but I haven't yet seen a list of roles and expected rights. We have a datahubadmins group who have all platform privileges.

Has anyone carried out any work on ascertaining who will be our data stewards?

Without this, I'm not sure that there is currently any more work to be done on this ticket.

BTullis updated the task description. (Show Details)May 17 2022, 3:19 PM

BTullis updated the task description. (Show Details)May 18 2022, 9:05 AM

• EChetty moved this task from In Progress to Blocked on the Data-Catalog board.May 19 2022, 9:40 AM

BTullis moved this task from In Progress to Paused on the Data-Engineering-Kanban board.May 19 2022, 9:52 AM

BTullis mentioned this in T309382: DataHub rights assignment is case-sensitive.May 27 2022, 9:19 AM

I have noticed a gotcha, if perhaps not strictly a bug. T309382: DataHub rights assignment is case-sensitive
I'm not yet sure how best to fix this. Perhaps we could downcase the username in the JAAS configuration, or perhaps it will just go away once we T305874: Switch DataHub authentication to OIDC.

In T307711#7930925, @BTullis wrote:

Has anyone carried out any work on ascertaining who will be our data stewards?

Not yet, and I don't want to hold this up on that work, it'll take a long time to define our data governance approach.

Without this, I'm not sure that there is currently any more work to be done on this ticket.

I agree. What was that hiccup the other day, where I didn't have access and then you did something and I did? Is that anything to worry about?

Milimetric moved this task from Paused to Ready to Deploy on the Data-Engineering-Kanban board.May 27 2022, 5:52 PM

Without this, I'm not sure that there is currently any more work to be done on this ticket.

I agree. What was that hiccup the other day, where I didn't have access and then you did something and I did? Is that anything to worry about?

I'm not 100% sure on the root cause of that incident, but I don't think that it's anything to worry about either.

After I made a change to the authentication configuration (https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/791061/3/charts/datahub/charts/datahub-frontend/jaas-ldap.conf) I purged and re-imported all of the LDAP users.
I was also able to delete the wmf and nda groups, since the membership of either one or the other is now enforced by the authentication mechanism.

I had made a group called datahubadmin which originally had 12 members (eveyone on the DE team) - but after the delete/reimport, for some reason the membership of the group had dropped to 4. We can add these missing users back and that works, so I'm not going to investigate any more along those lines at the moment.

So I'm happy to mark this as resolved, if that's OK.

Emil is still having a problem authenticating. When he logs in, his username doesn't have the groups that I add for user echetty.

I've investigated this a little and I can't yet find any cause for this.

Here are the database references to echetty:

MariaDB [datahub]> select * from metadata_aspect_v2 where urn like 'urn:li:corpuser:echetty%' limit 11;
+-------------------------+-----------------+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+----------------------------+-------------------------+------------+
| urn                     | aspect          | version | metadata                                                                                                                                                | systemmetadata                                                                                                               | createdon                  | createdby               | createdfor |
+-------------------------+-----------------+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+----------------------------+-------------------------+------------+
| urn:li:corpuser:echetty | corpUserInfo    |       0 | {"fullName":"Emil Chetty","lastName":"Emil Chetty","firstName":"Emil Chetty","active":true,"email":"echetty@wikimedia.org","displayName":"Emil Chetty"} | {"lastObserved":1652886806252,"runId":"ldap-2022_05_18-15_13_25"}                                                            | 2022-05-18 15:13:47.671000 | urn:li:corpuser:UNKNOWN | NULL       |
| urn:li:corpuser:echetty | corpUserKey     |       0 | {"username":"echetty"}                                                                                                                                  | {"lastObserved":1652886806252,"runId":"ldap-2022_05_18-15_13_25"}                                                            | 2022-05-18 15:13:47.671000 | urn:li:corpuser:UNKNOWN | NULL       |
| urn:li:corpuser:echetty | groupMembership |       0 | {"groups":["urn:li:corpGroup:76fbf709-8faa-47e0-b31e-dee18a1b403d"]}                                                                                    | {"registryVersion":"0.0.0.0-dev","runId":"no-run-id-provided","registryName":"unknownRegistry","lastObserved":1654111422348} | 2022-06-01 19:04:51.058000 | urn:li:corpuser:UNKNOWN | NULL       |
+-------------------------+-----------------+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+----------------------------+-------------------------+------------+
3 rows in set (0.001 sec)

This seems to support the group assignment, shown here:

https://datahub.wikimedia.org/group/urn:li:corpGroup:76fbf709-8faa-47e0-b31e-dee18a1b403d/members
https://datahub.wikimedia.org/user/urn:li:corpuser:echetty/groups

So hopefully it's just a matter of making sure that Emil logs in with his username in lowercase, as explained in: T309382

Confirmed, logging in with a lower case username works for @EChetty.

I have added a note to this page about the requirement to use a lower case username as well: https://wikitech.wikimedia.org/wiki/Analytics/Systems/DataHub#Accessing_DataHub

BTullis mentioned this in T305874: Switch DataHub authentication to OIDC.Aug 24 2023, 10:11 PM

User Experience: AuthenticationClosed, ResolvedPublic4 Estimated Story PointsActions