Debian SSO documentation
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 referrer sending (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
- 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