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?
> > >
> > >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"
