Ah, we're missing a link to the page: https://idm.wikimedia.org/wikimedia/whoami/

Design has been handed over, but will require implementation by us, as this is not part of what is being offered by the design team.

This patch https://gerrit.wikimedia.org/r/c/operations/software/bitu/+/959211 will enable SSH Keymanagement for WMCS in the Bitu IDM.
SSH key management appears to be the only remaining feature of OpenStackManager in Wikitech.

Rereading the answer for Juniper:

Project is in development, see: https://phabricator.wikimedia.org/T189531

We might need to change the Juniper configuration in CAS from:

Plan for testing rollout of Debian packages:

@SEgt-WMF One thing that might be an issue, and that honestly not clear at all to the users: There's a small delay between setting the new password and it being actually active. This is typically a minute or so, but it's enough that it also gave me an error when testing.

We're looking into why it's not working. In the meantime you should be able to use the password reset from: https://wikitech.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page

New Python fact has been rolled out.

One issue we ran into with Gitlab also involved Gitlab not being able to locate OIDC attributes. This was as a result of how CAS returns the attributes. By default CAS will return the attributes in a nested format, which almost nothing expects.

The new version of the script have been deployed, but not yet configured in Hadoop.

Plan of action:

@BTullis I think that was one of my regressions with my updated script. I think I stripped out the /default/rack bit, but added it back in.

Definitely plausible. But it won't be a feature of the new IDM at launch, and we don't want the new IDM to be a blocker for any progress on this task, so we should probably save that for later and build something without it in the nearer term even if it's imperfect. (Adding @SLyngshede-WMF and @joanna_borun to confirm that sounds right.)

Alert has cleared.

Leftovers from a failover test.

We previously suspected that the issue was that CAS nested the attributes it returns via the profile, but gave up on pursuing that as I believed it would require patching OmniAuth in Gitlab.

I did a diff of the configurations for idp and idp-test, and they are basically the same, none of the settings that could affect OIDC differs.

When I attempt a login I get the following:

@Jelto I think you have the wrong client id. Should be: "gitlab_replica_oidc".

The fixes that worked a little, but failed to provide correct user information was to set the following in CAS:

For OIDC via CAS in our Python applications we're relying on a special OIDC backend https://github.com/python-social-auth/social-core/blob/master/social_core/backends/cas.py this deals with the fact that CAS will put attributes fetched from the userinfo URL into a JSON structure that looks something like this:

@Jelto No not yet, and I just tried to login still the same error. I can see how it might work if the accounts are simply linked, but that will still be an issue for new users.

We do have sort of a work-around, which is currently for review. We let the IDM call the createUser api on mediawiki, so that the database object for the user already exists when the authentication via LDAP is done.

We didn't find a solution yet, but I'll spend some time looking into the CAS side of things tomorrow.

Depending on how the Gitlab OIDC pulls information we might have to change: userinfo_endpoint in client config options. If Gitlab users to profile to pull the email, then we need to set it to: /oidc/oidcProfile default appears to be /user_info

From testing I don't think this is an issue anymore. The patch would fix the issue I believe, but given that we're not seeing the warning anymore, I can't verify.
I have tested that the patch doesn't break the htpasswd function, see:

@MoritzMuehlenhoff did you rebuild the irc-ratbox deb for the Bullseye hosts?

I'll just push to get a review today so we can merge and close this.

I think we can close this.

No problem here either.