DICE Labs, which I originally suggested back in early 2008, is now an reality. Whilst I’ve been running a number of ‘not a service’ systems for a while, this puts them on an official footing, and lets a much wider set of folk play around with them than just the CO team. Lots of things that I built in the past that now run in production went through this ‘Not a Service’ phase, including bugzilla and the wiki. Jabber and iFile were also built as part of this process, but aren’t part of the DICE Labs launch offering as they’re in the process of graduating into fully fledged services of their own.
January 26, 2009
September 29, 2008
As this blog has suggested in the past, I’m in the process of moving things off duffus, and at the same time putting them on a more stable, LCFG managed, footing. The latest system to be moved is iTalk, a local installation of the JWChat application, which provides a web based interface to the Informatics Jabber service. As the service name http://italk.not-a-service.inf.ed.ac.uk/ suggests, this is not a production quality service – but it should be usable by anyone who has access to our Jabber service. Please do try it out, and let me know how you get on.
An older post provides some interesting technical details about the configuration of this service.
September 19, 2008
Back in May 2007, I wrote a blog post discussing hypothetical mechanisms for integrating the JWChat web-based Jabber client with a web SSO solution such as WWW-Negotiate or cosign. In my not-so-copious spare time, I’ve been working on implementing this, and now have a working solution to share. Skip to the end of this post if you’re just interested in the code.
In order to perform SSO, the client must authenticate the encapsulated HTTP connection in the usual way. The proxy must then hijack the client’s authentication step with the Jabber server, and replace it with one that uses credentials delegated to it as part of the HTTP connection establishment. Our credentials are all Kerberos based, which simplifies this step hugely. Here’s a rough description of how it all works when using the WWW-Negotiate HTTP authentication mechansim
- The client makes an HTTP connection to the proxy, which is authenticated using the client’s Kerberos credentials. The proxy performs this negotiate, and stores the delegated credentials
- The client and the jabber server start up the XMPP connection via the proxy
- Providing the authentication step succeeded, the proxy intercepts the server’s list of acceptable authentication mechanisms. If the server indiciates that GSSAPI is acceptable, the proxy adds the SASL EXTERNAL mechanism to the list. (EXTERNAL is a trivial mechanism which just indiciates that the server is prepared to accept an out-of-band authentication method)
- The client initiates an authentication using the EXTERNAL method
- The proxy intercepts the first EXTERNAL authentication stanza, and replaces it with a GSSAPI stanza, created using the stored credentials that were delegated in the first step.
- The proxy and the server continue to exchange stanzas, without involving the client, until the connection establishment either succeeds or fails.
- The proxy returns the success or failure stanza to the client – which views this as the result of its attempt at EXTERNAL authentication.
- Normal operation resumes
However, as I’ve discussed previously, the level of client side configuration required by WWW-Negotiate, especially when credential delegation is required, makes it difficult to deploy in a heterogeneous environment. That’s why we use Cosign as our WebSSO solution, rather than using Kerberos directly, and pretty much requires this solution to work with Cosign.
Cosign complicates things because it’s based on redirects, and (ultimately) on user interaction following those redirects. It also has a pretty complicated web-server side module which can’t be easily implemented within the python-based Punjab (rewriting the cosign client as a python Twisted module might be an interesting side project, but not for today). Cosign’s redirects means that you can’t easily use it to authenticate XMLHttpRequest connections, especially when those connections are POSTd. Instead, what we must do is use Cosign to authenticate the fetch of the HTML landing page. Once this page is fetched, and authenticated, Apache has taken care of populating the cosign cookie on the client, and placed a ticket file containing the delegated credentials on the server.
This all actually simplifies things for the proxy. Instead of having to accept a WWW-Authenticate GSSAPI handshake from the client, it just has to check for the presence of a cosign cookie. Having found the cookie, it can then locate the ticket file on the server, and tell the proxy to use that file to obtain credentials with which to authenticate to the server.
Enough talk, now for the patches …
JWChat, or more correctly, the JSJaC connection library that it uses requires a couple of small patches. The first fixes a bug with session restarts, which would otherwise break Punjab’s XML parser. The second adds support for using the EXTERNAL SASL authentication mechanism
The major changes are to Punjab. This patch adds support for doing both cosign and WWW-Authenticate authentication (if you aren’t interested in cosign, the patch should still function correctly – it will just skip the cosign parts when cosign cookies aren’t present with the incoming connection). In order to do GSSAPI authentication from punjab, you will also need my python-gss module.
Configuration wise, in order to use cosign, punjab must be accessed as a proxy through a cosign authenticated location on your web server. The JWChat html pages must also be served through a cosign authenticated location, which requires delegated tickets.