<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4134.600" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2>Distributed Jabber Authentication<BR>by Mike Hearn (<A href="mailto:mhearn@neuk.net">mhearn@neuk.net</A>) Jabber: <A href="mailto:tweedledee@jabber.org">tweedledee@jabber.org</A></FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>------------------------------------------------------------------------<BR>This document will assume knowledge of what network authentication is,<BR>and how Microsoft Passport operates.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>Jabber network authentication as outlined in this prelimary document<BR>will allow for the following things:</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>    * Authentication to arbitrary third party websites, without prior<BR>      knowledge of that site.<BR>    * Authentication to arbitrary services and servers, ie FTP servers,<BR>      where both server and client are jabber aware<BR>    * Authentication to services and servers for which the client is not<BR>      jabber aware.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>_Website authentication_</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>This involves using a special authentication website to allow web<BR>browsers to act as an authentication front end. It works like this:</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>   1. User visits site A (mycompany.com) and wishes to login. They see<BR>      one edit control, and a login button. They enter their network<BR>      address into the edit, and click login/submit<BR>   2. Site A sends either a Jabber IQ or a SOAP message to the users<BR>      server, that specifies the auth type (web), and a return URL.<BR>   3. Site B responds with a URL to the authentication website for that<BR>      server. Each Jabber server has one, we'll assume it's<BR>      *http://authenticate.jabber.org* here. The URL points to a CGI<BR>      script that Site A will redirect to, for instance:</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>      *http://authenticate.jabber.org/auth?token=120583asdbf5335sdfgy5767s*<BR>   4. At this address, the user is presented with a form which asks them<BR>      to present credentials (probably a password, but could be anything<BR>      - a certificate, iris scan, fingerprint data etc.) probably over a<BR>      secure connection.<BR>   5. The user presents their credentials and submits. The<BR>      authentication CGI logs into the users account to verify their<BR>      identity, and if clear redirects the user to the URL specified in<BR>      the original authencation request. At the same time, cookies are<BR>      set on the authenicate.jabber.org domain, so if another site<BR>      redirects to that site in future after Step 1, the login process<BR>      is automatic.<BR>   6. Once returned to the original site A properly authenticated, Site<BR>      A can set a cookie containing the username, so from now on when<BR>      visiting that site you are automatically logged in.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>_Arbitrary services_</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>We will use the example of a jabber aware FTP server and client for this<BR>section.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>   1. User connects to jabber-aware FTP server using jabber aware client<BR>   2. User gives client username and credentials (password, certificate,<BR>      whatever)<BR>   3. User sends username to FTP server.<BR>   4. FTP server sends message to jabber server via either an IQ or SOAP<BR>      asking for "service" authentication<BR>   5. Server responds with a token (random number), which the FTP server<BR>      then sends to the client<BR>   6. FTP client hashes credentials with random number and sends to ftp<BR>      server, which forwards this hash to the jabberd<BR>   7. Jabber server checks hashed credentials, and if clear sends<BR>      message back to FTP server announcing this fact, or otherwise<BR>      information about what went wrong.<BR>   8. User is now authenticated.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>_Arbitrary services when client is not Jabber aware_</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>Often,  a service may be Jabber aware, but the client is not. In this<BR>case, the client will prompt the user for a username and password for<BR>its own authentication system, but the user may wish to use Jabber<BR>authentication as supported by the server. In this case, Instant<BR>Messaging (IM) Authentication can be used.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>   1. User connects to jabber-aware FTP server with legacy client<BR>   2. Client prompts user for username and password<BR>   3. Client supplies Jabber network address and blank password<BR>   4. FTP server sends SOAP/IQ to server requesting "im" authentication.<BR>      Server sends a message with embedded form to an active IM<BR>      connection if one, otherwise authentication fails.<BR>   5. Users chat client receives message, for instance "Service<BR>      'SourceForge FTP' at 129.0.44.33 is requesting authentication.<BR>      Confirm? YES NO" would be displayed in the chat client.<BR>   6. User clicks yes which triggers reply to server, which takes this<BR>      message and replies to FTP service with a clear authentication. <BR>   7. FTP server has now authenticated the connection.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>This method utilises the fact that the user is probably running the chat<BR>client on the same machine as they are authenticating from.<BR></FONT></DIV> <DIV><FONT face=Arial size=2>_______________________<BR>Michael Hearn<BR><A href="mailto:mhearn@neuk.net">mhearn@neuk.net</A><BR>Jabber (jabber.org) <A href="mailto:tweedledee@jabber.org">tweedledee@jabber.org</A><BR>ICQ# 34800568</FONT></DIV></BODY></HTML>