What I find interesting about this - and why it *MIGHT* be worth reading
through all this - is that by adding a call to "request.getParameter(x)" in my
RestletFrameworkServlet subclass I can make all this nastiness happen.
CAS 3.4.7
The last 4 lines of the stack (before that is some sun.reflect... stuff) are:
java.lang.IllegalArgumentException: resourceOperatedUpon cannot be null
at
com.github.inspektr.audit.AuditActionContext.assertNotNull(AuditActionContext.java:81)
at
com.github.inspektr.audit.AuditActionContext.<init>(AuditActionContext.java:64)
at
com.github.inspektr.audit.AuditTrailManagementAspect.executeAuditCode(AuditTrailManagementAspect.java:148)
at
com.github.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:139)
AuditTrailManagementAspect, line 126 appears to be the point of exception.
Debugging reveals:
It seems to hit the line:
retVal = joinPoint.proceed();
twice.
The first time through:
joinPoint.toString = execution(String
org.jasig.cas.CentralAuthenticationService.createTicketGrantingTicket(Credentials))
jointPoint.arguments = Object[1] : UsernamePasswordCredentials (username and
password both null)
The second time through (throws the exception):
joinPoint.toString = execution(Authentication
org.jasig.cas.authentication.AuthenticationManager.authenticate(Credentials))
jointPoint.arguments = Object[1] : UsernamePasswordCredentials (username and
password both null)
In the catch block, these variables resolve:
currentPrincipal -> [username: null]
auditResource -> String[1] with: supplied credentials: [username: null]
action -> AUTHENTICATION_FAILED
Putting a conditional breakpoint at 136 (for auditResource[0] == null) reveals:
joinPoint.toString() = execution(String
org.jasig.cas.CentralAuthenticationService.createTicketGrantingTicket(Credentials))
jointPoint.arguments = Object[1] : UsernamePasswordCredentials (username and
password both null)
action = TICKET_GRANTING_TICKET_NOT_CREATED
Continuing to trace into each method as far as possible gets me to AopUtils:
314, where an InvocationTargetException is caught from out of
DelegatingMethodAccessorImpl, the source of which I cannot see.
Stepping over from that point puts me in the catch block of
AuditTrailManagementAspect.handleAuditTrail (line 134), where we see the
target exception was thrown up as an NPE.
From: Eric Turley [mailto:[email protected]]
Sent: Wednesday, June 08, 2011 2:10 PM
To: [email protected]
Subject: RE: RE: [cas-user] Causing CAS to make a REST call at each auth attempt
I'm (at this point) not going to use the Inspektr library for this.
But I would like to ask for a piece of advice, if you don't mind.
I've subclassed RestletFrameworkServlet and overridden
doService(HttpServletRequest request, HttpServletResponse response) in order to
store off two request parameters in a ThreadLocal that I will need later.
The problem I'm running into is that every time I try to access the request
parameters, I get a stack trace later:
Jun 8, 2011 2:08:24 PM com.noelios.restlet.StatusFilter getStatus
SEVERE: Unhandled exception or error intercepted
java.lang.IllegalArgumentException: resourceOperatedUpon cannot be null
at
com.github.inspektr.audit.AuditActionContext.assertNotNull(AuditActionContext.java:81)
I suspect it has something to do with that call messing with the inputStream in
the request, making it unusable later.
If so, how can I get the request parameter info?
(If not, what the heck am I doing wrong? :) )
From: Scott Battaglia [mailto:[email protected]]
Sent: Tuesday, June 07, 2011 2:30 PM
To: [email protected]
Subject: Re: RE: [cas-user] Causing CAS to make a REST call at each auth attempt
You could tie into into the Inspektr events.
On Jun 7, 2011 12:25 PM, "Eric Turley"
<[email protected]<mailto:[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]<mailto:[email protected]>]
> Sent: Tuesday, June 07, 2011 1:47 PM
> To: [email protected]<mailto:[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]<mailto:[email protected]> as:
> [email protected]<mailto:[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]<mailto:[email protected]> as:
> [email protected]<mailto:[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
--
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
