On Fri, 2008-10-03 at 09:11 -0500, Justin Pasher wrote:
> Cassiel wrote:
> > Hi you all,
> >
> > I would like to keep session variables alive, between two PHP coded
> > website, currently two virtual hosts.
> > This is in order to let users login from the main one and then switch
> > between the twos without loosing $_SESSION info.
> >
> > Any suggestion is appreciated.
> >
> > regards
> > raffaele
>
> A session variable is simply a cookie in the user's browser that holds
> their session ID (unless you happen to be keeping tracking of the
> session ID through the URL, which is a bigger security risk). You won't
> be able to make it work across two different domain names, as this would
> be a security hole. If the two virtualhosts share the same top level
> domain (such as sub1.example.com and sub2.example.com), then it is
> possible as long as the cookie is tied to example.com as opposed to
> sub1.example.com or sub2.example.com.
>
> Otherwise, you'll have to maintain the "link" between the two sites
> yourself, such as passing some sort of hash information from one site to
> the other that tells the site the user's login information. Keep in mind
> this is not the most secure way of doing things, but you just have to
> remember that the browse will think domain1.com and domain2.com are
> completely different web site, even if they are the "same" logically.
>
All of Justin's advice is good, but you can do a very simple 'SSO'
without sharing domains. I'll describe a 3 site system, 2 service
providers, one identity provider, but this can be expanded to cover any
number of sites that have a shared backend resource, like sessions or a
database. The identity provider could even be one of the service
provider.
User visits siteA, and doesnt have a current/valid session id.
He is bounced to http://siteC/get_session_id?site=siteA .
He doesn't have a session in siteC, so one is created, and he is bounced
back to http://siteA/federation?session=$site_c_sess_id .
siteA has then received a session id that is shared between siteA and
siteC.
User then visits siteB, and again, doesn't have a current/valid session
id.
He is bounced to http://siteC/get_session_id?site=siteB .
He does have a session in siteC, so he is bounced back to
http://siteB/federation?session=$site_c_sess_id
siteB has then received a session id that is shared between siteA, siteB
and siteC.
This is very weak SSO, check out lasso[1], shibboleth[2] and the SAML
2.0 specs and docs[3] (especially the tech overview[4] is good for an
insight into how proper SSO federations are managed).
Cheers
Tom
[1] http://lasso.entrouvert.org/
[2] http://shibboleth.internet2.edu/
[3] http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
[4] http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
|