Debian SSO documentation

Debian has a single sign on system for authenticating on web services. It runs on sso.debian.org and is sometimes referred to as "web password".

The web password is one way of logging into Debian's single signon system. There may be other ways (such as via Alioth) deployed in the future. Unfortunately this means that at the moment only Debian Developers can authenticate using single signon.

There is work being done to change that, hopefully an announcement will be made soon.

Documentation for Users

Setting up a web password (Debian Developers)

The web password single signon method only works for Debian Developers.

To set up a web password, you need to log on db.debian.org ("update my info") and set the password where it says: Change web password (for https://sso.debian.org/).

Note that the web password is different from the db.debian.org password, and is also different from the sudo password.

Note that after changing the web password via db.debian.org, it takes about 20 minutes for it to be distributed to LDAP, and take effect.

Debian services using the Debian single signon

This is a list of Debian services using the SSO, which you can use to test if your web password works:

Web browser functions needed

The Debian SSO requires these web browser functions to be working normally or whitelisted:

cross-sub-domain redirects (foo.debian.org -> sso.debian.org -> foo.debian.org)
cross-sub-domain cookies (debian.org not just sso.debian.org)

Documentation for web application owners

A word on the two A's

First of all, be aware that DACS only does *authentication*, your web application needs to handle *authorization* on its own. It is very important to understand the distinction clearly: an introduction can be found here and here.

Howto setup your web-app with DACS

There is a libapache2-dacs module which needs to be loaded into apache. It needs two places of configuration. - in the filesystem in /etc/dacs - in the apache configuration for the appropriate VirtualHost

When the module is loaded, apache passes REMOTE_USER as usual, but it will look like DEBIANORG::DEBIAN:enrico. The format is federation::jurisdiction:username.

Please do not ignore the federation and jurisdiction: they are an indication of the authentication source. When multiple backends are implemented, the same username may stand for different people according to how they authenticate. For example, enrico@identi.ca (or SOMETHING::IDENTICA:enrico) is not the same person as enrico@debian.org (or DEBIANORG::DEBIAN:enrico).

# TODO Some headers are not passed by default because CGI sucked and people didn't realise fcgi and wsgi don't suck that way. What's in these headers, though?
FcgidPassHeader Authorization
Passheader AUTHORIZATION

<VirtualHost *:443>
        # ... 
        
        # Proper invocation
        AddDACSAuth dacs-acs /usr/bin/dacs_acs

        SetDACSAuthMethod dacs-acs external
        SetDACSAuthSiteConf dacs-acs "/etc/dacs/federations/site.conf"
        SetDACSAuthConf dacs-acs /etc/dacs/federations/debian.org/DEBIAN/dacs.conf
        SetDACSAuthDebug Off
        SetDACSAuthPostBuffer 0
        SetDACSAuthEnvBuffer 32768

        <Location />
                # DACS auth
                AuthType DACS
                AuthDACS dacs-acs

                # DACS ACLs can specify different requirements for different
                # paths in your site. They can be tweaked by sending patches to
                # http://anonscm.debian.org/gitweb/?p=mirror/dsa-puppet.git
                # at modules/dacs/files/per-host/nono.debian.org/
                Require valid-user
        </Location>
</VirtualHost>

For more information

Question from a user

Sorry, I did not find a better place (like bugs.debian.org/sso.debian.org)... Would it be possible to set up SSO for the Alioth mailing lists ? That would be awesome (and completely outside my skills...) -- CharlesPlessy

DebianSingleSignOn