[JDEV] Single Sign on and stuff

[Michael Hearn]

Well, as there is still debate surrounding the JIG I think I'll just get on
with things here. At the end of the day, JIGs/JEPs are good but at the
moment they are slowing this down. So - first issue: how would it work.

Here is a doc I wrote a while ago, it details my current thinking on this.
Comments please!

Distributed Jabber Authentication
by Mike Hearn (mhearn at neuk.net) Jabber: tweedledee at jabber.org

------------------------------------------------------------------------
This document will assume knowledge of what network authentication is,
and how Microsoft Passport operates.

Jabber network authentication as outlined in this prelimary document
will allow for the following things:

    * Authentication to arbitrary third party websites, without prior
      knowledge of that site.
    * Authentication to arbitrary services and servers, ie FTP servers,
      where both server and client are jabber aware
    * Authentication to services and servers for which the client is not
      jabber aware.

_Website authentication_

This involves using a special authentication website to allow web
browsers to act as an authentication front end. It works like this:

   1. User visits site A (mycompany.com) and wishes to login. They see
      one edit control, and a login button. They enter their network
      address into the edit, and click login/submit
   2. Site A sends either a Jabber IQ or a SOAP message to the users
      server, that specifies the auth type (web), and a return URL.
   3. Site B responds with a URL to the authentication website for that
      server. Each Jabber server has one, we'll assume it's
      *http://authenticate.jabber.org* here. The URL points to a CGI
      script that Site A will redirect to, for instance:

      *http://authenticate.jabber.org/auth?token=120583asdbf5335sdfgy5767s*
   4. At this address, the user is presented with a form which asks them
      to present credentials (probably a password, but could be anything
      - a certificate, iris scan, fingerprint data etc.) probably over a
      secure connection.
   5. The user presents their credentials and submits. The
      authentication CGI logs into the users account to verify their
      identity, and if clear redirects the user to the URL specified in
      the original authencation request. At the same time, cookies are
      set on the authenicate.jabber.org domain, so if another site
      redirects to that site in future after Step 1, the login process
      is automatic.
   6. Once returned to the original site A properly authenticated, Site
      A can set a cookie containing the username, so from now on when
      visiting that site you are automatically logged in.

_Arbitrary services_

We will use the example of a jabber aware FTP server and client for this
section.

   1. User connects to jabber-aware FTP server using jabber aware client
   2. User gives client username and credentials (password, certificate,
      whatever)
   3. User sends username to FTP server.
   4. FTP server sends message to jabber server via either an IQ or SOAP
      asking for "service" authentication
   5. Server responds with a token (random number), which the FTP server
      then sends to the client
   6. FTP client hashes credentials with random number and sends to ftp
      server, which forwards this hash to the jabberd
   7. Jabber server checks hashed credentials, and if clear sends
      message back to FTP server announcing this fact, or otherwise
      information about what went wrong.
   8. User is now authenticated.

_Arbitrary services when client is not Jabber aware_

Often,  a service may be Jabber aware, but the client is not. In this
case, the client will prompt the user for a username and password for
its own authentication system, but the user may wish to use Jabber
authentication as supported by the server. In this case, Instant
Messaging (IM) Authentication can be used.

   1. User connects to jabber-aware FTP server with legacy client
   2. Client prompts user for username and password
   3. Client supplies Jabber network address and blank password
   4. FTP server sends SOAP/IQ to server requesting "im" authentication.
      Server sends a message with embedded form to an active IM
      connection if one, otherwise authentication fails.
   5. Users chat client receives message, for instance "Service
      'SourceForge FTP' at 129.0.44.33 is requesting authentication.
      Confirm? YES NO" would be displayed in the chat client.
   6. User clicks yes which triggers reply to server, which takes this
      message and replies to FTP service with a clear authentication.
   7. FTP server has now authenticated the connection.

This method utilises the fact that the user is probably running the chat
client on the same machine as they are authenticating from.

thanks -mike
_______________________
Michael Hearn
mhearn at neuk.net
Jabber (jabber.org) tweedledee at jabber.org
ICQ# 34800568