We will want to be able to open the API for users external to the toolforge infrastructure.
This task is to investigate current practices and options for us to do authentication in toolforge.
Currently we are doing ssl authentication using the client certificates that were generated for the tools (living in the NFS shared folders).
Some options to investigate are:
idp.wmcloud.org
This uses CAS as the sso server.
Supports:
- oauth
- cas
- openid
- saml
- rest
The data that we get back from the server include the ldap groups in the memberOf key:
memberOf [cn=tools.sqlchecker,ou=servicegroups,dc=wikimedia,dc=org, cn=tools.wm-lol,ou=servicegroups,dc=wikimedia,dc=org, cn=tools.jobs,ou=servicegroups,dc=wikimedia,dc=org, cn=project-account-creation-assistance,ou=groups,dc=wikimedia,dc=org, cn=project-cloudvirt-canary,ou=groups,dc=wikimedia,dc=org, cn=project-dumps,ou=groups,dc=wikimedia,dc=org, cn=project-wmflabsdotorg,ou=groups,dc=wikimedia,dc=org, cn=tools.toolschecker,ou=servicegroups,dc=wikimedia,dc=org, cn=tools.cloud-ceph-performance-tests,ou=servicegroups, ...
other projects using it
- Catalyst - https://phabricator.wikimedia.org/T350725
- grafana.wmcloud.org
- https://prometheus-alerts.wmcloud.org/
wikitech
This has no advantage over using idp/keystone
keystone
Has it's own authentication protocol (see docs https://docs.openstack.org/keystone/pike/user/index.html)
It can be federated (use idp underneath) - https://docs.openstack.org/keystone/latest/admin/federation/introduction.html