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

[Velpi]

Hi

we have joined the brave and taken the latest RC2 of the JA-SIG java 
client into production after careful evaluation. Here's some *initial* 
feedback:

* It seems to run like a charm (more details about that while time passes).
* The delegation filter adds much flexibility and works perfect! (But 
shouldn't it be in the filters package in stead of the util package?)
* Feedback from a colleague that had not seen the client yet but had to 
install it says logging is good. That's definitely a strong point!
* one small remark about logging identifiers though: for the server the 
subclasses start at "org.jasig.cas". For the client the subclasses start 
at "org.jasig.cas.client". It would be nice if the CAS server 3.1 
started its subclasses at "org.jasig.cas.server". It makes it more clean 
to configure logging (and there must be other good reasons).
* Configuration of the client looks more complex at first, but it's not 
once you start thinking in Spring. Documentation and examples will be 
important (as usual). The extra properties file is both good and bad: 
some people will miss it at first, but you can put some settings on a 
central location. On the other hand you can put those settings on a 
central spot in the XML too by using ref's (I think).
* Configuration is A LOT more flexible and leaves plenty of room for 
customizations. I'd say this will give the new client a long life-cycle: 
something we all value a lot.
* Getting a proxy ticket when using it as a Servlet filter is now done 
by writing merely a few lines of code! [and the right configuration of 
course]
* It might be a good idea to create a CAS-commons package that provides 
classes that are being used in both the server and the client (not so 
easy to pick which need to be where though).


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.



I would summarize this as: The release of this new filter is a step 
ahead and creates the necessary room for future improvements, while it 
keeps using the same ideas that we can already trust.


Good job!


-- Velpi