jauto

(this page contains a copy of my original Summer of Code application for this project)

Jabber HTTP-Auth Suite

TOC

• Hmm… (Introduction)
  • Vision
• How? (Project modules)
  • HTTP Client
  • HTTP Server
  • XMPP Server
  • XMPP Client
  • Variety of
    languages
• Why? (Benefits)
  • How the idea was born
  • In global view
  • Why would users like this?
• When? (Schedule)
• Who? (About me)

Hmm… (Introduction)

Do you remember your last time working on a new machine, typing thousands of passwords on every website you wanted to visit? it’s me again, I said it a moment ago…. Wouldn’t it be wonderful if you could authenticate once and then just say yes, it’s me again, I’d like to talk with you now…?

Talk…? Talking is one of the most popular ways of using the Internet. But - for some reason - you don’t need to provide your password every time you want to talk with another person. Somehow they know that it’s you. So why HTTP servers do not know? And why not to teach them how to do this?

There already exists a protocol (JEP-0070) which enables HTTP server to verify HTTP requests via XMPP. It describes how HTTP server can take advantage on strong authentication provided by XMPP and just simply associate unknown (until now) user clicking a link in browser with a well-known and “well-authenticated” XMPP user.

Vision

And now, imagine that your browser acts like an (invisible) XMPP client. Sure, it will need to know your password, but this is just one password (and it’s not same-password-everywhere solution!). In exchange for this one password, your XMPP-enabled HTTP browser could automatically confirm all your HTTP requests in background! You don’t need to send any password to HTTP server - just tell the server: yes, I’m a happy Jabber user! and everything else will happen automatically.

How? (Project modules)

Full suite consists of four components, which can be divided into groups by their location (client/server) and protocol which they use (HTTP/XMPP). Of course, it wouldn’t make much sense to write full HTTP or XMPP server, nor Internet browser just to have easier HTTP authentication. This is why the result of this project will be a set of plugins/addons/patches to already existing software. Since it is really motivating to work on something that I could really use, this solution will work with My Favorite Software™

HTTP Client

HTTP Client needs to understand requests of XMPP authorization and send appropriate information to HTTP server. This module will be implemented as Mozilla Firefox extension, written probably in JavaScript.

HTTP Server

HTTP Server sends XMPP authorization requests to HTTP client and authenticates user via XMPP server. This component will be implemented as Apache HTTP Server module(s), written probably in C.

XMPP Server

XMPP Server verifies (by exchanging stanzas with XMPP Client) if really that user made the request.Luckily, this module is planned to be a Jabber server component, and the nice thing about them is that they can be easily plugged to different Jabber server software. Language planned for this module is Python.

XMPP Client

XMPP Client confirms that the request was really made by the user. (Of course, sometimes it will have to deny to stop cruel coworkers trying to click “log in” button just before you). To make my dream come true, I’ll have to integrate this module with Firefox, either by including simple XMPP client in already mentioned extension, or reusing (a bit modified) Jabberzilla - this is still to be determined.

However, I cannot fail the trust of My Favorite Jabber Client’s developers, so I’m also planning to write a small patch for Psi, adding JEP-0070 support (C++).

Variety of languages

Someone could say that using so many different programming languages (C, C++, JavaScript and Python) in one project may only help me to fail. However, different modules of this project will run in different environments, and each of them has its preferred coding ways. Moreover, this variety will provide a better stimulation for my brain and help to overcome “I’m getting bored with this”problem - taking a look at another module will be like a journey to another exciting world.

Jobble project, which I spend much of my free time on, requires me to use JavaScript, PHP, Smarty templates and Perl at the same time and I admit that I enjoy working with this mix.

Why? (Benefits)

How the idea was born

The idea of this project came to my mind while planning how to simplify logging into Jobble site I’m working on with my friend. I remembered about JEP-0070, and happily noticed that JIDs used as user identifiers perfectly fit this protocol.

In global view

There are many popular services right now which use email address as user id. As IM becomes more and more popular and begins to successfully replace email, we may expect JID to take over the place of most suitable user identifier. This is already true for Jabber-related services, like Jabber users maps. Since JID is the only piece of information needed to perform HTTP authentication as defined in JEP-0070, transition from conventional authentication methods becomes trivial.

Why would users like this?

As already mentioned in the introduction, any way to reduce the number of passwords needed to be remembered is a blessing for a user. There are many methods to achieve this, but only solution described here has this unique combination of features:

same info everywhere

simply provide the same JID for every site: this can compete even with so widely used, so unsecure same-password-everywhere technique

same power everywhere

your XMPP account becomes a universal key, which is always with you

no passwords on the wire

there are no passwords at all

one click to authenticate

just send your JID to HTTP server (your XMPP-enabled browser will confirm your requests)

When? (Schedule)

Since the beginning of Summer of Code overlaps with end of semester on my university, I am not going to hide that first two weeks may bring a little progress. However, just after the semester is finished, the best way to forget about school will be to devote entirely to this project.

May 23 - May 24

setting up project website, repository, etc

May 25 - June 11

research

design (with more-or-less dummy prototypes)

preparing for exams at school

June 12 - June 18

Psi support

writing exams

June 19 - June 25

basic XMPP Server component

June 26 - July 2

Firefox “HTTP Client” part

July 3 - July 9

Apache module

July 10 - July 16

finishing XMPP Server component, connecting with Apache module

July 17 - July 30

Firefox “XMPP Client” part, merging with “HTTP Client” part

July 31 - August 6

time slot reserved for unexpected time-consuming problems

August 7 - August 20

final testing, finishing documentation, packaging

August 21

end of project

Who? (About me)

I’m a 4th year student of Warsaw University of Technology, Faculty of Electronics and Information Technology.

I became interested in Jabber about 3 years ago and I was instantly hit by it’s flexibility and extensibility. Open and powerful protocol enabled anyone to create (unseen, or - at least - not so popular in other networks) useful bots and agents, providing access to dictionaries, weather info, etc, etc. Jabber is more than IM - I thought.

Soon after I started using Jabber, I became interested in modifying Psi client (which is one of the most popular in Poland, both among users and programmers wishing to modify something). I published about 20 - smaller or bigger - patches since then. Then came summer of 2004, and I set myself two targets: learn Python and write a Jabber bot. Soon I noticed that the best idea is to do both at once: this is how Suuga - my math bot - was born. Summer seems to be the most productive development time for me: in summer 2005 I started working on Jobble Jabber Users Map, together with my friend. This project is still being actively developed, and working on it pushed me towards Jabber HTTP-Auth.