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

[Scott Battaglia]

We're recommending that Acegi users upgrade to the latest CAS Server release
(3.0.5) as it fixes an issue with encoded jsessionids.  That is a different
announcement.  The client is unaffected by this.  I will work on adding the
new CAS client support to Acegi after the final release of the client
though.

-Scott

On 11/7/06, March, Andres <amarch at soe.sony.com> wrote:
>
>  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
>
>
>
> _______________________________________________
> 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/5ba15160/attachment-0001.html