dotgnu-general
[Top][All Lists]
Advanced

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

Re: [DotGNU]Identity


From: David Nicol
Subject: Re: [DotGNU]Identity
Date: Thu, 28 Feb 2002 15:16:24 -0600

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


reply via email to

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