To whom it may concern, this is my report over the first few weeks of gsoc under the umbrella of the Debian project. I’m writing this on my way back from the minidebconf in Hamburg, which was a nice experience, maybe there will be another post about that ;)

So, the goal of my GSOC project is to design and implement a new SSO solution for Debian. But that only touches one part of the projects deliveries. As you can read in the description Alexander Wirth originally posted in the Debian Wiki¹, the project consists of two parts, where the first one is the design and coding of a new backend and self-service interface for Debian guest users (this includes the accounts of Debian Maintainers).

It should also allow creating and selfservice for guest users and DMs. Those users belong into their own backend and should be suffixed with -guest

So after getting in touch with my two mentors, Alexander (formorer) and Nicolas (babelouest), we talked a bit about how to communicate and organize meetings; then i started looking into possible solutions for the guest backend. This is actually the more time critical part, as the current -guest accounts are stored on alioth and alioth will be shut down at the end of may. But Alexander assured that he will maintain the guest user database by hand for the time being, until the new -guest account solution can go into production.

Even before the official acceptance for GSOC i thought about how to implement this and i also talked a bit about that with Alexander. The first decision to make was to choose a data store for the backend. LDAP was a candidate but it would also have been possible to use relational databases. But LDAP is already being used in Debian in the userdir-ldap project and there is also more support for LDAP from potential existing SSO solutions, so it was an obvious choice. There second decision to make was to choose a Webframework for the self service web frontend. I already had some experience with Ruby and Rails, but there are some Django applications in Debian ecosystem (i.e. tracker.d.o.) and i wanted to learn something new. Also i had to do a Python course at the university so wanted to bring the mostly theoretical knowledge to practical use.

Alexander asked me to write a design document for the guest-backend, which i [published a few weeks ago] (/notes/debian-guest-account-backend-design/). Nicolas gave some feedback on the document right away and Alexander and i reviewed the design document again this weekend during MiniDebConf which resulted in some additional requirements for the backend, like the support of groups.

In the few weeks after writing the design document, i looked more into the possibilities of the different ldap-django extensions. There are two ldap extensions that allow authentication against an ldap server in the debian archive (django-auth-ldap and django-python3-ldap), where the former has a slightly better popcon score. And there is also django-ldapdb, which maps the objects from ldap to django models; django-ldapdb was not packaged yet, but the day i wanted to create an ITP, #898750 was created and the package was uploaded a few days ago. Also i started getting into Django coding itself. I went through most of the Writing your first Django app tutorial and started by writing simple webapps. Also simpleisbetterthancomplex has a lot of helpful Django resources.

I then also started coding the self service web application and had a basic prototype ready after a week. The prototype allows to register an account, which will only become active after the email address has been confirmed using a token. Activated accounts can login and modify their profile, which at the moment only means changing the password; the next step will be to implement a password reset feature, implement an admin interface, add some more fields to the user profile, etc…

You can see some screenshots of the prototype below:

I’ve named the webapp ‘nacho’, you can see the code in my salsa repo.