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

Tue Nov 7 12:59:56 EST 2006

I see in the announcements that you recommend acegi users to upgrade but
acegi is bound to the old package structure.  Did you intend that users
should write their own acegi authentication provider and ticket
validator?

________________________________

From: cas-dev-bounces at tp.its.yale.edu
[mailto:cas-dev-bounces at tp.its.yale.edu] On Behalf Of Scott Battaglia
Sent: Monday, November 06, 2006 10:50 AM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] feedback about JA-SIG java CAS client 3.0 RC2

Thanks for the feedback.  I've pasted some comments inline.

On 11/4/06, Velpi <velpi at industria.be> wrote: 

<snip />

* It seems to run like a charm (more details about that while time
passes). 

That is good to know :-) 

	* The delegation filter adds much flexibility and works perfect!
(But 
	shouldn't it be in the filters package in stead of the util
package?)

The only reason its in the util package instead of the web.filters
package is because its not a general purpose CAS filter (i.e . one
dealing with either authentication or validation).

<snip />

* 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).

At this stage we can't change the package names unfortunately.  "CAS" is
the server though so its not entirely inaccurate to have the packages
the way it is.  It shouldn't be a problem as the CAS server and client
are generally not deployed together. 

	* 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).

The default Spring configuration is but one option.  If anyone can come
up with an easier way and wants to help us implement it, feel free to.
The configuration isn't more complex necessarily just completely
different than previous versions :-), Hopefully our examples make it
clear what to do. 

	<snip />
	* 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've debated internally doing this but there doesn't seem to be enough
"common" stuff (other than the domain) to warrant this at the moment. 

	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? 

Thanks for the feedback!
-Scott

	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
	_______________________________________________ 
	cas-dev mailing list
	cas-dev at tp.its.yale.edu
	http://tp.its.yale.edu/mailman/listinfo/cas-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20061107/3e3935d3/attachment.html