[Systems] Unified login to SL servers

Aleksey Lim alsroot at member.fsf.org
Wed Aug 18 07:53:30 EDT 2010


On Tue, Aug 17, 2010 at 05:46:46PM +0200, Sascha Silbe wrote:
> 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.

Well, my case is much simpler :), I just have to face this to make
bazaar.sl.o useful in public and it will be overkill to me to write
web code to manage regular account related stuff. So, my current plan is
pointing rubycas-server to our wiki users db (bazaar users need to have
wiki account to login to it).

> 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/



> _______________________________________________
> Systems mailing list
> Systems at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/systems


-- 
Aleksey


More information about the Systems mailing list