[dgAIS] Re: [DotGNU]Identity

[David Nicol]

to do identity with a little graphic instead of something else,
steps three and eight would be set up to give a no-session code
instead of redirecting; or possibly the AIS server would issue
some authentication request headers to pop those up for the user
instead of providing a HTML form; in fact that's a much cleaner
way to ask for the credentials.




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 AIS 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, beginning of course with the session cookie



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 handled 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