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

[Scott Battaglia]

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/20061106/fab2bb86/attachment.html