[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]The simplest thing that can possibly work

From: Norbert Sendetzky
Subject: Re: [Auth]The simplest thing that can possibly work
Date: Tue, 17 Jul 2001 15:18:53 +0200

On Monday 16 July 2001 13:05, you wrote:
> Can you suggest a viable path for making a simple solution that
> does not require cooperation of webserver administrators, and
> that doesn't involve making a plugin for IE?

There are a lot of good aspects from other people.
I will summarize what I think is a good idea:

At the first time:
1) A user connect to a web site, with requires authenication (mostly username 
and password)
2) The user insert a RLS (Resource locator string, eg. https address) to the 
server which holds his auth data (or even more). Through most browser have a 
feature (sometimes more a pain) to auto fill forms, this have to be done once.
3) The server redirects the user to the given auth server and appends the 
name of the information it needs (eg. "name", "password")
4) The auth server asks the user (authenticates with username and password) 
if it is ok to transmit the data and if the server can request this 
information in the future without without asking the user again (accept, ask 
or reject)
5) If the information isn't already stored encrypted on the auth server, it 
will be from now on except the user rejected further requests from the server
6) The auth server send the information back to the original server (https 
and POST I hope)

Further times:
1) - 3) are equal to the above
4) Through the policy the user make last time (accept, ask, reject) the auth 
server sent the requested information immediately to the server (if policy is 

Based on the RLS the user can have several auth server, each with different 
information (username,password on first, pubkey, etc on second). This 
solution is distributed, reliable, fault tolerant and secure, provided all 
transmissions are encrypted and you install your own auth server. Otherwise 
you must trust your provider that he don't touch your data. In an 
implementation, we can make this difficult, but not impossible. For something 
really secure, we need a small piece of software on the client for 
decryption. Another annoyance may be that the screen will flicker twice 
through the two redirects.

This requires the implementation of an auth server (probably we can use 
jabber, Theo is rather convinced by the protocol ;-) ), no client support and 
low server support, which is already there (a scripting language to parse the 

When do we begin to discuss implementation *smile*


reply via email to

[Prev in Thread] Current Thread [Next in Thread]