[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: "Access to" directives for RDBMs-LDAP model mapping
On Mon, 26 Apr 2004, Ivan Montoro wrote:
> Hi folks,
>
> We are working on a LDAP module for hipergate.org. FYI
> hipergate is a
> CRM suite with Contacts information, managed by
> security service based
> upon a RDBMS model. Each "user" belongs to a
> "workarea" (or workgroup),
> which contains "contact" information. A "contact"
> could be public to
> all members of the "workarea" or private for a certain
> user.
>
> We want to use LDAP as an easy way to access our
> information from Outlook/Mozilla/Evolution, but we
> have problems with the security restrictions using the
> "access to" directives at slapd.conf.
>
> I'm trying to figure up how to map this security model
> in a LDAP structure. No modifications can be done at
> LDAP, as database is exported in a batch
> process. This is an example of the proposed directory
> structure:
>
> -----------------------------------------------------------------------
> dc=org
> `-- dc=hipergate
> `-- dc=workareas
> `-- dc=d41d8cd98f00b204e9800998ecf8427e
> (workarea GUID)
> |-- dc=contacts
> | `-- dc=John Public
> | @-- givenName: John
> | @-- sn: Public
> | @-- mail: john.public@acme.com
> `-- dc=users
> `-- dc=joe.user@hipergate.org
> @-- objectClass: person,
> inetOrgPerson
> @-- mail: joe.user@hipergate.org
> @-- userPassword: xxxxxxxxx
> `-- dc=contacts
> `-- cn=Jane Private
> @-- givenName: Jane
> @-- sn: Private
> @-- mail:
> jane.private@acme.com
> -----------------------------------------------------------------------
>
> "John Public" will be visible by any authenticated
> user belonging to
> the corresponding "workarea" and "Jane Private" will
> be only visible to
> "joe.user@hipergate.org". Is there an easy way to
> implement security
> restrictions only with "access to" directives at
> slapd.conf?
>
Yes. See for example this one:
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/openldap/slapd.access.conf?rev=1.2&content-type=text/x-cvsweb-markup
The last example is pretty close to what you want for dc=contacts,dc=$GUID
> * Anonymous users can authenticate agains "users"
> entries
No problem.
> * Authenticated users can see its own "contacts"
> (subtree)
No problem (but you will need to write your own regex-based ACL).
> * Authenticated users can see "contacts" inside their
> parent "workarea"
The example I linked to shoiuld work with minimal modification.
>
> I'm also wondering how a user can bind to the
> directory using only its
> "cn" and "userPassword", without having to enter all
> the "dn" info, so
> Bind DN could be just "joe.user@hipergate.org".
I'm not sure about this one ... especially if you can't search on the mail
before authenticating.
Regards,
Buchan
BTW, using dc= for attributes which clearly are not domain-related objects
is probably not a good idea ... cn is most comonly used if you have
nothing better to name an attribute by ... but if it is an email address,
mail would probably be better ...).