Correct, and actually, that is the point. I want the user to be anonymous in the application even if they have already authenticated to CAS, until they perform some action to login. This action would be clicking a link that brings them to the CAS server. This would allow the user to anonymously view the content they have just published into the CMS, without requiring a full CAS logout or a different browser -- just clear the m-a-c cookie.
This would also allow tiering of Apache modules (through various wacky ProxyPass and Rewrite statements) such as m-a-c and _auth_kerb for authentication of both interactive browser sessions and non-interactive (cURL, DAV, etc) sessions through the same URL. -Matt Matthew J. Smith Manager of Server Support University of Connecticut UITS matt.sm...@uconn.edu ________________________________________ From: Joachim Fritschi [frits...@hrz.tu-darmstadt.de] Sent: Wednesday, July 14, 2010 2:32 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] Prevent CAS Redirect for Bots Matthew, As Nathan already pointed out your implementation has one flaw. How do you get your initial ticket= if you have no existing session for the current service but you already have some TGT. Your 4) simply omits that fact that there is now way to get this information before you perform a full login(or gateway) procedure with a redirect. The Facebook iframe sounds like a nice idea and might indeed be solution for this problem. Another idea could be a javascript that accesses the cas server and determines if there is session for the current user and simply skips the gateway calls if the skript is unsuccessful. Or you could have your cas server set cross domain cookie that contains if the user has a valid session. The cookie would have no security value but would simply prevent unnecessary gateway calls. Regards, Joachim Am 13.07.2010 22:55, schrieb Nathan Kopp: > We use this approach on a number of sites. In one of the Java clients, there > was a CasValidateFilter that does this. (I'm not sure if it still exists in > the latest Java client.) > > The biggest problem is that it won't automatically recognize a logged-in user > unless they take some sort of action. This approach acts similarly to > Facebook Connect and OpenID. I've heard that Facebook can do OpenID in an > invisible IFRAME, effectively doing a "gateway" but without issuing a > redirect on the outer page (the redirect is happening within the IFRAME). > This approach might work for enabling gateway-style single sign-on while > using a validation-only (passthru mode) CAS client. > > -Nathan > > > -----Original Message----- > From: Matthew J. Smith [mailto:matt.sm...@uconn.edu] > Sent: Tuesday, July 13, 2010 4:48 PM > To: cas-dev@lists.jasig.org > Subject: RE: [cas-dev] Prevent CAS Redirect for Bots > > I've tossed around (only in discussions with myself) the idea of > prototyping a CAS "Passthru" mode to mod_auth_cas. This is similar to > Gateway mode, but without the redirect to determine if a user is already > authenticated. The flow would be something like this: > > 1) User accesses resource protected by mod_auth_cas. > > 2) m-a-c, configured in "Passthru" mode checks for a "ticket=" parameter > or a session cookie. Finding none, the user is allowed through > anonymously. > > 3) Internal to the application a "Login" link is available, bringing the > user to https://login.example.com/cas/login > > 4) Upon successful authentication (or acceptance of previously issued > TGC), user is directed back to application with "ticket=" parameter > (normal CAS flow), > > 5) m-a-c, configured in Passthru mode, finds a "ticket=" parameter, > performs "serviceValidate", sets REMOTE_USER for authenticated access, > and sets a session cookie. > > 6) Subsequent access(es), m-a-c configured in Passthru mode finds the > cookie and sets REMOTE_USER for authenticated access. > > In this mode, anonymous access is allowed without redirects, and > authenticated access with one extra action from the user. > > Anyone else think this would be useful? Is there a big security hole I > haven't yet identified? > > -Matt > > On Tue, 2010-07-13 at 16:30 -0400, Nathan Kopp wrote: >> I think the use case is that bots should always look like guests. >> Recall that gateway mode is being used. >> >> >> >> We actually will have this same requirement. Consider a public >> website that uses gateway mode to provide customized content for users >> who are logged in, but will show generic content for all guest users. >> You want Google to spider the site and see the public (generic) >> content. But it stops the instant it sees the gateway redirect. >> >> >> >> -Nathan >> >> >> >> >> From: J. David Beutel [mailto:jbeu...@hawaii.edu] >> Sent: Tuesday, July 13, 2010 4:00 PM >> To: cas-dev@lists.jasig.org >> Subject: Re: [cas-dev] Prevent CAS Redirect for Bots >> >> >> >> >> It sounds like you want to allow access for bots without >> authentication, while still requiring humans to authenticate for the >> same URL. That can't be secure. A human could impersonate a bot. >> >> On the other hand, if you want to authenticate just the 20% of the >> site that you don't need the bots to access, you could use the >> url-pattern on the CAS filter in web.xml (with the Java client, at >> least). >> >> >> On 2010-07-13 05:44 , prasanna h wrote: >> >> Hi Joachim, >> >> >> >> >> I can use a robots.txt to allow or deny bots accessing portions of the >> site. But about 80% of the site has data that needs to be accessed by >> bots so as to not affect the search rank. Since I have enabled a CAS >> gateway, every request is intercepted and redirected to cas. I need to >> modify this so that requests from bots are not redirected to CAS. >> >> >> >> >> >> Not sure if robots.txt is the way to go for what I'm trying to >> accomplish. >> >> >> >> >> >> Prasanna. >> >> >> >> >> On Tue, Jul 13, 2010 at 9:01 PM, Joachim Fritschi >> <frits...@hrz.tu-darmstadt.de> wrote: >> >> Hi, >> >> i guess a classic robots.txt should solve the issue for search >> engines. >> >> Cheers, >> >> Joachim >> >> Am 13.07.2010 11:18, schrieb prasanna h: >> >> Hi All, >> >> We use CAS as a gateway where each request is intercepted and >> redirected >> to CAS to check for a ticket. I noticed that the redirect to CAS >> happens >> for users as well as bots. Has anyone using CAS encountered this and >> if >> yes, can you let me know the solution? >> >> Right now, I'm planning to check the user-agent against a list of >> common >> bots to determine whether to redirect to CAS. >> >> Looking forward to your thoughts as well. >> >> Prasanna >> >> >> -- >> You are currently subscribed tocas-...@lists.jasig.org >> <mailto:cas-dev@lists.jasig.org> as: frits...@hrz.tu-darmstadt.de >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> >> >> -- >> Joachim Fritschi >> Hochschulrechenzentrum (HRZ) >> L1|01 Raum 248 >> Petersenstr. 30 >> 64287 Darmstadt >> >> Tel. +49 6151 16-5638 >> Fax. +49 6151 16-3050 >> E-Mail: frits...@hrz.tu-darmstadt.de >> >> >> >> >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> jbeu...@hawaii.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> >> >> -- >> >> You are currently subscribed to cas-dev@lists.jasig.org as: >> nathan.k...@ccci.org >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> matt.sm...@uconn.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- Joachim Fritschi Hochschulrechenzentrum (HRZ) L1|01 Raum 248 Petersenstr. 30 64287 Darmstadt Tel. +49 6151 16-5638 Fax. +49 6151 16-3050 E-Mail: frits...@hrz.tu-darmstadt.de -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
