durusmail: quixote-users: Single-signon in Quixote
Single-signon in Quixote
2005-02-02
2005-02-02
Quixote + SQLObject Sessions (was Single-signon in Quixote)
2005-02-02
Re: Quixote + SQLObject Sessions (was Single-signon in Quixote)
2005-02-09
2005-02-09
2005-02-02
2005-02-02
2005-02-02
2005-02-03
2005-02-03
Single-signon in Quixote
Titus Brown
2005-02-02
-> I wonder what other people think about following. I want to build a
-> system that will authenticate users across multiple sites, so users
-> have to log in only once on one site, and then just click on a link
-> and go to another site with their credentials. All sites are Quixote
-> applications on different subdomains on one Apache server with
-> mod_scgi. PostgreSQL will be used for sessions.
-> What is the strategy for creating thing like that? Has anyone done it
-> before in Quixote?
-> Any tips would be greatly appreciated :-)

I've written something that could easily be extended for this purpose.
(I didn't, yet, because I only have one bioinformatics Web app and
don't need to split users across multiple sites/apps.)

I have two components:

* my normal PostgreSQL session handling code, that authenticated etc.
        against a database; see the wiki for e-mail me privately
        for the code.

* a Web services API on top of that database that let you retrieve information
        about a given user (by unique ID or some such).

The only additional component I'd need is one that, for any particular
Web site, accesses the Web services API to retrieve information on the
user from the central Web site.

Overall the code is pretty simple to write (I can point you towards the
project -- it's called Cartwheel, and it's on SourceForge) but the
hardest part is the session handling code which is already cleanly
separate.  So I'd suggest just starting from that code & building your
own Web services API.

A couple of additional points:

* this setup is a client-server setup, and if the central auth server
        goes down, *poof* no more user auth.  You can fix this by
        caching user information locally (for each Web site) but you
        would have to worry about synchronization, perhaps.

* the central server is also a choke point.  Not very stable for many
        servers.

* Web services (XMLRPC in my case) are pretty slow across long
         connections, at least in my hands.  YMMV.

Another way to go -- and this requires more up-front coordination but is
less centralized -- is to use a universal unique ID system (UUID).
Design the UUID so that each server has its own "space" of personal IDs,
and each server can be identified from a given UUID.  Then pass the
UUIDs around and use those as universal IDs.

I'm curious as to what you end up doing, let me know how it goes...

cheers,
--titus

reply