[Systems] Unified login to SL servers

[Sascha Silbe]

Excerpts from Aleksey Lim's message of Tue Aug 17 16:16:03 +0200 2010:

> At first, I was thinking about OpenID but Bernie said about CAS[2]
> (in such case we can implement centralized, in comparing w/ OpenID,
> accounting system for all SL services).
The Wikipedia description of CAS sounds a lot like OpenID. The RubyCAS [3]
"CAS vs. OpenID" section doesn't explain differences on the protocol /
conceptual level either. One of the major weaknesses of OpenID - the
redirection from a potentially untrusted website to the trusted, central
login page - is definitely shared by OpenID.

> I found two CAS implementations, one Java based and one lightweight
> Ruby server. Last one doesn't have feature to create new users but has
> many backends (including custom) to get accounts info.
RubyCAS supports LDAP so it should work well enough with our existing
infrastructure.
One thing I can't find out is whether it supports authentication with
something else than pre-shared keys (AKA passwords), in particular by
using SSL client certificates. See my previous ramblings [4,5] and also
Daniel Clarks reply [6] for why this is crucial.

My current plan is along the following lines:
1. Let Browse import the Sugar private key and generate a self-signed
   certificate from it.
2. Let each web service request a client certificate.
3. Identify and possibly authenticate + authorize the user based on the
   public *key* (not certificate) by checking against a central server
   (e.g. LDAP).
4. Service-specific preferences can be changed at each service by the
   usual methods. Global preferences (e.g. real name) can be changed
   using a web interface on the central server or CLI tools from a
   shell account. Add links from service-specific preferences to the
   global ones.

I have #1 (*) and #2 [7] working in principle, but the usual compatibility
issues are a stumbling block. The easiest way to resolve these is to set
up an additional web server front end at a different IP address (many
brain-dead firewalls block anything but port 80+443 so using a
different work isn't going to work). Browse can ship a modified start
page; wiki pages can mention the alternate address for users of
"compatible" browsers and the benefits (automatic login, no password
required) it gives. For "legacy" users and those using foreign computers
(e.g. in internet cafés) we can continue to offer password-based logins.
We might want to disable password-based shell access, though.

As usual, I'm busy working on other things so any help is appreciated.
And if you think your approach is better or a good stepping stone until
we got something better, don't block on me.
The reason why I think CAS (or OpenID for that matter) isn't a good
solution is because it still requires the user to explicitly "log in".
The time required to get something like CAS to work is better spent
on a seamless experience IMO.

Sascha

> [2] http://en.wikipedia.org/wiki/Central_Authentication_Service
[3] http://code.google.com/p/rubycas-server/
[4] http://lists.sugarlabs.org/private/systems/2009-October/000871.html
[5] http://lists.sugarlabs.org/private/systems/2009-October/000872.html
[6] http://lists.sugarlabs.org/private/systems/2009-October/000874.html
[7] https://sunjammer.sugarlabs.org:8443/ssltest.php
(*) openssl req -x509 -out cert.pem -new -key ~/.sugar/default/owner.key -subj "/CN=Sascha Silbe" -days 99999 -utf8 -batch && openssl pkcs12 -export -nodes -password pass:a -in cert.pem -inkey ~/.sugar/default/owner.key -name Sugar -out x.p12 && pk12util -i x.p12 -d ~/.sugar/default/org.laptop.WebActivity/data/gecko -K '' -W a
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/private/systems/attachments/20100817/a956b1fe/attachment.pgp