On Sat, Nov 03, 2001 at 08:56:00PM -0600, Mike Hicks wrote: > If a connecting web browser doesn't have a cookie, or the cookie's out of > date, the connection gets forwarded to https://www.umn.edu/login -- a > secure web page -- where the user is asked to login. If they get > authenticated, a cookie is sent to the browser and the browser is > redirected back to where it was originally connecting. > > Again, the web server checks for a cookie. Now that it's there, the > cookie is sent off by the web server to a TCP port (either plaintext or > SSL) on x500.umn.edu. If the cookie is valid, the user can be considered > to be authenticated. The data returned also contains the username, and > the IP address of the user's system, which the web server should verify. > > The two joyful things for me were that I didn't have to ask anyone to use > that service, and that it was extremely easy to implement. I was using a > PHP web page, and it took me less than two hours to get it going. PHP > doesn't seem to make SSL socket connections very easy, but for the time > being, sending the cookie to be verified in plaintext works like a charm. A cookie? Now that's something easy to spoof... > I suspect this is pretty similar to how Kerberos works, but you guys will > have to enlighten me on that one. The whole point here is that it's > possible to get authentication working with untrusted systems by > forwarding the actual authentication to somewhere else and using things > like cookies or tickets. florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20011104/5fbbe001/attachment.pgp