[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]MACS/AIS integration
From: |
david nicol |
Subject: |
[Auth]MACS/AIS integration |
Date: |
04 Sep 2003 00:08:43 -0500 |
I saw from the "pink" logs that at least two people
got AIS to work for them.
The terms used within AIS are (from memory)
AIS server: the host where the AIS service lives,
analogous to an "authentication domain" in other literature
AIS client: a webservice that wishes to use an identity
established with an AIS server
Service Client: some mozilla-class software capable of following
http "Location:" directives. Referred to as "the user" for
purposes of brevity.
Things that happen, in the order that they happen, when a user
of an AIS-subscribed webservice begins their session:
* the webservice checks to see if they have a session cookie
established with ths user. If they do, we're good -- we have
a session. (go to HAVE_A_SESSION)
Otherwise,
* the webservice redirects the user to an URL at the AIS, which
includes GET-style CGI data about where to redirect the suthenticated
user back to.
* The AIS authenticates the user somehow, ideally by looking up
a long-term cookie in a big database. Throwing up the HTTP headers to
demand credentials would be very cool, but cannot be done from within
the CGI environment. Any apache module hackers reading this? Although
a well-subscribed AIS would get enough traffic to justify writing a
server program that does nothing but AIS serving.
* The AIS redirects the authenticated user back to the URL provided
two bullet-points ago, with a single-use authentication ticket (aka
a capability key) appended to the url
* the AIS client makes (or reuses, if practical) a connection to
the AIS server and presents the single-use authentication ticket
* the AIS server looks up the single-use authentication ticket and
provides the authenticated identity.
* the AIS client establishes a session cookie (if they haven't done
that already) and associates the identity with the session
Label: HAVE_A_SESSION
:)
That is as simple as it can be made, but no simpler, to have
an identity service in a web service, that does not expose the
AIS client to user credentials, and that does not try to create
a "secure" channel through the user.
For those who are worried about packet sniffing, standard SSL/TLS
can be used.
I have working prototype AIS server that uses e-mailed verification
codes and persistent cookies for authentication method, and
working prototype AIS client module that uses Perl's BEGIN-block
feature to transparently redirect and stop when the session has not
yet been created.
I believe the versions of the AIS tools I uploaded to CPAN are
behind the versions actually in use in the "pink" demonstration.
A longer version of the preceding description is on a web page
in http://pay2send.com/ais/AIS.html
--
David Nicol / If at first you don't succeed, use a bigger hammer.
http://gallaghersmash.com
- [Auth]MACS/AIS integration,
david nicol <=