Re: [OT?] Cross domain cookie/ticket access
I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. Now I'm curious, I'll need to try that. -- Joe Pearson Database Management Services, Inc. 208-384-1311 ext. 11 http://www.webdms.com -Original Message- From: Aaron Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, September 07, 2000 10:08 AM Subject: [OT?] Cross domain cookie/ticket access I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? I have thought about several different alternatives, but they just get uglier and uglier. One thought was that they could go to a central server and login. At the time of login they would be redirected to a special page on each of the other two servers with any required login information. These pages would in turn return them to the login machine. At the end of the login process they would be redirected to the web site they original wanted. This is a rough summary of what might happen - domain1.net - user requests a page in a protected directory. They don't have a cookie. They are redirected to the cookie server. This server asks for the user name and pass and authenticates the user. Once authenticated the cookie server redirects the client to each of the other (the ones not matching the originally requested domain) domains. This redirect is a page that hands the client a cookie and sets up the session information. domain2.net gets the request and redirects the user to a page that will return them to the cookie machine which will add the domain2.net to the list of domains in the cookie. And then the process will repeat for each domain that needs to be processed. Am I crazy? Did I miss something in the documentation for the current Session/Auth/Cookie modules? I did some hacking of the Ticket(Access|Tool|Master) Example in the Eagle book, but the cookie limit is keeping it from working correctly. ( BTW: I already use it for a single server login and it works great. ) Any information would be appreciated. Aaron Johnson
Re: [OT?] Cross domain cookie/ticket access
Joe Pearson ([EMAIL PROTECTED]) said something to this effect: I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. You sure can -- otherwise Navigator wouldn't have the "Only accept cookies originating from the same server as the page being viewed" option. Set-Cookie: foo=my%20foot%20hurts; domain=.apache.org; path=/; expires=*mumble* (darren) -- Any technology indistinguishable from magic is insufficiently advanced.
RE: [OT?] Cross domain cookie/ticket access
Cookies cannot be shared across domains (except the supercookie, due to a bug in IE and Netscape? See http://cookiecentral.com for more info) Cookies are bound to either a domain (domain.com) or a FQDN host.domain.com Netscape sees everything as a FQDN if you select originating server only. This means host1.domain.com cannot see host2.domain.com's cookies. And in all cases (except super promiscuous cookie) host1.domain.com cannot see host1.domain2.com's cookies... -Original Message- From: darren chamberlain [mailto:[EMAIL PROTECTED]] Sent: Friday, September 08, 2000 10:24 AM To: Joe Pearson Cc: [EMAIL PROTECTED] Subject: Re: [OT?] Cross domain cookie/ticket access Joe Pearson ([EMAIL PROTECTED]) said something to this effect: I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. You sure can -- otherwise Navigator wouldn't have the "Only accept cookies originating from the same server as the page being viewed" option. Set-Cookie: foo=my%20foot%20hurts; domain=.apache.org; path=/; expires=*mumble* (darren) -- Any technology indistinguishable from magic is insufficiently advanced.
Re: [OT?] Cross domain cookie/ticket access
At 11:37 PM 9/7/00 -0600, Joe Pearson wrote: I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. I don't think you can set a cookie for a completely different domain, based on my reading of RFC2109 and some empirical tests ... it would be a massive privacy/security hole, yes ? - Simon Now I'm curious, I'll need to try that. -- Joe Pearson Database Management Services, Inc. 208-384-1311 ext. 11 http://www.webdms.com -Original Message- From: Aaron Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, September 07, 2000 10:08 AM Subject: [OT?] Cross domain cookie/ticket access I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? I have thought about several different alternatives, but they just get uglier and uglier. One thought was that they could go to a central server and login. At the time of login they would be redirected to a special page on each of the other two servers with any required login information. These pages would in turn return them to the login machine. At the end of the login process they would be redirected to the web site they original wanted. This is a rough summary of what might happen - domain1.net - user requests a page in a protected directory. They don't have a cookie. They are redirected to the cookie server. This server asks for the user name and pass and authenticates the user. Once authenticated the cookie server redirects the client to each of the other (the ones not matching the originally requested domain) domains. This redirect is a page that hands the client a cookie and sets up the session information. domain2.net gets the request and redirects the user to a page that will return them to the cookie machine which will add the domain2.net to the list of domains in the cookie. And then the process will repeat for each domain that needs to be processed. Am I crazy? Did I miss something in the documentation for the current Session/Auth/Cookie modules? I did some hacking of the Ticket(Access|Tool|Master) Example in the Eagle book, but the cookie limit is keeping it from working correctly. ( BTW: I already use it for a single server login and it works great. ) Any information would be appreciated. Aaron Johnson - Simon Rosenthal ([EMAIL PROTECTED]) Web Systems Architect Northern Light Technology 222 Third Street, Cambridge MA 02142 Phone: (617)621-5296 : URL: http://www.northernlight.com "Northern Light - Just what you've been searching for"
RE: [OT?] Cross domain cookie/ticket access
Why not do this... Implement sessions via DBI. All three servers will use the same table in the same database for setting/getting session data (ie 'authenticated_uid' = 1425). Pass the session id around in the path or in query string. Make sure your applications include this data when linking to the other servers. It's too early.. so I doubt this method is without flaws. Session hijacking comes to mind. Bad juju.
Re: [OT?] Cross domain cookie/ticket access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 10:21 PM -0400 9/7/00, [EMAIL PROTECTED] wrote: I don't think there's any pretty way to do it. The only thing I can think of off-hand is to generate the cross-server links dynamically, including an encrypted token in the URL which will notify that server If you ever implement something like this, just be sure you patent it before Amazon does ; Actually, I have a strong suspicion that this may be covered by the OpenMarket patents. I know their authentication software worked cross-domain, and I know their ordering software worked with encrypted URL tokens. At 10:24 AM -0400 9/8/00, darren chamberlain wrote: Joe Pearson ([EMAIL PROTECTED]) said something to this effect: I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. You sure can -- otherwise Navigator wouldn't have the "Only accept cookies originating from the same server as the page being viewed" option. Nope, that's for cookies being set by images that are from a different server than the one you are on. But yes, you could use that, with a fair bit of trickery. Primary domain sets cookie in database, page includes image references to secondary domains with encrypted token. Fetching those images causes a lookup in the database which then sets the appropriate cookie. Of course, if someone has set the above-mentioned netscape option, it won't work, and it won't work if the user doesn't hang around for those two (probably somewhat delayed) images. - -- Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects (Now playing: http://www.somewhere.com/playlist.cgi) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBObkjaCZsPfdw+r2CEQIwmgCfVt0lfvamfD3TqpXs3mLcglmwr+EAoIAL /CTdiqk1T4Ik/gHwqwQg6CMu =bVrB -END PGP SIGNATURE-
Re: [OT?] Cross domain cookie/ticket access
Well even if I thought it might be possible with a single cookie the user agents are by by RFC2109 supposed to not allow it so even if I got something to work there is no guarantee that it will work in the future, since it will most likely be a security hole of the user agent. See RFC2109 section 8.3 - Unexpected Cookie Sharing Thanks, Simon, for the RFC number it really helped. So based on some other responses here is my new idea - Each machine has a login screen that is custom to its "app". It shares the login information via LDAP or SQL for user information across the different domains. The user will only see the login app if they do not have a valid session or cookie for that app/domain The user gives user name and pass and are authenticated. The user, once authenticated is updated in the "session" table as being online and are given a unique number and various information about them is stored under that key (user name, pass, time of access, IP*, etc.). When the user on domain1.net is given a link to domain2.net we could do one of two things: a) the link actually goes to a local page that then pulls the unique code for that user and appends it to the URL for the domain2.net site and they are sent with the unique code via post. domain2.net then looks up the info for unique code in the shared session database. Along with the code as the key the session database also would hold the user name and "clearance" of the user (possibly other fields like IP) and the server would also check the HTTP_REFERER to see if it is in the "valid" list. - or - b) The link to domain2.net or domain3.net is pre appended with the unique code when the navigation is generated and we rely only on the HTTP_REFERER. (a) is a little more paranoid and doesn't require processing on every page to add the code to the off domain URLS, but requires more "work" to get the person to the correct URL. (b) Is certainly quick and dirty, but has more potential to expose the unique code. Is it hard to spoof a HTTP_REFERER? Is it as easy as sending a modified header? domain2.net once it has received the URL will create it owns session/cookie information for the user based on the information in the session database and subsequent requests to that domain would automatically be passed to the correct URL with out creating session information again. ( I am basing that off existing work with Apache::ASP and app entry points ) Any major flaws with this plan or suggested improvements? Aaron Johnson Simon Rosenthal wrote: At 11:37 PM 9/7/00 -0600, Joe Pearson wrote: I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. I don't think you can set a cookie for a completely different domain, based on my reading of RFC2109 and some empirical tests ... it would be a massive privacy/security hole, yes ? - Simon Now I'm curious, I'll need to try that. -- Joe Pearson Database Management Services, Inc. 208-384-1311 ext. 11 http://www.webdms.com -Original Message- From: Aaron Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, September 07, 2000 10:08 AM Subject: [OT?] Cross domain cookie/ticket access I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? I have thought about several different alternatives, but they just get uglier and uglier. One thought was that they could go to a central server and login. At the time of login they would be redirected to a special page on each of the other two servers with any required login information. These pages would in turn return them to the login machine. At the end of the login process they would be redirected to the web site they original wanted. This is a rough summary of what might happen - domain1.net - user requests a page in a protected directory. They don't have a cookie. They are redirected to the cookie server. This server asks for the user name and pass and authenticates the user. Once authenticated the cookie server redirects the client to each of the other (the ones not matching the originally requested domain) domains. This redirect is a page that hands the client a cookie and sets up the session information. domain2.net gets the request and redirects the user to a page that will return them to the cookie machine which will add the domain2.net to the list of domains in the cookie. And then the process will repeat for each domain that needs to be processed. Am I crazy? Did I miss something in the documentation for the current Session/Auth/Cookie modules?
Re: [OT?] Cross domain cookie/ticket access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 2:23 PM -0400 9/8/00, Aaron Johnson wrote: a) the link actually goes to a local page that then pulls the unique code for that user and appends it to the URL for the domain2.net site and they are sent with the unique code via post. domain2.net then looks up the info for unique code in the shared session database. Along with the code as the key the session database also would hold the user name and "clearance" of the user (possibly other fields like IP) and the server would also check the HTTP_REFERER to see if it is in the "valid" list. Note that that is neither secure nor reliable. HTTP_REFERER can be trivially forged, and reloads cause it not to appear at all. That's why I recommend an encrypted version of the login information in the URL. You can encrypt a timestamp with it, or allow a given encryption key to be used only once, so as to ensure that the URL can't be reused by a third party. Remember too that anything you pass in the URL will end up in your log files--do you trust everyone who can get access to those? Are they kept secure? Is it hard to spoof a HTTP_REFERER? Trivial. Is it as easy as sending a modified header? Yes. - -- Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects (Now playing: http://www.somewhere.com/playlist.cgi) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOblXOiZsPfdw+r2CEQJ1qACfeRX8RNhAFIGWPzYNS4P96Je5oEsAn1ds 0XDzJ4RJdpHZhueoyjXvQzvZ =OHRN -END PGP SIGNATURE-
Re: [OT?] Cross domain cookie/ticket access
Kee Hinckley [EMAIL PROTECTED] writes:
At 10:21 PM -0400 9/7/00, [EMAIL PROTECTED] wrote:
I don't think there's any pretty way to do it. The only thing I can
think of off-hand is to generate the cross-server links dynamically,
including an encrypted token in the URL which will notify that server
If you ever implement something like this, just be sure you
patent it before Amazon does ;
Actually, I have a strong suspicion that this may be covered by the
OpenMarket patents. I know their authentication software worked
cross-domain, and I know their ordering software worked with
encrypted URL tokens.
That's what I was afraid of.
However, I searched the Open Market patents at http://patents.ibm.com;
and I didn't see any directly relevant listings. They apparently hold a patent
related to embedding session data in the path-info; your particular
problem appears cookie-related.
My recommendation for using cookies is to do what banner advertisers do.
I would embed a dummy link (image, stylesheet, javascript) in the ticket
authentication's confirmation page ("Congratulations, you've successfully
logged in... redirecting to ...").
Say you use blank images. Put one in for each domain, and put the
authentication token in the url or query args. When the browser
fetches the dummy link FROM EACH DOMAIN, presumably the code you
run for that url will return a set-cookie header
for that domain. It's like doing the 'round-robin' thing all at once.
The end user shouldn't notice any difference.
Also, I'm pretty sure the netscape setting for 'accepting cookies from other
domains' only applies to this kind of usage. Domain x should NEVER be able
to set a cookie in domain y. Period. Advertisers deliver banners from domains
other that the one you requested in the browser's url. Disabling this feature
within netscape prevents those images from setting cookies
(in thier OWN domain,of course). This would conceivably break thi
implementation above, in which case you can use dummy frames instead!
Best of luck.
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
Re: [OT?] Cross domain cookie/ticket access
Aaron Johnson wrote: I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? Yes. In the end I decided users would just have to login into each domain seperately as I'm using cookies for authentication/tracking. You just can't do it. :-( Of course, if someone has another idea I'm listening... The only other way around it is at time of login to do what you described - round-robin redirect to each domain. It's ugly, time consuming (for the user), and it generally sucks. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: [OT?] Cross domain cookie/ticket access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Johnson wrote: I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? I don't think there's any pretty way to do it. The only thing I can think of off-hand is to generate the cross-server links dynamically, including an encrypted token in the URL which will notify that server that it should set a cookie saying that the user has already logged in. The good news is that you only need to do that once for each domain that it is visited. The bad news is that it doesn't work if the user comes to that domain via some mechanism that doesn't include the token--then they'll have to login the first time to regain their session identifier. - -- Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects [Coming this week solar-powered from the Florida beaches] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBObfCzCZsPfdw+r2CEQKypgCfc6iDirFQMl3YL10UUJPx7fa+/u4An1a5 tF4LFML6QP7cb3VeI/iqD+MI =vjy/ -END PGP SIGNATURE-
Re: [OT?] Cross domain cookie/ticket access
I don't think there's any pretty way to do it. The only thing I can think of off-hand is to generate the cross-server links dynamically, including an encrypted token in the URL which will notify that server that it should set a cookie saying that the user has already logged in. The good news is that you only need to do that once for each domain that it is visited. The bad news is that it doesn't work if the user comes to that domain via some mechanism that doesn't include the token--then they'll have to login the first time to regain their session identifier. -- If you ever implement something like this, just be sure you patent it before Amazon does ; -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
