Our CAS filters have always checked for the assertion, and not whether getRemoteUser was set (since its technically not a requirement).
I wonder if it makes sense to do the following: 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). 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. They don't have to happen together, but #2 isn't terribly useful (other than simpler configuration) without #1 being done. Thoughts? On Mon, Apr 19, 2010 at 11:05 PM, Bryan Wooten <[email protected]> wrote: > Thanks Scott, I was hoping for your reply. > > I didn't write the application. This is just the way the developer decided > to do things, but as you know there is the "big" picture. > > I would have preferred they followed the instructions found via the wiki > pages or asking questions on this mailing list. > > The problem is political and personal. We have over 100 applications and > the (some) developers would rather I mod our peoplesoft filter to check for > CAS (as stated). They think adjusting their web.xml is "too much work". > > Honestly I can mod my peoplesoft filter to do cas auth as described in very > few lines of code. But it doesn't "feel" right, CAS client could change > method names/signatures and we would break. > > Thanks for your feedback, the Oracle acquisition of Sun has really caught > us with our pants down. :) (RIP OpenSSO) > ________________________________________ > From: Scott Battaglia [[email protected]] > Sent: Monday, April 19, 2010 7:38 PM > To: [email protected] > Subject: Re: [cas-user] Is this design good or bad or indifferent? > > Is there a reason you didn't just use the CAS Client filters and configure > them in Spring? Was some part of that not sufficient? > > > > On Mon, Apr 19, 2010 at 11:32 AM, Bryan Wooten <[email protected] > <mailto:[email protected]>> wrote: > We have a Spring application that is using CAS. This application does not > use the CAS client jar as a filter. The design uses a Spring Interceptor > and makes calls directly to CAS client classes. > > So when the application is first hit we do a “response.sendRedirect()” to > our CAS server login URL. When the application is set a request with a > “ticket” parameter it calls > org.jasig.cas.client.validation.Cas20ServiceTicketValidator.validate() > directly. The application gets the principal like this: > > Assertion casAssertion = this.ticketValidator.validate(myTicket, > localServiceUrl); > String unid = casAssertion.getPrincipal().getName(); > > At this point we are successfully logged in and the unid is placed on the > session. For here on out the interceptor checks to see if there is a unid > on the session, if there is one then the user is assumed to be logged in and > CAS is never referenced again. > > What does the group think of this? > > Thanks, > > Bryan Wooten > > UIT Systems Administrator > University of Utah > > [email protected]<mailto:[email protected]> > > > > -- > You are currently subscribed to [email protected]<mailto: > [email protected]> as: [email protected]<mailto: > [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 > > > -- > 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
