Re: [Auth]Okay, so how about some code...

[Mason Ham]

Okay ... Here is a quick take. We all know passport. The idea is that you
have one centralized server that everyone asks for authentication from. This
hash be hashed to death so I am going to assume that everyone understand the
pros and cons of that. What the system here does is decouple what is
Passport (using win thunks etc to do it's stuff) from  windows. We call it
browser routing, and basically through the use of server and client side
redirects, the end http 3.2 compliant "browser" becomes the router. The only
reason that one needs to have 3.2 is for when it is used in a browser (IE,
Opera, etc) and you want the user to be "seamlessly" authenticated with out
an interstitial (sp?) page asking for permission of the specific data that
is being transmitted from the auth site to the site that wanted the auth.
That make sense to people? Here lets try this:
user-> bob.
site-> foo
auth site -> bar
lcrs->Least Common Rule Set
1) Bob goes to foo and asks for a protected page.
2) foo checks if bob is already auth'd with it. Bob isn't so it make an
auth. packet and "transmits" it to the client. At this point the client
could view the encrypted data going from foo to bar. Not much use in that
though....
3) bar gets the request, checks if bob is already auth'd with it. Bob isn't
so it sends a login screen to bob. bob fills it out and sends to bar.
4) bar process and does what need to be done with LCRS. In this case bob has
stated that he wants to approve data going to this site. So bar send him a
form for approval. He says yes.
5) bar encrypts the information with foo's public key. and "transmits" the
data to bob to be redirected.
6) This is where the 3.2 dependence comes in. In order to make it happen one
must use the onload even from the scripting subsystem. the other option is
to have form post to a button for bob to click to send it.
Hope that is clearer.

As for:
> I'm afraid I still don't understand all of the basics of all this...
> maybe you could start with explaining the most basic question:  What
> benefits to the end user does this system provide, as opposed to the
> good old "username and password over SSL"?
>
The system supports:
1) Level 2 authentication. This is where there are unique questions that
must be answered for a proper auth.
2) Bio-metrics. The system can be tied to a thumb, retinal, what ever
bio-metric read you want.
3) The system can use smart cards.
4) the system can use combinatory values.
5) Each of these have LCRS applied to them. So user, site and the auth site
itself have the ability to set minimums.

Hope that helps.

Mason
----- Original Message -----
From: "Norbert Bollow" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>
Sent: Thursday, October 04, 2001 10:59 AM
Subject: Re: [Auth]Okay, so how about some code...


> > > What do you think, how much work would it be to get rid of these
> > > requirements?
>
> > Further, remember that this is only for
> > systems that would want to run as an Auth. server, not for the clients
that
> > wanted to use the auth. server, they simply use the ssl package that is
on
> > there system.
>
> Aah!  This answers the concern I had... I agree that it's not
> unreasonable to expect something like Crytix JCE to be installed on
> auth servers.  (In fact when we distribute DotGNU on CDROM, we could,
> for convenience of installation, include Crytix JCE ... so it's not a
> big deal at that end.)
>
> I'm afraid I still don't understand all of the basics of all this...
> maybe you could start with explaining the most basic question:  What
> benefits to the end user does this system provide, as opposed to the
> good old "username and password over SSL"?
>
> Greetings, Norbert.
>
> --
> A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
> Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
> Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
> Your own domain with all your Mailman lists: $15/month  http://cisto.com
>