Scott,
Thank you for your reply as I appreciate some direction to make our CAS
additions in-line with CAS' direction! As for the use of Spring
HandlerInterceptor and SWF Actions, that is a satisfactory solution as I
have refactored our Domino SSO module to be its own separate Action.
However, I have a couple of questions though:
1. In the AuthenticationViaFormAction class' initAction() method,
it checks whether a form object has been previously set, and if not, it
will default to using the UsernamePasswordCredentials. Seeing how I
want a custom action to be performed after AuthenticationViaFormAction's
submit() method but have access to the user's credentials, what is the
best method to define the form used by both actions? It would be nice
to only configure it once rather than per bean definition or having to
do so in the initAction() method for each action that wanted to use it.
2. Is it possible to map interceptors from multiple handlers to the
same URL? I see how the logout controller has an interceptor applied to
it and didn't know if it would conflict if declared a third mapping
handler to perform my custom code on /logout.
Thanks once again for your help!
Andy
Andrew R Feller, Analyst
University Information Systems
200 Fred Frey Building
Louisiana State University <http://www.lsu.edu/>
Baton Rouge, LA, 70803
(225) 578-3737 (Office)
(225) 578-6400 (Fax)
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Scott Battaglia
Sent: Thursday, May 15, 2008 9:10 PM
To: Yale CAS mailing list
Subject: Re: How to integrate a login & logout event listener in CAS
Server ?
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]
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]
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]>
<mailto:[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]> <mailto:[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
