dotgnu-auth
[Top][All Lists]
Advanced

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

[Auth]proposed modifications of davidnicol AIS (working implementation o


From: david nicol
Subject: [Auth]proposed modifications of davidnicol AIS (working implementation of proposed Perl auth interface)
Date: Wed, 10 Jul 2002 00:15:41 -0500

Hello all; I've gotten the home office set up pretty much and I'm
trying to get things accomplished once again.



In order to present it at YAPC/America 2002 last week I finally
got my AIS project in a working state.  

http://pay2send.com/ais/ais.html describes it.

The "profile host" is identified, in AIS, with a string called
an "aissri" which is a stub to the various URIs involved in the
handshake.

My current perl module provides an "Authenticate" method that
performs the handshake and saves a session object with the
data returned by the AIS.  Currently, no-identity is represented
by a reserved identity NULL and errors are represented by a
reserved identity ERROR.

I am thinking that it would be better to change it in these ways:

1:  don't return at all for null identity.  Guarantee the AIS client
program that if flow of control returns from the Authenticate routine,
there is an identity and it is valid.

2: throw exceptions (perl uses "die" for this) instead of special-casing
identities for errors, and NULL identities from AIS servers that provide
null identities instead of insisting on credentials.


Another thought is to support both behaviors with a switch of some kind,
or possibly two primitives, one primitive to request that the AIS server
create a one-time-use key that will map to the user's identity, or null
if
there is not one defined (what is currently the "present" action) and
another one that is the same except that when there is no identity
defined
the AIS server will keep the user until they define and authenticate an
identity, and only then will the AIS server redirect the user back to
the AIS client.

The two behaviors can be called "strong authentication" where we don't
return unless we've got an identity and "weak authentication" where if
we
don't know who the user is we return an identity of NULL.  Which the
client
then has to trap, and send the user to a per-AIS login page of some
kind,
so why even bother with the weak version.  Am I right?


David Nicol

-- 
"You look like you could have slept with Iggy Stooge" -- Cher U.K.


reply via email to

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