Striker should use idp.wikimedia.org for the log-in interface instead of direct LDAP authentication.
As far as I can tell, due to how 2fa is implemented, this is actually not blocked on T359552 - for now we can have the authentication via IDP and still use the homegrown Wikitech 2fa interface, and then simply remove that once 2fa is implemented in IDP itself.
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| Use IDP for authentication | Arendpieter | labs/striker | master | +495 -55 | |
| Use IDP for authentication | Arendpieter | labs/striker | master | +351 -17 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T189531 All Wikimedia developer services should use single sign-on | |||
| In Progress | Feature | None | T359554 Use IDP for authentication in Striker |
Hi Andrew,
I’ve deploy the new 2FA implementation to idm-test.wikimedia.org. If you sign in, you should see a button labeled "Manage two factor authentication”. If you click that you’ll be guided though setting up 2FA for your account. It’s not currently connected to anything, so enabling it will not break or influence your actual 2FA anywhere.
Becuase code moved around internally in Bitu, I have also moved the API endpoint, but the functionality is mostly the same. The test token is also the same.
Example:
import requests
headers = {'Authorization': 'Token 54ba5ed5eec4d6a5931f20e9e849be6fe410cfbd', 'Content-Type': 'application/json’}
url = 'https://idm-test.wikimedia.org/mediawiki/api/totp/'
payload = {'user': 'slyngshede', 'token': '123456’}
r = requests.post(headers=headers, json=payload, url=url)This will return a JSON object. e.g. {"user":"slyngshede","valid":false,"enabled":false}
User is just echoing the username you provided in the post, valid indicates if the 2FA token is accepted and enabled tells you is the user has 2FA enabled or not.
I figured that might be hand to signal to the user that they need to enable 2FA.You can reuse the token in my example for testing, it’s assigned to a test account.
I think there are two ways to approach this:
#2 seems better, assuming that idp is set up for that and is likely to remain stable. #1, on the other hand, I know how to do already.
This seems reasonable to me, but should also be blocked from deployment until IDP and IDM implement T359552: Enable self-service IDP two-factor authentication management.
As the task description states, this task is about #2 as we (or at least I) want that to eventually happen. If you're planning to swap the 2fa backend before T359552: Enable self-service IDP two-factor authentication management happens please file a new task instead of highjacking this one.
I will make a separate task for case #1 but I am also going to orphan this ticket as it is not a requirement for the great wikitech migration.
OK, this task is back to the case #2, log in entirely via idm. I've created T373461 for case #1 which we will do sooner.
Change #1189915 had a related patch set uploaded (by Arendpieter; author: Arendpieter):
[labs/striker@master] Use IDP for authentication
@SLyngshede-WMF, do you know how to create OIDC_KEY and OIDC_SECRET in idp.wikimedia.org in order to test this solution: https://gerrit.wikimedia.org/r/c/labs/striker/+/1189915 ?
@taavi do I need to do something else for https://gerrit.wikimedia.org/r/c/labs/striker/+/1189915 ?
This is pending a response to https://gerrit.wikimedia.org/r/c/labs/striker/+/1189915/comments/a720b9e0_7be59381 where I asked you to manually test your change in a local development environment first. As far as I can tell the lack of a local CAS container and the hardcoded https://localhost URLs mean that there's no way for the patch to work in its current state.
Change #1189915 abandoned by Arendpieter:
[labs/striker@master] Use IDP for authentication
Reason:
no interest more
Change #1250537 had a related patch set uploaded (by Arendpieter; author: Arendpieter):
[labs/striker@master] Use IDP for authentication
@taavi This is the second attempt, where I made several different choices compared to the previously abandoned patch. I chose django-cas-ng instead of social-auth-app-django, mainly because it is single-purpose and has a minimal footprint. Additionally, instead of using a proper CAS setup for local development (until T412826 is finished), I added a minimal CAS Python server for local development.
@taavi I see that no one is interested in reviewing my second pull request, so I’m thinking of abandoning it.