To Whom It May Concern, this is my student application for this years google summer of code for the debian SSO project- i removed the boring parts about myself ;)

Student Application

Description of the Project

Status Quo

For some time now, the Debian project has a single sign on (SSO) solution¹ that users can use to authenticate against on tracker.debian.org, nm.debian.org, contributors.debian.org and paste.debian.net. The SSO solution² uses client browser certificates and is maintained by Enrico Zini (enrico@debian.org). It does not bring its own user database, but forwards authentication to mod_ldap³. There are two authentication backends, ldaps://db.debian.org, which is the main debian developers database, and ldaps://alioth.debian.org. Alioth.debian.org was/is a FusionForge installation, which acted as the main code management system for the debian project. And in connection with sso.debian.org it acted as a backend for ‘guests’ and Debian Maintainers. Alioth was replaced by salsa.debian.org, which is a gitlab installation that went live in december 2017 and left beta in the beginning of 2018. But salsa.debian.org does not provide an authentication backend for sso.debian.org, which means, as soon as alioth.debian.org will be gone, there is one backend missing. Sso.debian.org is also only a single sign on solution, but not a user management solution. There is no way for users to reset their password or to delete their account. Another interesting feature would be to provide an interface to manage SSH or OpenPGP keys. And last but not least, sso.debian.org only provides an SSO solution based on certificates. There are other technologies like Oauth2 or SAML, that are more widespread and integrated in wide range of products. Some solutions have been mentioned in a discussion about the sso.debian.org service on debian-devel in August last year⁴. There is also a wiki page⁵ collecting facts about the SSO service and listing some ideas for a makeover.

Project Goal / Devilerables

As described above, there are two main tasks:

• sso.debian.org frontend: for one there is the expansion or replacement of sso.debian.org with Oauth2 and/or SAML. There have been some proposals on debian-devel about this topic, whic will have to be tested. If there is no suitable solution the existing sso.debian.org solution has to be extended with additional authentication mechanism or a new single sing on solution has to be implemented.
• sso.debian.org backend: the second task is the design, development and implementation of the guest-backend of sso.debian.org. This platform should provide means to manage one’s own account data, reset a password, manage keys for OpenPGP or SSH and delete an account. As with the sso solution, there will be one part research in existing solutions as well as development of an own solution and subsequently the design and development of the solution.

Any Work, be it research or be it programming tasks will be documented and published in git. If it turns out that it would be practical to spread the work over multiple repositories, that won’t be a problem (thats what submodules are for). To accompany the work there can be regular written by mail and/or blog post.

Rough Timeline

• April 23 - Mai 14: Get to know the existing sso solution as well as the userdir-ldap system that the Debian project uses to manage the debian developer accounts ⁶. Read and test different SSO solutions. Talk to DSA about requirements/wishes for the SSO platform as well as possible Test-VMs. Maybe talk to package maintainers of possible solutions about their relationship with upstream and upstreams responsivness. Compose an implementation plan, devide in two steps and write an email to debian-devel about it, asking for input. From May 3rd to May 5th there will be the Vienna Linux Weeks which would be interesting- also to get in contact with Debian contributors. But there will also be an big exam on May 4th. It’s not clear yet if that leaves time for attending the Linux Weeks.

• May 14 - June 11: If time permits, go to Mini-DebConf in Hamburg, which will happen from May 16-20 to do some community bonding and talk over some ideas. Start with step one with designing the LDAP database for the backend and at the same time start implementing the chosen SSO solution on a test server. The goal to have basic prototypes for both the backend and the frontend before June 11. Give regular updates to mentors about progress and/or obstacles.

• June 11 16:00 UTC Mentors and students can begin submitting Phase 1 evaluations

• June 15 16:00 UTC Phase 1 Evaluation deadline

• June 15 - July 9: Start with step 2: implement a webinterface for the management of the backend. Refine the existing prototypes; find and remove bugs, check deliverables. Create a test application that authenticates against the chosen SSO solution or even propose a patch for an existing debian service to make that service authenticate against the new solution.

• July 9 16:00 UTC Mentors and students can begin submitting Phase 2 evaluations

• July 13 16:00 UTC Phase 2 Evaluation deadline

• July 13 - August 4 Bugfixing, testing, puppetize existing setup; report to debian-devel about the project status; Start writing down future features;

• August 6 - 14 16:00 UTC Final week: Students submit their final work product and their final mentor evaluation