[cas-dev] feedback about JA-SIG java CAS client 3.0 RC2

[Velpi]

Today we did some more examining of the new Ja-SIG CAS client filter. We 
did not find any issues that are of any concern. (note: we have a 
special deployment which also use the delegation filter from the util 
package: maybe this one can even be pushed into Spring??)

It's running smoothly for more than a week now and we did not see any 
problems yet. Aside from the remarks I made before, we are very pleased 
with the new setup. I expected a small rise in cpu load, but if there 
was one, it is that small that we can't notice the difference (even in 
our more complex setup).
Using the proxy feature in combination with a setup as servlet filters 
is now really simple. There's no need anymore to start dragging around 
PGTIOU's.

I have a light suggestion to implement the InitializingBean as a next 
improvement so we can use setters and getters. One of our customizations 
implements the InializingBean and it works together with the rest 
without a hitch. Implementing the InializingBean interface is more clear 
to do configuration. On the other hand it is important that the classes 
can also be used outside of the Spring context.

I'd like to stress that modifying the new client to suit your particular 
needs has become a LOT more easy. However documentation is necessary for 
people wanting to do more modifications, so let's start making that soon 
now. A default deployment can be done easily with the supplied examples.
We did not have the chance yet to investigate adapting one of our 
systems that use the new filter as a library in their code. I'm assuming 
this would not a problem.


In my opinion it is ready for a general release so it starts spreading 
and documentation can be updated. The current release is both new and 
sticks to some behaviour we have grown acquainted to. I suggest creating 
some basic documentation for it and then making the release official.


(also see below)

>     We have deployed a customized version of the RC2 where validation of the
>     ticket is done before the authentication filter. I investigated this
>     thoroughly and I did not find this to create any security issues. My
>     suggestion is to change the sequence of both filters to easily add even
>     more flexibility in the future. But maybe there's a good reason why
>     this
>     has not been done before?
> 
>     Current implementation
>     ######################
>     ||
>     -----
>     Authentication:
>     if (no principal in session) and (no ticket) redirect
>     -----
>     ||
>     -----
>     if (ticket) try to validate it, send error when validation fails
>     -----
>     ||
> 
>     My suggestion
>     #############
>     ||
>     -----
>     if (ticket) try to validate it, OPTIONAL error when validation fails
>     -----
>     ||
>     -----
>     Authentication:
>     if (no principal in session) and (no principal on request) redirect
>     -----
>     ||
> 
>     That would cause the following changes in behaviour:
>     * The authentication filter is completely separated from the ticket
>     part. It always checks for a valid principal in either the session or
>     the request, even when there's a ticket in the request: this feels more
>     secure (definitely safer when you start customizing).
>     * The validation filter does not *need* to throw a fatal exception when
>     ticket validation fails since the authentication filter won't let
>     anyone
>     pass that's not authenticated.
> 
>     If it would not throw a fatal error and the user is authenticated then
>     this probably means an old ticket was in the request. The latter problem
>     is being fixed now by an "extra redirect". That works, but it adds yet
>     another redirect for the client.
>     If it would not throw a fatal error and the user is not authenticated,
>     this could, in rare cases, cause a loop from the authentication filter.
>     But looping can be prevented easily by using a session variable.
>     So throwing a fatal exception can be made optional behaviour.
>     * Information about the user is known right after validation is done.
>     This means the authentication filter could already do something useful
>     with this (eg: force re-authentication when it's a staff member that
>     wants to do a certain action). Although you'll probably just add a new
>     filter for that.
> 
> 
> You would enter some form of bad loop if you kept trying to validate 
> failed tickets and then redirecting to the authentication piece (and not 
> checking for a ticket).  At some point a validation failure needs to 
> throw an exception.  The purpose of the validation filter is to fail if 
> a validation fails.  Nobody else would know to fail other than the 
> validation filter.  Using a "flag" on the authentication filter doesn't 
> tell you that validation failed.  All it tells you is that hey I already 
> tried to authenticate this person.  Thoughts?

We are currently running in a setup where the standard validation filter 
is configured before the standard authenticationfilter. It is possible 
to do that now without any modifications. It does not create any 
(security) issues.
I think it might be a good idea to be able to make the error silent as a 
configuration option, but it's not a requirement. Error handling in 
general is still one of the points where improvement can be done for a 
next version.


I say "make it official"!


--Velpi