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, email@example.com (or SOMETHING::IDENTICA:enrico) is not the same person as firstname.lastname@example.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