FWIW, the Spring Modules projects is defunct: https://springmodules.dev.java.net/ <https://springmodules.dev.java.net/>
It’s kind of sad that actively used projects depend on other dead projects. Cheers, D. > On Jul 30, 2015, at 8:25 AM, Whittaker, Geoffrey <[email protected]> > wrote: > > Thanks, > > I don't think that requiring the logout is sufficiently painful enough to > warrant the other cache for us. > > I was getting problems with needing spring-modules-cache. I added that to > my POM, but it has like 31 dependencies. And apparently they were not all > in the sonnatype repos. I found a post on the uportal list where someone > had a similar problem and excluded most of them. I was able to get it to > build after that, but I still wasn't getting it to work. > > Since I'm not doing the cached repository right now, I'm not worried about > it any longer. Now, I'm just concentrating on fixing the > LdapPersonAttributeDao and wiring up the MergingPersonAttributeDAO. For > some reason, I'm not getting a query builder returned (getting NULL), so the > queries either aren't happening or are happening for nothing. The logs are > below, but I dont think it's anything complicated. I probably just > fat-fingered something yesterday. > > 2015-07-29 15:10:12,263 DEBUG > [org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver] - > Creating SimplePrincipal for [me] > 2015-07-29 15:10:12,263 DEBUG > [org.jasig.cas.persondir.LdapPersonAttributeDao] - Created seed > map='{username=[me]}' for uid=' me' > 2015-07-29 15:10:12,263 DEBUG > [org.jasig.cas.persondir.LdapPersonAttributeDao] - Generated query builder > 'null' from query Map {username=[me]}. > 2015-07-29 15:10:12,263 DEBUG > [org.jasig.cas.persondir.LdapPersonAttributeDao] - No queryBuilder was > generated for query {username=[ me]}, null will be returned > 2015-07-29 15:10:12,279 DEBUG > [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - > org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver@1705 > dc3f resolved me from me+password > 2015-07-29 15:10:12,279 INFO > [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - > Authenticated me with credentials [n00638663+password]. > 2015-07-29 15:10:12,279 DEBUG > [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - Attribute > map for me: {} > > > Geoff > > -----Original Message----- > From: Misagh Moayyed [mailto:[email protected]] > Sent: Thursday, July 30, 2015 1:42 AM > To: [email protected] > Subject: RE: [cas-user] Attribute repository with multiple different sources > > 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 -- 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
