[JDEV] Single Sign on and stuff
Michael Hearn
mhearn at mailandnews.com
Wed Oct 3 16:10:55 CDT 2001
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
More information about the JDev
mailing list