(CCing the list)
On 09/07/12 17:02 +0200, David Rose wrote:
On 09/07/2012 04:17 PM, Dan White wrote:
On 09/07/12 15:59 +0200, David Rose wrote:
Hi everyone,
Is anybody know if it's possible to define roles in OpenLDAP using back-sql?
Here's the thing, we need to prevent some of our users to see "everything". We need to filter results for some groups of users. But we need these rules in the database (Postgres) to be able to change them dynamically.
Consider using the dynamic slapd-config backend instead. See chapters 5 and 8 of the OpenLDAP Administrator's Guide.
We have a WebApp that stores all its data in Pg and we'd like to access it using LDAP without having to replicate the database. And AFAIK slapd-config and back-sql aren't compatible.
I don't know.
Problem is that, currently, when a user send a search query, OpenLDAP does not include in any way the DN of the user who made the query.
That seems counterintuitive. Are your users binding anonymously? If so, don't do that.
None of our users are bind anonymously. They're logged in, LDAP knows who's logged in, but doesn't tell Pg when a search query is passed.
How do they 'log in'. Do they bind using user credentials directly to the LDAP server, or do they log in to a website? If the latter, then see if your webapp supporting binding *using the user's credentials* when querying the ldap server. Or see if it supports binding with an authz identity matching the user.
On 09/07/2012 05:15 PM, Dan White wrote:
(CCing the list)
On 09/07/12 17:02 +0200, David Rose wrote:
On 09/07/2012 04:17 PM, Dan White wrote:
On 09/07/12 15:59 +0200, David Rose wrote:
Hi everyone,
Is anybody know if it's possible to define roles in OpenLDAP using back-sql?
Here's the thing, we need to prevent some of our users to see "everything". We need to filter results for some groups of users. But we need these rules in the database (Postgres) to be able to change them dynamically.
Consider using the dynamic slapd-config backend instead. See chapters 5 and 8 of the OpenLDAP Administrator's Guide.
We have a WebApp that stores all its data in Pg and we'd like to access it using LDAP without having to replicate the database. And AFAIK slapd-config and back-sql aren't compatible.
I don't know.
Problem is that, currently, when a user send a search query, OpenLDAP does not include in any way the DN of the user who made the query.
That seems counterintuitive. Are your users binding anonymously? If so, don't do that.
None of our users are bind anonymously. They're logged in, LDAP knows who's logged in, but doesn't tell Pg when a search query is passed.
How do they 'log in'. Do they bind using user credentials directly to the LDAP server, or do they log in to a website? If the latter, then see if your webapp supporting binding *using the user's credentials* when querying the ldap server. Or see if it supports binding with an authz identity matching the user.
Website loggin and LDAP binding are separate. Our goal is to access the same data from either the website and LDAP server. So, for LDAP queries, they bind using credentials directly to the LDAP server.
On 09/07/12 17:20 +0200, David Rose wrote:
On 09/07/2012 05:15 PM, Dan White wrote:
On 09/07/12 17:02 +0200, David Rose wrote:
On 09/07/2012 04:17 PM, Dan White wrote:
On 09/07/12 15:59 +0200, David Rose wrote:
Hi everyone,
Is anybody know if it's possible to define roles in OpenLDAP using back-sql?
How do they 'log in'. Do they bind using user credentials directly to the LDAP server, or do they log in to a website? If the latter, then see if your webapp supporting binding *using the user's credentials* when querying the ldap server. Or see if it supports binding with an authz identity matching the user.
Website loggin and LDAP binding are separate. Our goal is to access the same data from either the website and LDAP server. So, for LDAP queries, they bind using credentials directly to the LDAP server.
I think I see now. You have both user credentials and authorization (roles) stored in a postgresql database, which you want to use in a new ldap installation?
With direct ldap binds, then either the user's DN, or their authc identity (in the case of SASL binds) will be available for ACL restriction. If you also have group definitions, then you should try to shoe horn them into ldap entries with objectClass 'groupOfNames', or a similar structure, that will allow you to apply ACL restrictions to.
openldap-technical@openldap.org
-
Dan White -
David Rose