Hi, For our current purposes, the caching for TGT lifetime works fine. As someone mentioned I’d be a little concerned with LDAP lookup time and performance at peak periods without any sort of caching mechanism at all. Our TGT lifetime is currently ”a work day”.
But, if we were to implement remember-me with longer TGT-lifetime (as I assume it works), and as the number of apps using the extra attributes grows, this might become an issue. Some configurable period of time works, and in the case of storage separate from tickets, the entire storage backend has to be pluggable, as suggested, for our purposes. Regards, /Fredrik -- Fredrik Jönsson, M.Sc. Email: f...@kth.se<mailto:f...@kth.se> System architect Phone: +46 8 790 66 03 Kungliga tekniska högskolan (KTH) Mobile: +46 73 595 66 03 KTH/UF/ITA/Infosys 24 sep 2014 kl. 23:26 skrev Daniel Ellentuck <d...@columbia.edu<mailto:d...@columbia.edu>>: Hi Misagh, I used ehcache and didn't worry about synchronizing the cache across hosts. Something like: <bean id="spring-ehCacheFactory-for-attributes" class="org.springframework.cache.ehcache.EhCacheFactoryBean" > <property name="cacheName" value="ldapAttributes"/> <property name="maxElementsInMemory" value="5000"/> <property name="eternal" value="false"/> <property name="overflowToDisk" value="false"/> <property name="timeToIdle" value="120"/> <property name="timeToLive" value="120"/> <property name="diskExpiryThreadIntervalSeconds" value="60"/> </bean> ... Dan Ellentuck Columbia University I.T. On Wed, Sep 24, 2014 at 12:07 PM, Misagh Moayyed <mmoay...@unicon.net<mailto:mmoay...@unicon.net>> wrote: Dan, that seems like a great way to go. The proposed pull does allow for alternative implementations, and I wonder if we can also provide an option for attributes to be cached and then expired after a configurable period of time. How did you end up caching the attributes? What was the cache storage? From: Daniel Ellentuck [mailto:d...@columbia.edu<mailto:d...@columbia.edu>] Sent: Wednesday, September 24, 2014 8:14 AM To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> Subject: Re: [cas-dev] Dynamic Principal Attributes: scope and feedback Hi Carl, et. al., This would be a nice option to have, but I'd recommend a 2-phased approach, which I implemented in the local precursor system to CAS. When users in the local university environment power up at the start of the day, whether to log into a portal or just a bunch of applications, they often create a lot of attribute retrieval requests in a brief interval. It made sense for both performance and consistency to cache those results for a short time, like 120 seconds, but not for the life of the TGT. Dan Ellentuck Columbia University I.T. On Wed, Sep 24, 2014 at 9:52 AM, Waldbieser, Carl <waldb...@lafayette.edu<mailto:waldb...@lafayette.edu>> wrote: Am I correct in understanding that the current behavior is to load the attributes at the time of authentication and they get stored for the life of the TGC (in the CAS ticket store)? And the proposal would be to allow the attributes to be re-populated whenever a /serviceValidate or /proxyValidate request was successfully made? I hadn't noticed this behavior. I had rather assumed the dynamic behavior was how CAS was working all along. What exactly would be the concerns with enabling that as an option? Are there performance concerns? Or some kind of consistency concerns? Thanks, Carl Waldbieser Systems Programmer Lafayette College ----- Original Message ----- From: "Misagh Moayyed" <mmoay...@unicon.net<mailto:mmoay...@unicon.net>> To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> Sent: Wednesday, September 24, 2014 5:23:29 AM Subject: [cas-dev] Dynamic Principal Attributes: scope and feedback Team, Context: https://github.com/Jasig/cas/pull/676 https://github.com/Jasig/cas/issues/468 There is a pending pull and corresponding issue that tries to bring forth support for dynamic principal attributes. This is the case where principal attributes are not cached to the length of the SSO session, but are forced to always be up-to-date when called upon. I want to emphasize that this is not proposed replace the default behavior now, yet simply allows one to do this, should the use case come up. Jérôme and I have been conversing on pros and cons of this feature, and what it would mean for CAS deployers to turn on support for this. We are at a point where we need more eyeballs and feedback on the issue and the solution presented. It would be great if you could take a look at the conversation and provide suggestions on how to best proceed forward. Regards, -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: waldb...@lafayette.edu<mailto:waldb...@lafayette.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: d...@columbia.edu<mailto:d...@columbia.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: mmoay...@unicon.net<mailto:mmoay...@unicon.net> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: d...@columbia.edu<mailto:d...@columbia.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: f...@kth.se<mailto:f...@kth.se> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
