I guess the question is really do we care that they were authenticated already, or do we care that they used CAS to authenticate?
The first option allows for better chaining of different methods. The second option might (?) be more secure (since we know how they authenticated then). On Tue, Apr 20, 2010 at 7:31 AM, Marvin Addison <[email protected]>wrote: > > 1. Have the CAS filters automatically check getRemoteUser (and possibly > > fallback to checking the assertion). This means that if anything else > > authenticates the system, the CAS filters will let it through (instead of > > just letting CAS authentications through now). > > We just discussed this behavior recently while working on the JAAS > module for the Java CAS client. It would be useful in some cases to > allow the CAS AuthenticationFilter to have a trust mode where it > trusts upstream filters that set remoteUser/userPrincipal. My only > concern with this is that it feels like a lie: the CAS authentication > filter isn't checking for CAS authentication anymore but > authentication of any kind, no matter how strong or weak. It may be > desirable in some cases, but could have security implications that > need to be clearly documented. > > > 2. Get rid of the filter that sets getRemoteUser and just fold it into > the > > validation filter and make it a requirement that the getRemoteUser is > set, > > rather than optional. > > -1 > The current filter arrangement is well designed where each has a > single well-defined purpose. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
