You could tie into into the Inspektr events. On Jun 7, 2011 12:25 PM, "Eric Turley" <[email protected]> wrote: > @Andrew: > Yeah, we're using the war overlay as well, and currently, I'm specifying a different authenticationHandler, and within that, overriding postAuthenticate and doing what I gotta do. But I'm not sure that's the best place to plug in. > > > @Marvin: > No, we USED to use our "platform" as the front-end for auth. Clients would call it, and it would delegate to CAS. Now, we're moving to proper use of CAS, allowing clients direct access to it. > But the *REASON* we used to have the platform front for it is because we wanted to create records of auth attempts. So you see, now I want CAS to make a call to the platform at every auth attempt, and the platform can create that record. > And, afaik, I'm just interested in each TGT-granting. I just care when a user presents credentials and either succeeds or fails. I don't care how many times the user accesses a service. > > -----Original Message----- > From: Marvin Addison [mailto:[email protected]] > Sent: Tuesday, June 07, 2011 1:47 PM > To: [email protected] > Subject: Re: [cas-user] Causing CAS to make a REST call at each auth attempt > >> We'd like to make our CAS server make an http call to our "platform" server >> whenever an auth attempt is made (pass or fail). > > IIRC this REST service is your authentication provider, so you simply > want to call that service for every service access. Is that correct? > Assuming so, there is no way to do this. In an SSO environment, the > authentication handler fires on login exclusively. I imagine you > don't want to burden the user with reauthentication to achieve this, > so you'll have to customize CAS to support this use case. > > The fundamental problem you'll have to solve is a way to cache > credentials to pass off to the authentication handler on every service > request. Normally the credentials are provided by the Webflow, but in > your case you'll have to cache them and replay them to the auth > handler. > > Off the top of my head this sounds both difficult and ill-advised > solely because of the need to cache credentials. Lots of problems can > emerge from cached credential situations. > > M > > -- > 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
