1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices. 2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups 3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that! 4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups if not 4.) my recommendation would be 2a.) being the minimal invasive alternative. Hope this helps, Peter Am 06.05.2013 12:21, schrieb Geo P.C.:
-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz |