On 11 February 2015 at 03:33, Donald Stufft <don...@stufft.io> wrote: > > In a slightly hypocritical view point, I actually think that at some point we > should get something like id.python.org which is an IdP and switch all of the > *.python.org sites to authenticate against that instead of keeping local > user accounts. This would reduce the number of passwords that Python inflicts > on people but it still keeps authentication within our (PSF/Python/whatever)'s > control. This is more along the lines of implementing SSO using a federated > auth technology than actual federated auth though.
This is the approach that Fedora uses [1], and it offers a lot of benefits in making it possible to implement infrastructure services as independently updated components, while using role-based access control for authorisation management. One of the key practical benefits is providing a single place for people to register their public SSH keys, while one of the key community building benefits is that reliably federating identity across the various Fedora infrastructure services enables the badge system that allows people to more easily be appropriately credited for their contributions to the project. If you start doing 2FA, then the identity management server becomes the place where you do your token management. If we keep the focus specifically on PyPI, then the benefits of breaking out a separate identity service mostly amount to making it a bit easier to introduce a build service in the future (since PyPI and the build service would be peers using a common identity provider, making it easier to accommodate things like alternate experimental PyPI front ends or separating the upload service from the publishing service). Things start to get a bit more interesting once we consider a world where mail.python.org has been upgraded to Mailman 3, and we actually have the concept of a "user profile" for the mailing list infrastructure (as part of the HyperKitty archiver/web gateway). In that case, then having HyperKitty/Mailman 3/PyPI sharing an identity provider would make it feasible to let user's opt in to listing their PyPI packages on their mail.python.org profile, which may provide useful context in some discussions. And then once we expand our sphere of consideration even further into CPython core development, then I think core developers would gain the most in the near term, as we touch almost all the major identity silos (hg.python.org, pypi.python.org, buildbot.python.org, bugs.python.org, wiki.python.org) regularly, with the release managers also needing to deal with www.python.org. It's also worth noting that both of the current workflow improvement proposals suggest adding yet another identity silo in the form of a forge.python.org service. Longer term, the shared identity model does offer a benefit in terms of reducing barriers to entry: it means that anyone that has created an account on PyPI to distribute software, or on Mailman 3 to subscribe to a mailing list, will already have an account that lets them file bugs on bugs.python.org or submit pull requests on the future forge.python.org. Another aspect to consider is that once you decide to have a single authoritative identity provider *within* the ecosystem, it's also possible to adopt models like the one Stack Overflow uses, where you can *link* other profiles to your account and use them to login once you do, but you're still required to be able to authenticate directly with a password (If I recall correctly, DISQUS uses a similar setup, although I think the "native" password controlled account is optional there). So this approach isn't necessarily about "no social auth allowed" - it's about managing the risk of what happens if an external identity provider goes away at some point in the future. Cheers, Nick. [1] https://admin.fedoraproject.org/accounts/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
