Le 03/06/2009 16:30, Marvin Addison a écrit :
Olivier, I reviewed our configuration against yours, and I see why
yours does not work. I don't believe there is a way to do what you
want.
Argh ! Thanks for comparing configurations. What's your ldap server
software (just by curiosity) ?
In our case we have a groupMembership attribute on the People branch:
ou=People
dn=uid=1234
eduPersonAffiliation=staff
groupMembership={group1, group2, group3}
dn=uid=567
eduPersonAffiliation={student, faculty}
groupMembership={group4, group5, group6}
where groupMembership is a distillation of all the entries in the
ou=Groups branch to which a person belongs.
Do you think this method
http://www.openldap.org/doc/admin23/overlays.html#Reverse%20Group%20Membership%20Maintenance
Could do the trick ? Please, say yes :-)
It appears that LdapPersonAttributeDAO is intended solely for the use
case where you're searching for a _single_ entry and reading
attributes from it. In your case you need multiple results, and
LdapPersonAttributeDAO complains about non-unique results and discards
them all.
That was indeed the meaning of the uniqueness in my first mail.
It's my opinion that yours is a use case that should be supported by
CAS out of the box and it's something that I hope we will pursue in a
future release of CAS. I encourage you to open a Jira improvement
issue for your use case to put it on the development roadmap.
Hmm it depends if you think it's a lack of the user storage or a lack of
cas server... Maybe cas server could do this itself, I don't know where
the solution belong. If you're "sure", I'll open the bug in Jira.
Would it be possible to modify your LDAP schema to create an
applications attribute on your ou=Utilisateurs branch that contains
all of entries in the ou=Applications to which each person belongs?
(see open ldap modification)
Olivier
--
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
