[cas-user] caching attributes?
So I'm trying to get CAS to retrieve attribute from LDAP, and ideally cache them to decrease load. I'm looking at: https://wiki.jasig.org/display/PDM15/Attribute+Caching and trying to figure out how to set the size of the cache and the TTL. It seems I need to use the userInfoCache property to tell it what cache to use. I've found some examples that use org.jasig.portal.utils.cache.MapCacheFactoryBean for this, which has a property "cacheFactory", but I haven't found any examples for that definition. Am I missing some obvious documentation somewhere? My google-fu is failing me, I've been flailing at this for a couple of hours and really made no headway on understanding how to configure this caching. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
So I'm trying to get CAS to retrieve attribute from LDAP, and ideally cache them to decrease load. I would exercise caution with this approach. CAS natively employs attribute caching; attributes are only fetched on user authentication, so attributes are naturally cached for the duration of the SSO session. In most cases that's at least once per day which is arguably too long for certain kinds of authorization data. Adding additional caching on top of that sounds like a tradeoff you would make only upon careful analysis with your security folks. That said, we use Ehcache in a custom attribute resolver to cache attributes during the authentication pipeline. We want to hit the directory exactly once during authentication, but it turns out we needed to perform at least two (possibly three) queries to resolve some data for user attributes as well as audit data. The caching TTL was carefully chosen to have data hang around only long enough to prevent duplicate queries against the directory during the authentication flow. https://wiki.jasig.org/display/PDM15/Attribute+Caching and trying to figure out how to set the size of the cache and the TTL. I'm going to go on record and say I hate Person Directory. The only way I figure things out is by reviewing source: https://github.com/Jasig/person-directory/blob/rel-1.5.0-RC6/person-directory-impl/src/main/java/org/jasig/services/persondir/support/CachingPersonAttributeDaoImpl.java Good luck. M -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
> servers. While I might end up not implementing caching for the LDAP queries, > could I trouble you to share your configuration if only so I can understand > how it's supposed to work :)? Here's the cache configuration we use for our custom resolver: Honestly we haven't measured the cache miss ratio in production under load, but I'm certain it helps reduce the number of queries against our directories while in the auth pipeline. M -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
On 9/13/2013 6:25 AM, Marvin S. Addison wrote: I would exercise caution with this approach. CAS natively employs attribute caching; attributes are only fetched on user authentication, so attributes are naturally cached for the duration of the SSO session. Ah, I did not realize that the attributes were cached with the TGT. That does indeed make caching attributes at the persondir level much less necessary. In most cases that's at least once per day which is arguably too long for certain kinds of authorization data. Yes, I'll have to mention this to our security group to take into account when deciding how long a TGT should last. It would be nice to have a feature that would not require the user to re-authenticate but would refresh their attributes more frequently (I'd probably go with hourly). That said, we use Ehcache in a custom attribute resolver to cache attributes during the authentication pipeline. I'm already using ehcache to replicate tickets between load balanced servers. While I might end up not implementing caching for the LDAP queries, could I trouble you to share your configuration if only so I can understand how it's supposed to work :)? I'm going to go on record and say I hate Person Directory. The only way I figure things out is by reviewing source: I can't say I'm very fond in general of the Java XML bean configuration methodology 8-/, it makes my head hurt :(. Thanks much for the information… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
On Fri, Sep 13, 2013 at 01:16:30PM -0700, Marvin Addison wrote: > Here's the cache configuration we use for our custom resolver: > >class="org.springframework.cache.ehcache.EhCacheFactoryBean" > p:cacheName="PrincipalCache" > p:eternal="false" > p:overflowToDisk="false" > p:maxElementsInMemory="100" > p:timeToLive="5" > p:timeToIdle="5"> > >class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" > /> > > Cool, thanks. So to integrate that into the cachingPersonAttributeDao config, you'd just set the userInfoCache property to "principalCache"? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
So to integrate that into the cachingPersonAttributeDao config, you'd just set the userInfoCache property to "principalCache"? I'm not certain since I've never used that component, but it certainly sounds like it would work. Seems easy enough to try. M -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
On Fri, Sep 13, 2013 at 01:44:43PM -0700, Marvin S. Addison wrote: > > So to integrate that into the cachingPersonAttributeDao > > config, you'd just set the userInfoCache property to "principalCache"? > > I'm not certain since I've never used that component, but it certainly > sounds like it would work. Seems easy enough to try. How are you integrating the cache into persondir if you're not using the persondir cache object? Are you inserting the cache somewhere in the ldap lookup pipeline instead so the LdapPersonAttributeDao object thinks it's doing an ldap lookup but hits the cache instead? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
> How are you integrating the cache into persondir if you're not using the > persondir cache object? We developed a custom resolver to meet our needs. I believe it uses PersonDirectory under the hood but the details are not based on any existing PD component. M -- You are currently subscribed to cas-user@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-user
RE: [cas-user] caching attributes?
> From: Marvin Addison [mailto:marvin.addi...@gmail.com] > > We developed a custom resolver to meet our needs. I believe it uses > PersonDirectory under the hood but the details are not based on any > existing PD component. Ah, gotcha. Thanks for the info... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
RE: [cas-user] caching attributes?
> From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] > > So to integrate that into the cachingPersonAttributeDao > > config, you'd just set the userInfoCache property to "principalCache"? > > I'm not certain since I've never used that component, but it certainly > sounds like it would work. Seems easy enough to try. Hmm, trying to do that resulted in a failure: java.lang.ClassNotFoundException: org.springmodules.cache.key.CacheKeyGenerator So I added spring-modules-cache to my maven dependencies and tried to rebuild, which failed: [WARNING] The POM for gigaspaces:gigaspaces-ce:jar:5.1-1603-000 is missing, no dependency information available [WARNING] The POM for jini:jsk-lib:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:jsk-platform:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:mahalo:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:reggie:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:start:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:boot:jar:20060125 is missing, no dependency information available [WARNING] The POM for jini:webster:jar:20060125 is missing, no dependency information available [WARNING] The POM for jboss:jboss-cache:jar:1.2.4 is missing, no dependency information available [WARNING] The POM for jboss:jboss-common:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-jmx:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-minimal:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-system:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jcs:jcs:jar:1.2.6.5 is missing, no dependency information available [WARNING] The POM for xpp3:xpp3_min:jar:1.1.3.4.I is missing, no dependency information available Per this fairly old mailing list posting, it seems spring-modules-cache is less than intelligent about dependencies: http://forum.spring.io/forum/attic/spring-modules/21843-spring-modules-cache-dependencies Evidently Spring Modules have been deprecated by Spring Extensions as well. This is really more of a persondirectory issue than a CAS issue, so I thought I'd try their mailing list, but the user list mentioned at: http://www.jasig.org/mailing-lists/person-directory simply no longer exists, and the developer list has not had a message posted since 2012 8-/. And the last commit to the github repo is from early January: https://github.com/Jasig/person-directory Is this project still under development? In any case, I've wasted way too much time trying to figure out how this caching is supposed to work. I guess if we have a load issue in the future I'll just drop in more LDAP servers . -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
I can't promise anything but I'll see if we can easily convert persondirectory to use Spring 3's cache apis. On Wed, Sep 18, 2013 at 5:34 PM, Paul B. Henson wrote: > > From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] > > > So to integrate that into the cachingPersonAttributeDao > > > config, you'd just set the userInfoCache property to "principalCache"? > > > > I'm not certain since I've never used that component, but it certainly > > sounds like it would work. Seems easy enough to try. > > Hmm, trying to do that resulted in a failure: > > java.lang.ClassNotFoundException: > org.springmodules.cache.key.CacheKeyGenerator > > So I added spring-modules-cache to my maven dependencies and tried to > rebuild, which failed: > > [WARNING] The POM for gigaspaces:gigaspaces-ce:jar:5.1-1603-000 is > missing, no dependency information available > [WARNING] The POM for jini:jsk-lib:jar:2.1 is missing, no dependency > information available > [WARNING] The POM for jini:jsk-platform:jar:2.1 is missing, no dependency > information available > [WARNING] The POM for jini:mahalo:jar:2.1 is missing, no dependency > information available > [WARNING] The POM for jini:reggie:jar:2.1 is missing, no dependency > information available > [WARNING] The POM for jini:start:jar:2.1 is missing, no dependency > information available > [WARNING] The POM for jini:boot:jar:20060125 is missing, no dependency > information available > [WARNING] The POM for jini:webster:jar:20060125 is missing, no dependency > information available > [WARNING] The POM for jboss:jboss-cache:jar:1.2.4 is missing, no > dependency information available > [WARNING] The POM for jboss:jboss-common:jar:4.0.3 is missing, no > dependency information available > [WARNING] The POM for jboss:jboss-jmx:jar:4.0.3 is missing, no dependency > information available > [WARNING] The POM for jboss:jboss-minimal:jar:4.0.3 is missing, no > dependency information available > [WARNING] The POM for jboss:jboss-system:jar:4.0.3 is missing, no > dependency information available > [WARNING] The POM for jcs:jcs:jar:1.2.6.5 is missing, no dependency > information available > [WARNING] The POM for xpp3:xpp3_min:jar:1.1.3.4.I is missing, no > dependency information available > > Per this fairly old mailing list posting, it seems spring-modules-cache is > less than intelligent about dependencies: > > > http://forum.spring.io/forum/attic/spring-modules/21843-spring-modules-cache-dependencies > > Evidently Spring Modules have been deprecated by Spring Extensions as > well. > > This is really more of a persondirectory issue than a CAS issue, so I > thought I'd try their mailing list, but the user list mentioned at: > > http://www.jasig.org/mailing-lists/person-directory > > simply no longer exists, and the developer list has not had a message > posted since 2012 8-/. And the last commit to the github repo is from early > January: > > https://github.com/Jasig/person-directory > > Is this project still under development? > > In any case, I've wasted way too much time trying to figure out how this > caching is supposed to work. I guess if we have a load issue in the future > I'll just drop in more LDAP servers . > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@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-user
RE: [cas-user] caching attributes?
> From: Scott Battaglia [mailto:scott.battag...@gmail.com] > > I can't promise anything but I'll see if we can easily convert persondirectory > to use Spring 3's cache apis. If that will make it any easier to actually use, that would be much appreciated :). It would be nice if the documentation could also include a couple of examples of working configurations, perhaps it's just my lack of java background but it's a bit mystifying how to get all the pieces to work together. Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@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-user
Re: [cas-user] caching attributes?
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. On Thu, Sep 19, 2013 at 7:59 PM, Paul B. Henson wrote: > > From: Scott Battaglia [mailto:scott.battag...@gmail.com] > > > > I can't promise anything but I'll see if we can easily convert > persondirectory > > to use Spring 3's cache apis. > > If that will make it any easier to actually use, that would be much > appreciated :). It would be nice if the documentation could also include a > couple of examples of working configurations, perhaps it's just my lack of > java background but it's a bit mystifying how to get all the pieces to work > together. > > Thanks much... > > -- > Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ > Operating Systems and Network Analyst | hen...@csupomona.edu > California State Polytechnic University | Pomona CA 91768 > > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@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-user
RE: [cas-user] caching attributes?
> From: Scott Battaglia [mailto:scott.battag...@gmail.com] > 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 cas-user@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-user
