This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Thu, 07 Sep 2000 12:03:08 -0400
From: Aaron Johnson <solution@gina.net>
To: modperl@apache.org
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
===
Date: Thu, 07 Sep 2000 12:07:21 -0400
From: Drew Taylor <dtaylor@vialogix.com>
To: Aaron Johnson <solution@gina.net>
Subject: 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.
===
Date: Thu, 7 Sep 2000 12:30:50 -0400
To: Aaron Johnson <solution@gina.net>
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [OT?] Cross domain cookie/ticket access
Cc: modperl@apache.org
>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.
===
From: joe@sunstarsys.com
To: modperl@apache.org
Subject: Re: [OT?] Cross domain cookie/ticket access
Date: 07 Sep 2000 22:21:01 -0400
>
> 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 ;>
===
Date: Fri, 8 Sep 2000 10:24:28 -0400
From: darren chamberlain <darren@boston.com>
To: Joe Pearson <joe@webdms.com>
Cc: modperl@apache.org
Subject: Re: [OT?] Cross domain cookie/ticket access
Joe Pearson (joe@webdms.com) 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*
===
From: Jerrad Pierce <Jerrad.Pierce@networkengines.com>
To: "'darren chamberlain'" <darren@boston.com>, Joe Pearson <joe@webdms.com>
Cc: modperl@apache.org
Subject: RE: [OT?] Cross domain cookie/ticket access
Date: Fri, 8 Sep 2000 10:28:22 -0400
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:darren@boston.com]
>Sent: Friday, September 08, 2000 10:24 AM
>To: Joe Pearson
>Cc: modperl@apache.org
>Subject: Re: [OT?] Cross domain cookie/ticket access
>
>
>Joe Pearson (joe@webdms.com) 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.
>
===
Date: Fri, 08 Sep 2000 10:32:23 -0400
To: "Joe Pearson" <joe@webdms.com>, <modperl@apache.org>
From: Simon Rosenthal <srosenthal@northernlight.com>
Subject: 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 ?
===
From: "Ian Mahuron" <imahuron@bro-net.com>
To: "Aaron Johnson" <solution@gina.net>, <modperl@apache.org>
Subject: RE: [OT?] Cross domain cookie/ticket access
Date: Fri, 8 Sep 2000 08:28:51 -0700
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.
===
Date: Fri, 08 Sep 2000 14:23:10 -0400
From: Aaron Johnson <solution@gina.net>
To: modperl@apache.org
Subject: 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 <solution@gina.net>
> >To: modperl@apache.org <modperl@apache.org>
> >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 (srosenthal@northernlight.com)
> 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"
===
Date: Fri, 8 Sep 2000 16:54:13 -0400
To: Aaron Johnson <solution@gina.net>
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [OT?] Cross domain cookie/ticket access
Cc: modperl@apache.org
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.
===
Date: Fri, 8 Sep 2000 13:34:55 -0400
To: joe@sunstarsys.com
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [OT?] Cross domain cookie/ticket access
Cc: modperl@apache.org
At 10:21 PM -0400 9/7/00, joe@sunstarsys.com 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 (joe@webdms.com) 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.
===
From: joe@sunstarsys.com
To: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [OT?] Cross domain cookie/ticket access
Cc: modperl@apache.org
Date: 08 Sep 2000 21:53:50 -0400
Kee Hinckley <nazgul@somewhere.com> writes:
> At 10:21 PM -0400 9/7/00, joe@sunstarsys.com 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!
===
From: "Peiper,Richard" <rpeiper@cfn.com>
To: "'joe@sunstarsys.com'" <joe@sunstarsys.com>,
Cc: modperl@apache.org
Subject: RE: [OT?] Cross domain cookie/ticket access
Date: Mon, 11 Sep 2000 07:24:50 -0400
> and I didn't see any directly relevant listings. They
> apparently hold a patent
> related to embedding session data in the path-info;
>
You HAVE to be kidding me? I have been embedding session data in
URL's for 7 years... and they patented that?! *sigh* I guess it just seemed
to logical for me to ever dream of patenting it.
===
From: joe@sunstarsys.com
To: "\"Peiper,Richard\" <rpeiper@cfn.com> \"Kee Hinckley\"" <nazgul@somewhere.com>
Subject: Re: [OT?] Cross domain cookie/ticket access
Cc: modperl@apache.org
Date: 11 Sep 2000 12:58:54 -0400
"Peiper,Richard" <rpeiper@cfn.com> writes:
> > and I didn't see any directly relevant listings. They
> > apparently hold a patent
> > related to embedding session data in the path-info;
> >
>
> You HAVE to be kidding me? I have been embedding session data in
> URL's for 7 years... and they patented that?! *sigh* I guess it just seemed
> to logical for me to ever dream of patenting it.
>
> Richard
>
from http://www.patents.ibm.com/details?pn=US05708780__
*****
This invention relates to methods for controlling and
monitoring access to network servers. In particular, the
process described in the invention includes client-server
sessions over the Internet involving hypertext files. In the
hypertext environment, a client views a document transmitted
by a content server with a standard program known as the
browser. Each hypertext document or page contains links to
other hypertext pages which the user may select to
traverse. When the user selects a link that is directed to
an access-controlled file, the server subjects the request
to a secondary server which determines whether the client
has an authorization or valid account. Upon such
verification, the user is provided with a session
identification which allows the user to access to the
requested file as well as any other files within the present
protection domain.
*****
It looks like they were awarded a patent in 1998 for using session data in the
URL for authentication, as Kee pointed out. Pretty damn original, no?
I think we're really OT with this thread; probably it should be on /. or
private mailings going forward.
===