[Chicago] Integrated wiki + forums
cstejerean at gmail.com
Fri Oct 17 00:50:32 CEST 2008
> IBM has a social network product that we're using internally at PSC called
> Connections. It's not too shabby, but it seems like something that could
> just as well be a loose conflagration of best of breed tools. The missing
> piece, imho, is that single sign on authentication / authorization service.
> A few months ago, I spend a great deal of time setting up CAS
> (http://www.ja-sig.org/products/cas/) and getting it to run with Django.
> Massimo has done the same with KPAX.
> CAS has a really simple API, and does a good job of allowing you to choose
> from a variety of auth backends (ldap, database...other stuff), it then
> passes credentials back to the applications through a token...it's up to the
> apps to handle authorization bits. It's a nice scheme. HOWEVER, CAS is a
> total pain to set up. At least, it was for me, as its a JEE app.
> I know that there's some sorts of movement towards distributed auth schemes,
> but none of them seem to tackle single sign on for internal apps. It's a
> space that's sort of been abandoned by Python folks.
> It's really yet another case of the Java enterprise guys handing us our
> asses by providing a few tools that end up making a ton of sense.
> Anywho, I started drafting the above as a blog post last week...kind of
> funny timing.
For internal corporate apps I like the IBM
authentication/authorization model. Applications typically live behind
a reverse proxy (WebSEAL) which talks to Tivoli Access Manager for the
authentication. URLs can be restricted in WebSEAL. If the URL is
allowed WebSEAL creates a security token (LTPA) that gets passed along
to an application deployed on WebSphere. WebSphere is configured to
trust tokens created by WebSEAL and further authorization can be done
at the application level using JAAS.
I spent a good amount of time reverse engineering the LTPA format and
I'm pretty much at a point where I can interop with this kind of an
environment (either by creating a replacement proxy or by creating
applications that can consume LTPA tokens). I've been meaning to
create some pure Python solutions for a while but I haven't had a need
to deploy Python apps in enterprises that needed single sign-on. One
of these days I'll get around to it and create a pair of WSGI
middleware for the token creation and consumption parts.
More information about the Chicago