If we are going to do this kind of shuffle I'm a fan of an authentication/authorization service model here, but it's all complications and implementation specifics. Plus, more things in LDAP is mentally painful :)

Input from Security-Team on the general idea and implementation gotchas would be appreciated.

In T136350#2331516, @bd808 wrote:

Input from Security-Team on the general idea and implementation gotchas would be appreciated.

I just realized that probably doesn't ping them, so @csteipp, @dpatrick, and @Bawolff I would love to hear opinions from you on either using LDAP as a TOTP seed storage or ideas about a proper 2fa service we could run to secure LDAP accounts outside of the current wikitech + Horizon implementations.

If you want to use ldap to store the secret, then mediawiki's Ex:OATHAuth needs to be ldap aware (or have hooks to let another extension swap out the secret). It's ugly, but doable.

If I had to do it over again, I'd look into doing a more federated approach, so Horizon or the labs console would just support mediawiki's OAuth as their login mechanism, and then one system is handling the password and totp check, and the rest of the systems trust mediawiki.

In T136350#2331739, @csteipp wrote:

If you want to use ldap to store the secret, then mediawiki's Ex:OATHAuth needs to be ldap aware (or have hooks to let another extension swap out the secret). It's ugly, but doable.

Agreed. It's bullet #3 in the original description.

If I had to do it over again, I'd look into doing a more federated approach, so Horizon or the labs console would just support mediawiki's OAuth as their login mechanism, and then one system is handling the password and totp check, and the rest of the systems trust mediawiki.

The only thing that makes me sad about this is that it would mean that wikitech remains an LDAPAuth wiki indefinitely blocking my desire to convert it to part of the normal SUL wiki family when we have all of the OpenStack features migrated to Horizon or other related systems. (And yes I know that LDAP is used for more than OpenStack.) I would personally be more excited about consolidating the validation in https://www.linotp.org or something similar.

I've lost track of exactly what features AuthManager supports, but does it allow storing of arbitrary user authentication metadata? Because then once Extension:OATHAuth is converted to use AuthManager, we can just have the authentication provider store and fetch the secret from the generic backend interface.

The only thing that makes me sad about this is that it would mean that wikitech remains an LDAPAuth wiki indefinitely blocking my desire to convert it to part of the normal SUL wiki family when we have all of the OpenStack features migrated to Horizon or other related systems. (And yes I know that LDAP is used for more than OpenStack.) I would personally be more excited about consolidating the validation in https://www.linotp.org or something similar.

I don't think moving to normal SUL is excluded :). If you did move to consuming the wiki's identity in Horizon / etc, then the wiki would need to add something about how long ago the user used MFA to login. So whether they did that on wikitech, or another SUL wiki, it should be the same.

No argument that we do need to consolidate authentication-- linotp would be one way. We're also working on T120484 with an eye towards having the service validate 2fa tokens as well.

In T136350#2332183, @csteipp wrote:

No argument that we do need to consolidate authentication-- linotp would be one way. We're also working on T120484 with an eye towards having the service validate 2fa tokens as well.

We could, in theory, expose that Auth Service via an LDAP interface in addition to a REST interface, if LDAP is the best way of integrating. And so, if we went that route users would login using their public wiki/CentralAuth creds (and possibly have to establish a new username specifically for shell access in order to conform to POSIX). How much do we care to have users use separate accounts for wikitech/Horizon/etc.?

In T136350#2332237, @dpatrick wrote:

In T136350#2332183, @csteipp wrote:

No argument that we do need to consolidate authentication-- linotp would be one way. We're also working on T120484 with an eye towards having the service validate 2fa tokens as well.

We could, in theory, expose that Auth Service via an LDAP interface in addition to a REST interface, if LDAP is the best way of integrating.

LDAP is mostly a convenient shared storage system rather than a desired point of integration. Horizon right now has to reach into the labswiki database to access the secrets. This is cumbersome in the longer term because it is tightly coupled to a storage schema that is not well-defined (the OATHAuth table structure). A REST interface would be much preferable if that it likely in a reasonable timeline. My timeline concerns are related to my desire to build out a new Tool Labs focused admin console and create new account management workflows for volunteers that are less cumbersome and confusing than the current wikitech provided interface. That new service could follow the lead of the Horizon TOTP plugin and muck about in the labswiki database directly, but it would be nice to have a slightly cleaner solution.

And so, if we went that route users would login using their public wiki/CentralAuth creds (and possibly have to establish a new username specifically for shell access in order to conform to POSIX). How much do we care to have users use separate accounts for wikitech/Horizon/etc.?

Posix LDAP accounts are needed in Labs generally for ssh access and I think to integrate with Nova (the OpenStack core system). The same LDAP accounts are also used for authn/authz on a variety of other Wikimedia services including Phabricator, Kibana (Logstash), Graphana, etc.

My hope is that over the next 6-9 months the need for wikitech specifically to be bound to LDAP will be gone. That will require us to provide another entry point for creating and managing LDAP accounts. That may or may not be a feature that gets moved to Horizon.

In T136350#2332046, @Parent5446 wrote:

I've lost track of exactly what features AuthManager supports, but does it allow storing of arbitrary user authentication metadata? Because then once Extension:OATHAuth is converted to use AuthManager, we can just have the authentication provider store and fetch the secret from the generic backend interface.

AuthManager itself provides no storage features at all. Mostly it provides a more flexible method of compositing authn systems at runtime than the old AuthPlugin one provider is all you get method.