mod_auth_cas stores the backing data for the cookies in a path like /var/run/mod_auth_cas/.... If you have 3 separate servers that do not share disk (like foo.example.com, bar.example.com, baz.example.com) and set the cookie domain to .example.com, if the user authenticates to foo.example.com, bar.example.com and baz.example.com won't be able to look up the cookie. They'll redirect the user to the CAS server, and set their own cookie, overwriting the one that foo set. Then when the user goes back to foo, it will not be able to read the backing data for the cookie bar set, etc.
If you leave the cookies scoped to the explicit domain (by not changing any domain scope related options) then each cookie will implicitly be scoped to foo.example.com, bar.example.com, etc. and you won't have that problem. -Phil On Tue, Jun 14, 2011 at 9:59 AM, stan santiago <[email protected]> wrote: > Phil, > > > Please note that unless all these domains are served from the same > physical > > box, this will fail since they wouldn't share the same backing store > (seems > > like you are serving them from the same box). > > Sorry I don't get what you meant by "same physical box" and "backing > store" Are you referring to the > box running the CAS server or the Apache/mod_auth_cas server? Yes they > are running on the > same box in the test environment. But the final deployment would have > them in separate servers. > > Stan > > > > On Mon, Jun 13, 2011 at 4:32 PM, Phil Ames <[email protected]> wrote: > > On Mon, Jun 13, 2011 at 2:18 PM, Smith, Matthew J. <[email protected] > > > > wrote: > >> > >> Stan- > >> > >> mod_auth_cas builds the service URL from the ServerName parameter in the > >> Apache config, not from the submitted host header (see > >> https://wiki.jasig.org/display/CASC/CASFilter for an explanation of the > >> risks around using the submitted host header). > >> > >> I don't believe we've considered the use case, though, of ServerAliases. > >> For larger group rumination with regard to all CAS clients, how do > other > >> CAS clients handle multiple valid serverNames? Continuing to think > >> out-loud, perhaps we could validate the submitted host header to the > list of > >> ServerAliases and ServerName -- any thoughts from other m-a-c-devs? > >> > >> I'm wondering, though, if the CASCookieDomain parameter could > immediately > >> meet your use case. Please try setting CASCookieDomain .test.com . > This > >> will cause a m-a-c session cookie set by any subdomain to be valid for > all > >> subdomains, preventing another roundstrip to the CAS server. > > > > Please note that unless all these domains are served from the same > physical > > box, this will fail since they wouldn't share the same backing store > (seems > > like you are serving them from the same box). > > > >> > >> HTH, > >> -Matt > >> > >> Matthew J. Smith > >> University of Connecticut UITS > >> [email protected] > >> ________________________________________ > >> From: stan santiago [[email protected]] > >> Sent: Monday, June 13, 2011 11:33 AM > >> To: [email protected] > >> Subject: Re: [cas-user] CAS not working correctly with subdomains > >> > >> I agree. The bug is on the mod_auth_cas apache module not the the CAS > >> server. > >> > >> Use case similar to our setup : > >> ------------------------------------------ > >> > >> Let's say different departments in a company have their own custom > >> portal as follows: > >> > >> - marketing.company.com > >> - engr.company.com > >> - finance.company.com > >> - intranet.company.com > >> ... > >> > >> And the SSO implementation allows login using the corporate ldap portal. > >> > >> Is there a problem or using both subdomains and domains with CAS? Am I > >> missing something > >> related to best practices around domain/subdomains and CAS? > >> > >> Stan > >> > >> > >> On Mon, Jun 13, 2011 at 11:17 AM, Scott Battaglia > >> <[email protected]> wrote: > >> > There's no bug with the CAS server with respect for subdomains. All > CAS > >> > clients are required to read their host names from configuration and > not > >> > from Host headers, as using host headers introduces a security risk > >> > since > >> > its controlled by users. > >> > I know that info doesn't actually help you :-) Can you describe your > >> > use > >> > case a bit more on why you're using a CAS client to work with both a > >> > domain > >> > and subdomain? I admit its probably a use case we haven't encountered > >> > before. > >> > Cheers, > >> > Scott > >> > > >> > > >> > > >> > On Mon, Jun 13, 2011 at 11:11 AM, stan santiago <[email protected]> > >> > wrote: > >> >> > >> >> Greetings Folks, > >> >> > >> >> I'm unable to get CAS working with subdomains. I see there is a bug > >> >> filed for this issue: > >> >> https://issues.jasig.org/browse/CAS-980 > >> >> > >> >> Anyone else run into this and find any workarounds for this issue? > >> >> > >> >> My environment: > >> >> ----------------------- > >> >> - OS: CenOS 5.5 64 bit > >> >> - Apache Module: Mod_auth_cas 1.0.9.1 setup on Apache 2 > >> >> - CAS Server 3.4.7 > >> >> > >> >> TEST URLs: > >> >> ------------------ > >> >> 1. Accessing http://test.com redirects to > >> >> > >> >> > >> >> > https://my.casserver.com:8443/cas-server-webapp-3.4.7/login?service=http://platformsystems.com/ > >> >> 2. Accessing http://host1.test.com redirects to exactly the same URL > >> >> above. The "host1" subdomain is stripped off during redirection to > CAS > >> >> server. > >> >> > >> >> Apache httpd.conf > >> >> -------------------------- > >> >> > >> >> # Use name-based virtual hosting. > >> >> NameVirtualHost *:80 > >> >> > >> >> <VirtualHost *:80> > >> >> > >> >> DocumentRoot /var/www/html > >> >> ServerName test.com > >> >> ServerAlias *.test.com > >> >> > >> >> LoadModule auth_cas_module modules/mod_auth_cas.so > >> >> > >> >> # Cookie path must be given as an absolute path with a trailing > >> >> slash > >> >> CASCookiePath /var/run/mod_auth_cas/ > >> >> > >> >> # Certificate path may be a file or a directory of certificates > >> >> symlinked by > >> >> # their hashed names > >> >> CASCertificatePath /etc/ssl/certs > >> >> CASValidateServer Off > >> >> CASDebug On > >> >> > >> >> # The URL to the CAS server > >> >> CASLoginURL > >> >> https://my.casserver.com:8443/cas-server-webapp-3.4.7/login > >> >> CASValidateURL > >> >> > https://my.casserver.com:8443/cas-server-webapp-3.4.7/serviceValidate > >> >> CASProxyValidateURL > >> >> https://my.casserver.com:8443/cas-server-webapp-3.4.7/proxyValidate > >> >> > >> >> </VirtualHost> > >> >> > >> >> ... > >> >> > >> >> <Directory "/var/www/html"> > >> >> > >> >> Options Indexes FollowSymLinks > >> >> > >> >> AuthType CAS > >> >> AuthName "MY CAS" > >> >> require valid-user > >> >> > >> >> Order allow,deny > >> >> Allow from all > >> >> > >> >> </Directory> > >> >> > >> >> ... > >> >> > >> >> Thanks, > >> >> Stan > >> >> > >> >> -- > >> >> You are currently subscribed to [email protected] as: > >> >> [email protected] > >> >> To unsubscribe, change settings or access archives, see > >> >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > > >> > -- > >> > You are currently subscribed to [email protected] as: > >> > [email protected] > >> > To unsubscribe, change settings or access archives, see > >> > http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> -- > >> You are currently subscribed to [email protected] as: > >> [email protected] > >> To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> > >> -- > >> You are currently subscribed to [email protected] as: > >> [email protected] > >> To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > > > > -- > > You are currently subscribed to [email protected] as: > > [email protected] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
