httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Evans <tevans...@googlemail.com>
Subject Re: [users@httpd] Keep session variables alive
Date Fri, 10 Oct 2008 16:10:40 GMT
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

Mime
View raw message