> From: Scott Battaglia [mailto:[email protected]] > Sent: Tuesday, October 01, 2013 7:58 PM > > I looked at migrating to Spring 3's caching APIs and its more effort than I > expected it to be. I'll have to defer it for now.
Our applications group contracted Unicon to help them out with uPortal deployment, I spent a little time today with them discussing our CAS implementation. I've actually got two issues with CAS and attribute caching - this issue, that I can't really see a clean way to implement persondir attribute caching within a CAS context, and then that CAS itself caches attributes too long, I think there should be a way to have attributes refreshed more often than you might want to have the lifetime of the TGT. We came to the conclusion that potentially the best approach moving forward would be to have CAS stop storing attributes with the TGT, but instead do a fresh lookup of them for every service ticket granted, along with fixing persondir caching to work better with CAS. This would allow you to separate your session timeouts for TGT's from attribute cache timeouts, the former configured within CAS and the latter based on your persondir cache configuration. Unicon said this is something they could potentially work on for us and contribute back to CAS/persondir. I'm not sure how much effort it would actually require; our applications group tends to have a fairly large budget for consulting, so I'm hoping I might be able to shoehorn this CAS enhancement into their uPortal deployment budget ;)... Plus, they had actually budgeted for Unicon to configure/deploy CAS for them, and I kind of already went and did that, so at the very least that chunk of change should be available... -- 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
