[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Identity
From: |
Mario D. Santana |
Subject: |
Re: [DotGNU]Identity |
Date: |
Sun, 10 Mar 2002 12:08:50 -0500 |
David,
What you've described sounds an awful lot like a stripped-down version
of macs. See http://macs.sf.net/ for more, especially the readme at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/macs/macs/lms/README.login?rev=HEAD&content-type=text/plain
mds
> Bill Lance wrote:
> >
> > An overview:
> >
> > http://www.oreillynet.com/pub/a/webservices/2002/02/26/identity.html
>
>
> I have an apprentice working on templatizing the HTML pages
> involved in the six-stage handshake and writing identity client
> code in Java as well as Perl -- for an authenticated identity service
> as described at my web page . Anyway, here's some ASCII - UML
> describing how the handshake works:
>
>
> AIS_client AIS_server User
>
>
> 0.request web page from client
>
> 1.redirect User to Server along with
> a URL the server is supposed to redirect
> the user back to, with some text replaced
> by the server
>
> 2.request URL from server,
> along with auth cookie
>
> 3.Is user in a session? if yes,
> select unique code, rewrite URL,
> and redirect server to the rewritten
> URL with the code in it
> if no, redirect user to a login page or
> redirect them back to the client with the
> identity key blank -- depending on how you
> want to do this
>
> 4.request URL from client
>
> 5.contact server with unique code
>
> 6.reply to client with User's Identity
>
> 7. create session for User
>
> 8. (compose and) serve page to User
>
>
>
> If the User doesn't already have a session ongoing with the AIS_server,
> the server can demand credentials (issue a login page) at step 3. If
> the Server supports identity hiding of some kind, it can give some kind
> of fake code at step 6 instead of a useful (harmful?) identity hook such
> as a good e-mail address.
>
> The client never sees how the user authenticates themselves to the server,
> log-ins are handles as needed by the server, the system could be embedded
> in a web page in the form of, for instance, a link to a graphic rather
> than a whole page, but whole pages would work too.
>
>
> Some way of telling the server how to handle no-session at step 3
> is required -- either issue a login page, or give the user back to
> the client and let the client issue a login page -- the server issuing
> the login page preserves the abstraction better in my opinion.
>
>
> Advice, dissent?
>
>
>
>
> --
> David L Nicol, humble system administrator (816) 235 1187
> "... security through transparency." -- Margareta Wolf
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
>