NYCPHP Meetup

[Michael B Allen]

On Mon, 26 Mar 2007 23:12:35 -0400
"Joseph Crawford" <codebowl at gmail.com> wrote:

> I am guessing this talk of a central server is a central domain like
> erenetwork.com
> which would hold all the session data in the database.  Whenever someone
> accesse say domainA.com it would redirect to erenetwork.com, get the session
> data then redirect to domainA. with the session id in the header or
> something is that correct?

Basically yes. If you don't want to (or can't) have the client carry
some state with it, then you're pretty much locked into using a central
database to store cross site session data. There's just no other way
for site B to know that the user authenticated successfully with site
A without site A and site B sharing data.

As for the redirects, that's up to you. Personally I think I would rather
have the server issue a secondary HTTP request to erenetwork.com. The
only problem with that is that you don't know who's session data to
ask for. That's why I was thinking you could use a cookie to store the
client's identity. The first time they visit each site they will have to
logon separately. That's ugly but they would only do that once until the
cookie got deleted or expired. Once their identity is set in the cookie
you have the means to ask erenetwork.com for the session state for that
user every time they visit that particular site.

Of course you can't just store a username in the cookie since a cookie
can easily be forged. You would have to encrypt something that uniquely
identified the user. When they a site you decrypt the cookie and use the
unique identifier to query erenetwork.com for the session state. If the
state is not present or indicates the user is not logged in, then you
reauthenticate them and submit the updated state to erenetwork.com. Then
when the client goes to another site, the same thing happends but this
time the session state indicates they are already logged in and thus
they do not have to log in again.

Mike

> On 3/26/07, Michael B Allen <mba2000 at ioplex.com> wrote:
> >
> > On Mon, 26 Mar 2007 22:03:07 -0400
> > "Joseph Crawford" <codebowl at gmail.com> wrote:
> >
> > > Mike,
> > >
> > > If i cam correct you cannot use cookies in this manner because
> > > domainB.comcould not read a cookie set by
> > > domainA.com
> >
> > Right but I'm not suggesting that you put a logon session key in the
> > cookie, just something to represent their identity. So the first time
> > someone visited a site they would have to login regardless. But that's
> > only the first time. Once the cookie saved their identity (which is
> > fixed in time) the server would know who who the client is and could
> > consult the "central server" to retrieve the user's session state.

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/