Mark W. Eichin wrote:
failed access) and give a kerberos login, and get back a cookie; the cookie can then be used for access to other pages. (Yes, this
You might want to take a look at what umn.edu does with their x.500 login system. THere is at least a description at http://www.umn.edu/cookieauth/
Essentially:User gets redirected from any required-login page by the 'cookieauth' module to the 'login' page at www.umn.edu/login with some options to have the login page redirect back to the original page on success.
Login page assigns cookie of random bits on auth success and redirects to original page.
Original page has the 'cookieauth' module loaded and makes a ssl (I think) connection to x500.tc.umn.edu and sends the other side the cookie string and x500.tc sends back information like username, authed until time, and other bits. (Is this an Enterprise login or not? Enterprise logins are SecureID authenticated also, AFAIK.)
It seems like a decent system and is definately browser independant. The only true pain is in making modules for popular webservers, the login page, and the authentication server bit.
-- Scott Dier <dieman@ringworld.org> http://www.ringworld.org/ -- To UNSUBSCRIBE, email to debian-wnpp-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org