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:mmoay...@unicon.net]
Sent: Thursday, July 30, 2015 1:42 AM
To: cas-user@lists.jasig.org
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:geoff.whitta...@unf.edu]
Sent: Wednesday, July 29, 2015 11:55 AM
To: cas-user@lists.jasig.org
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:geoff.whitta...@unf.edu]
Sent: Tuesday, July 28, 2015 10:54 AM
To: cas-user@lists.jasig.org
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:one...@sigcorp.com]
Sent: Tuesday, July 28, 2015 10:41 AM
To: cas-user@lists.jasig.org
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:geoff.whitta...@unf.edu]
Sent: Monday, July 27, 2015 11:20 AM
To: cas-user@lists.jasig.org
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:waldb...@lafayette.edu]
Sent: Monday, July 27, 2015 9:23 AM
To: cas-user@lists.jasig.org
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" <geoff.whitta...@unf.edu>
To: cas-user@lists.jasig.org
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 cas-user@lists.jasig.org as:
geoff.whitta...@unf.edu 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:
geoff.whitta...@unf.edu 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:
geoff.whitta...@unf.edu To unsubscribe, change settings or access archives,
see http://www.ja-sig.org/wiki/display/JSG/cas-user
smime.p7s
Description: S/MIME cryptographic signature
