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

[Scott Battaglia]

Thanks for the feedback. As for the option of making the error silent I had
actually thought of a similar thing.  If you can file a JIRA issue, we can
get that in for a 3.0.1 release!

Thanks
-Scott

On 11/10/06, Velpi <velpi at industria.be> wrote:
>
> 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
> _______________________________________________
> 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/20061110/56f7adc0/attachment.html