On 05/31/2012 09:44 AM, Henrik Ingo wrote:
Hi Zisis

On Wed, May 30, 2012 at 3:58 PM, Zisis Sialveras<zisi...@gmail.com>  wrote:
I am currently coding the LDAP-based policy plugin and I want to discuss
some things with you to give me  some ideas. This is short introduction
about my plugin functionality: Whenever a user tries to read/write to a
schema, the plugin will search in ldap database for the user and the schema.
Depending on users' and schemas' attributes the ldap-policy plugin will
decide if access should be granted or denied to the user.

The problem is that I am having "hard" time to decide the arrangement of
users and schemas in LDAP database.
The first that came into my mind is that users should be in directory
cn=RANDOM_USER,ou=users,dc=BASE_DN. Users has posixAccount objectclass so
they must define their uidNumber and gidNumber.
Do you plan to support the case that user belongs to multiple groups?
Ie in Unix I have one gidNumber that is the primary group (for
instance username=hingo and groupname=hingo), but I can also belong to
any other group (like users, admins, projectmanhattan, etc...).

I think what you plan above with ou=users is correct, but you should
take into account that the gidNumber isn't necessarily the only group
I belong to. (Note that ou=users is of course an option for auth_ldap
plugin, so it could be anything else than "users" too.)

Btw, for a first version, I think you should keep it simple and not
worry about groups at all. (Note that other drizzle auth and policy
plugins don't have a concept of groups in Drizzle, so you'd still be
"feature complete" even without groups.)
A solution for this that I have seen in LDAP so far is, in groups directory in LDAP (let's say ou=groups,dc=BASE_DN), each group can have memberUID attribute. So if a schema has allowedGroups: 500, every user with gid = 500 is authorized. Also every memberUID, that belongs to the group with gid=500 is authorized too. So it will be easy enough to search not only the primary group, but supplementaries group also.

And schemas are in
cn=RANDOM_SCHEMA,ou=schemas,dc=BASE_DN and they have attribute like
allowedUsers and allowedGroups (I have already create those attrs because I
couldn't find anything else to use, feel free to msg me if you any better
solution). So after getting these attributes I compare them and decide if
user is authorized.

I think this is ok, and again, make sure the ou and dc are in fact
configurable options for ldap_policy plugin.
Done that.

How does the allowedUsers work? Is it a single attribute and you put a
comma separated list there? Or does the LDAP record contain multiple
allowedUsers entries, each containing a single user. (I'm sorry,
probably none of us know LDAP so well, so we need to ask these basic
questions.)
allowedUsers is an attribute that I have created. It stores integers ( uid ) and I have assigned it as multi-value. So each schema is allowed to have more than one entries of allowedUsers. So when a user wants access to a target schema. I just compare if uid is one of allowedUsers.
Shouldn't you also support table and process objects? Would they then
be in ou=tables and ou=processes?

Of course they will be support for tables and processes. For now, I have stuck with schema's implementation.
henrik



_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : drizzle-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to