Matt, Thank you for your response which clears that up. However, after further reading the help file on mod_auth_cas more questions arise.
Hmm... 1. If in our app, there are multiple .htaccess files within the branches of a website. that have the same AuthType, AuthName, AuthUserFile and AuthGroupFile but a different "require" apache directive values for both users and groups to restrict which users or groups has access to specific subdirectories in our website which is part of Apache Core would that retrigger m-a-c to reauthenticate? Or if a user is authenticated when a particular 'require valid-user' , 'require user foo' or 'require group foo' be locally checked and the m-a-c module will some how remember who was authenticated and not have to do another round trip to the CAS Server. 2. Another important question to me is, if currently our existing web app is using .htaccess files to control access to certain subdirectories by using .htaccess files and the Require user xxx and Require group xxx xxx Apache Core directives from the README file https://www.ja-sig.org/svn/cas-clients/mod_auth_cas/trunk/README It suggests that the Apache directives Will those existing directives (AuthName, AuthUserFile, AuthGroupFile, require) still be recognized and enforced by Apache either through Apache Core directives 'require valid-user', 'require group foo' work, so I'm assuming require user peter would be enforced. However, would the directives AuthName, AuthUserFile, AuthGroupFile have any meaning with the m-a-c where 'AuthType CAS' is set? For example, if I had a require valid-user, in some .htaccess file that was protected by m-a-c, would the m-a-c module first lookup to see if that user is in the file referenced by AuthUserFile and if in there then make a call to the CAS Server to verify that that user is valid? I think the answer is yes (probably could check the code). If there was a 'valid user thungp' entry I would think the behavior of the m-a-c module would still make a call to the CAS server to validate that thungp had already logged in, assuming he didn't. If you happen to know off hand please confirm. How are groups handled though? With AuthType basic, from my understanding, users are checked to see if they are in the correct group which is looked up at the location of AuthGroupFile XXX. Since I don't believe CAS has the concept of groups, I am thinking that the m-a-c module would rely on the group file reference by AuthGroupFile to see if that user was in the particular group referenced by the 'require group foo' for example and then possibly do a CAS server check to log him in if not already authenticated. Please confirm. Is the AuthName also still compatible or enforced with the m-a-c? 3. If we are a Windows 2003 Server box running Apache, can this module work with it? Are their any recipes to help me compile this module for that platform using free software? Maybe Cygwin? If not maybe we need to consider the AuthCAS module which depends on mod_perl which does not need a compiled library. MOD_CAS (m-c) also appears to be similar is style to (m-a-c) in terms of needing to be compiled. Thanks again for you help. -Peter From: Smith, Matthew J. Sent: Tue 2/24/2009 5:11 AM To: [email protected] Subject: Re:[cas-user] Questioning Regarding mod_cas and mod_auth_cas -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Does anyone know if any of these mod_cas issues were addressed in the > mod_auth_cas implementation? All of these concerns still hold. > > Anyone have any idea if it is even possible to address this issues given > the CAS architecture and hence why there was a cautionary note on MOD_CAS? This is the great question. Given the redirect required for CAS authentication, content where the browser is not expecting a redirect (CSS, images, scripts, etc), protecting this data with m-a-c is difficult. But, if you can ensure that authentication happens first, then access to this data will not need further redirection for authentication. This is a fairly common setup anyway -- you protect a directory containing your app and all content, and the first call to the directory triggers the authentication. Only upon the return from the CAS server are the CSS, JS, images, etc loaded, without need for further redirection. The real problem comes from deep-linking or deep-bookmarking. If CSS/JS/images/frame-content are protected by m-a-c, and called into before authentication occurs (linked from a non-protected page, or bookmarked directly), funky things can happen. HTH, - -Matt Thung, Peter C CIV SPAWAR SSC PAC, 56340 wrote: > In regards to the following: > mod_auth_cas > http://www.ja-sig.org/wiki/display/CASC/mod_auth_cas > > mod_cas > http://www.ja-sig.org/wiki/display/CASC/MOD_CAS > > After reading the description of the two I came across this in regards > to teh mod_cas client. > When not to use MOD_CAS > (Per Scott Lundgren's email). > > mod_cas not should not be used with pages that use frames > directories of images files should be moved out from under mod_cas > protection because browsers (IE 6 & Firefox 1.06) do not know how to > handle the redirects for the requests for images embedded in an HTML page > directories of CSS files should be moved out from under mod_cas > protection for the same reasons > mod_cas cannot be used with server generated images where scripts return > an image stream > > In our particular website, it does use frames and does have embedded > images in HTML pages. > Apparently it does not have any issues using regular Basic > Authentication using the built in mod_auth directive. > > Does anyone know if any of these mod_cas issues were addressed in the > mod_auth_cas implementation? > > Anyone have any idea if it is even possible to address this issues given > the CAS architecture and hence why there was a cautionary note on MOD_CAS? > > Thanks. > > -Peter > > > ****************************************************************** > > Peter Thung > > SPAWAR Systems Center PACIFIC (Code 56340) > > Netcentric ISR Development > > Software Developer > > Primary: (619) 553-6513 > > Secondary:(619) 553-0777 > > ****************************************************************** > > > > - -- Matthew J. Smith University of Connecticut ITS [email protected] PGP KeyID: 0xE9C5244E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJo/IMGP63pOnFJE4RArbOAJ4uBkmZEnX1aXZ2HetFeCxuCqhyAQCgrvWR ar5l6eiGcaulE0jB32rjRtU= =ZCC4 -----END PGP SIGNATURE----- -- 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
