I'm guessing (though I haven't tried it) that there should not be an issue with configuring Validation Filter before the Authentication Filter.  If you want to try it out, let me know if it works and I will update the documentation accordingly to say it doesn't matter what order.  We would need to ensure this doesn't open up any security issues though.

-Scott


On 10/4/06, Velpi <[EMAIL PROTECTED]> wrote:
> There is a reason that the AuthenticationFilter and the ValidationFilter
> are seperate.  There are instances where you'd like to do validation
> *if* a ticket is on the request, otherwise don't. We've configured a
> bunch of stuff that way.

Right, I see it now, looks ok to me this way.

Is there a reason why the filters should be placed authenticationFilter-first?
Remember that validation always sets a principal on the request (one-time-use at
the validation request), and may set an assertion in the session (multi-use).

now:
1) authentication: if no ticket AND no assertion AND not gatewayed
2) validation: if ticket

my suggestion:
1) validation: if ticket
2) authentication: if no *principal* AND no assertion AND not gatewayed
=>
* authentication is based on whether there's valid principal, in stead of 'a' ticket
* authentication filter has access to the principal


The main reason why *I* would like this is because my modified authentication
filter will choose whether or not to use renew/session/gateway/... based on the
principal (and it attributes). This is useful when you want another policy for
eg students and personnel. But it can only be accomplished if validation has
been done first.


--Velpi
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Reply via email to