Attributes are cached in the TGT, yes. The caching of merged attributes is not required; it only comes into play when you logout and destroy your TGT and attempt to log back in, at which time depending on persondir cache configuration, the repository may not be contacted because it already has cached copies of the attributes. So things will go faster, if the attribute-fetching process from the repository is a resource-expensive operation.
I suppose, the most comprehensive example is what uPortal does today with persondir: https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resource s/properties/contexts/personDirectoryContext.xml Note that a side-effect of caching attributes in the TGT is that they will not change during the lifetime of a TGT; so if you decided to change an attribute from X to Y, at this point, the only way to recognize that change is to ask the user to log out and log back (think attribute-driven MFA for instance). Future versions of CAS will present a feature to not require that logout, should you need immediate changes to the attribute repository. What sort of odd dependency requirements are you running into? -----Original Message----- From: Whittaker, Geoffrey [mailto:[email protected]] Sent: Wednesday, July 29, 2015 11:55 AM To: [email protected] Subject: RE: [cas-user] Attribute repository with multiple different sources So, I've been playing with this for a few hours now and I was wondering if someone could share some insights. The documentation on github says to use a large blob of beans and I was reviewing the persondir docs and it seems much simpler on theirs. I was wondering is the caching of the merged attributes necessary? I mean, they're cached already in the TGT, right? Also, I keep running into odd dependency requirements when I try to implement as shown in github. Does anyone have a working template they can share with me? >From github: <bean id="mergedPersonAttributeDao" class="org.jasig.services.persondir.support.CachingPersonAttributeDaoImpl" > <property name="cacheNullResults" value="true" /> <property name="userInfoCache"> <bean class="org.jasig.portal.utils.cache.MapCacheFactoryBean"> <property name="cacheFactory" ref="cacheFactory" /> <property name="cacheName" value="org.jasig.services.persondir.USER_INFO.merged" /> </bean> </property> <property name="cachedPersonAttributesDao" > <bean id="mergedPersonAttributeDao" class="org.jasig.services.persondir.support.MergingPersonAttributeDaoImpl" > <property name="merger"> <bean class="org.jasig.services.persondir.support.merger.NoncollidingAttributeAd de r" /> </property> <property name="personAttributeDaos"> <list> <bean class="org.jasig.services.persondir.support.CascadingPersonAttributeDao"> <property name="personAttributeDaos"> <list> <ref bean="anotherDao" /> </list> </property> </bean> </list> </property> </bean> </property> </bean> -----Original Message----- From: Whittaker, Geoffrey [mailto:[email protected]] Sent: Tuesday, July 28, 2015 10:54 AM To: [email protected] Subject: RE: [cas-user] Attribute repository with multiple different sources Thanks Tom. That looks like just the ticket (pardon the pun). Hopefully, I can incorporate that without too much trouble. Geoff -----Original Message----- From: Tom O'Neill [mailto:[email protected]] Sent: Tuesday, July 28, 2015 10:41 AM To: [email protected] Subject: RE: [cas-user] Attribute repository with multiple different sources Geoff, In the past with CAS 3.5.x I've used a merging attribute repository to implement the behavior you are describing. Each attribute repository can have its own search filter and there are multiple strategies for how merging occurs when the attribute is available from both sources. The options for attribute release in CAS 4 are outlined in the github hosted documentation: http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html Hopefully that helps! Thanks, Tom O'Neill Senior Consultant Strata Information Group -----Original Message----- From: Whittaker, Geoffrey [mailto:[email protected]] Sent: Monday, July 27, 2015 11:20 AM To: [email protected] Subject: RE: [cas-user] Attribute repository with multiple different sources I'd thought of that, but was worried how cas might react. I'll do a test build of that and see what happens. I'm Also looking at the possibility of adding the CN field to the second LDAP source. Geoff -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Monday, July 27, 2015 9:23 AM To: [email protected] Subject: Re: [cas-user] Attribute repository with multiple different sources Geoffrey, Can you just map both 'uid' and 'cn' to 'UDC_IDENTIFIER'? I could see a potential issue with that if one directory supports both attributes and there would be some potential ambiguity about which attribute would actually end up being mapped. I am guessing there is likely to be a solution to this baked into CAS. You can also handle this by manipulating the LDAP response before it reaches CAS with an LDAP proxy. Specifically, you could convert the 'cn' attribute in the response of LDAP2 to 'uid'. I wrote a blurb on setting up an LDAP proxy [1], though I am just noticing that my code formatting was messed up. A well-formatted code example can be found on github[2]. This is a more heavy-handed approach, so I'd probably try experimenting with CAS attribute mappings first. Thanks, Carl Waldbieser [1] https://lifeonlayer7.wordpress.com/2015/07/18/ldap-proxy/ [2] https://github.com/twisted/ldaptor/blob/master/docs/source/cookbook/ldap-p ro xy.rst ----- Original Message ----- From: "Geoffrey Whittaker" <[email protected]> To: [email protected] Sent: Monday, July 27, 2015 7:36:19 AM Subject: [cas-user] Attribute repository with multiple different sources I have CAS4 with two LDAP Auth Handlers. The first is pointed at my local Active Directory (LDAP1) which has my Employees, Staff, Faculty, etc.. The second is pointed at another LDAP server (ldap2) which contains alumni, parents, and other 'special' people. Currently, if the search of LDAP1 fails CAS falls through to LDAP2. In the past, it's been sufficient for those people only in LDAP2 to merely authenticate. Now, I need to get an attribute from that directory and map it to the attribute map to the same field that LDAP1 would use. The problem is the name of the fields is different. In LDAP1 the field is 'cn' in LDAP2 the field is 'uid'. I somehow have to get that value from into a custom Attribute field we called UDC_IDENTIFIER regardless of the directory. Can I have more than one attribute repository, and if can someone point to an example config? Am I making this too complicated? Is there another way to handle this? Thanks -- 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
