[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
accept)
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
result)
When do we begin to discuss implementation *smile*
Norbert