The current Inspektr package is perfectly capable of intercepting both ticket creation and ticket destruction events (as well as service ticket validation and creation). Its also designed to collect data from the entire flow from web tier to service layer (something the original event handler structure could not do).
Take a look at the auditable annotations on the CentralAuthenticationServiceImpl: http://developer.ja-sig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/CentralAuthenticationServiceImpl.java?r=43396 There is one defined for "TICKET_GRANTING_TICKET_DESTROYED" and one also defined for TICKET_GRANTING_TICKET_CREATED. They should both give you the resource (ticket id), the user they were created for, and some additional information. If you merely need to do certain things at the web tier level, you should be using Spring's Handler Interceptors which are designed to be used with the Handler Mappings and should thus not require modification to core classes. Regardless of whether you ask Ben or myself, Rutgers is committed to supporting the Inspektr package as the means of notifying the system of actions that occur within CAS. The goal is to create an extensible auditing and statistics package that can be used in any Java application. We currently use it in both CAS and our online Web Registration system with great success, and are looking at additional applications. It will continue to evolve separately as a product, with CAS gaining any of the new features introduced in the package. It has the benefit of being developed outside of the scope of CAS, thus getting additional developers looking at it, while the CAS use cases will always remain one of factors driving its evolution. Our recommendation for extending the web tier is and has always been to utilize the methods provided with Spring Web Flow and the Spring MVC layer which can either include additional actions or the Handler Interceptor Adaptors. -Scott On Thu, May 15, 2008 at 9:17 PM, Adam Rybicki <[EMAIL PROTECTED]> wrote: > Andrew, > > I think that you and I both have stumbled into requirements that the > EventHandler interface in 3.1 was capable of solving. I managed to find > that interface, and even though its original intent was to facilitate > auditing, I was able to use it to monitor TGT creation and destruction and > act on those events (TicketEvent). My EventHandler implementation had > nothing to do with auditing. > > Your requirements, if I understand them correctly, could have a solution by > implementing a 3.1 EventHandler that would process the HttpRequestEvent. > > Which makes me think that the event model, which allows CAS "extensions" > without modifying CAS code itself, is useful. Perhaps I made a mistake of > using an interface intended for auditing for a different purpose entirely. > Still, I had a real-life need to be notified of TicketEvents, and you have a > need to be notified of HttpRequestEvents. Perhaps the EventHandler > interface and the entire event pattern is useful enough to preserve in CAS. > This pattern neatly hides the AOP details, which is a good thing for > AOP-handicapped people like me. ;-) > > This whole ApplicationEvent pattern on which the CAS 3.1 events were built > seemed like a useful thing in CAS. I found a use case for it, and perhaps > others would. What do you think? It would be good to know Scott's opinion, > but Scott is out this week. I wonder if Ben Oshrin has an opinion on this > matter. > > I have a feeling that it should be possible to "resurrect" the > org.jasig.cas.event package. > > Thanks, > Adam > > Andrew R Feller wrote: > > Adam, > > I spent a day or so reviewing the possible pointcuts to apply advice to, > however depending on what you want, you may or not be able to use AOP to tie > into the creation and destruction of ticket granting tickets. With Spring > AOP, it cannot apply advice to classes and methods that are marked as final > as it cannot override them. > > In my case, I need to have access to the HttpServletRequest and > HttpServletResponse along with users' credentials, so the pointcuts I need > are the LogoutController's handleRequestInternal() method and the > AuthenticationViaFormAction's submit() method. > > If you do need access to either HttpServletRequest or HttpServletResponse, > then you can write some advice that goes against the > CentralAuthenticationServices interface's createTicketGrantingTicket() and > destroyTicketGrantingTicket() methods as this is not a problem for AOP. > > Scott: What would you recommend in my situation to tie into creation and > destruction of TGTs but with access to HttpServletRequest / > HttpServletResponse? I currently have a custom Spring Webflow Action that I > have configured to be called if a success event occurs from the > AuthenticationViaFormAction state. However, in order to hook into logout, I > had to design a custom logout controller. > > Thanks, > > Andrew R Feller, Analyst > University Information Systems > 200 Fred Frey Building > Louisiana State University > Baton Rouge, LA, 70803 > (225) 578-3737 (Office) > (225) 578-6400 (Fax) > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] On > Behalf Of Andrew R Feller > Sent: Monday, May 12, 2008 10:22 AM > To: Yale CAS mailing list > Subject: RE: How to integrate a login & logout event listener in CAS Server ? > > Adam, > > I encountered the same issue whenever I deployed CAS 3.0.7 / 3.1.0 as I > needed CAS to create and destroy an additional cookie upon login / logout. > At the time, the only solution available was to create a custom Spring > WebFlow state for the login process and extend the logout controller to > expire my cookie upon logout. > > I am perfectly aware that this isn't elegant or desirable as I am dealing > with upgrading to CAS 3.2.1, so I would love to hear a solution, too! I am > available for private conversation about this if you want to talk more. > > Thanks, > Andy > > Andrew R Feller, Analyst > University Information Systems > 200 Fred Frey Building > Louisiana State University > Baton Rouge, LA, 70803 > (225) 578-3737 (Office) > (225) 578-6400 (Fax) > > ________________________________________ > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] On > Behalf Of Adam Rybicki > Sent: Wednesday, May 07, 2008 9:01 PM > To: Yale CAS mailing list > Subject: Re: How to integrate a login & logout event listener in CAS Server ? > > Scott, > > I am back from the conferences and resolving this issue has come to the top > of my priority list. I spent some time looking at 3.2.1, and I have not been > able to figure out how to weave my custom code into this new package. Let me > elaborate... > > My custom code needs to perform some work when a TGT is created or destroyed. > I looked at the sample auditTrailContext.xml. This sample has no comments > that would hint at "hooking in" custom auditing code. I am not schooled in > AOP, and while I understand the concepts, some additional hints would help. > I just do not see how to configure the system to notify my code of TGT > creation and destruction. > > CAS manual on the JA-SIG Wiki has nothing on the subject. Can you please > point me in the right direction? > > Thanks, > Adam > > Scott Battaglia wrote: > We switched to the Inspektr package for a few reasons: > > 1. It provides end-to-end auditing, it can track user, ip address, and action > all in one transaction > 2. its an open-source library developed by two coworkers and myself that can > be incorporated into other projects, allowing for knowledge re-use. > Eventually the tool will include a web application to view the results. > 3. supports statistics gathering > 4. code is completely externalized from the CAS code so enabling/disabling it > adds/removes the code rather than the events being fired anyway and then > ignored > 5. its generic so we can add new things to audit without creating new events > 6. The code in the source tree was actually sample/example code on how to do > auditing using events, and not designed for production use (though it was > capable of being used that way). We stated this when it was put in place in > 3.0, but I'm sure by now everyone's forgotten about that :-) > > -Scott > On Tue, Apr 22, 2008 at 4:18 PM, Adam Rybicki <[EMAIL PROTECTED]> <[EMAIL > PROTECTED]> wrote: > Scott, > > Was there anything wrong with EventHandler or TicketEvent? I ask because I > have used them, and now upgrading to 3.2.1 will be more difficult. :-( > > Adam > > Scott Battaglia wrote: > Cyrille, > > Since CAS is now using the Inspektr package (detailed here: > http://code.google.com/p/inspektr/) that's our preferred way of doing things. > You'll merely need to write an AuditTrailManager that does the JMS call. > > -Scott > On Tue, Apr 22, 2008 at 6:14 AM, Cyrille Le Clerc <[EMAIL PROTECTED]> <[EMAIL > PROTECTED]> wrote: > Hello, > > I would like to capture login and logout events in CAS Server to broadcast > these events to a JMS Topic (backend data preloading, etc). > > The package org.jasig.cas.event (AuthenticationEvent, TicketEvent and > EventHandler interface) has been removed in CAS 3.2, the SVN comment says > "started move to Google Code Inspektr library". > > What is the preferred way to integrate a login/logout/ticket event > listener in CAS ? > > Thanks in advance, > > Cyrille > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
