[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: regex in group ACL


first, thank you very much for spending time for me

Pierangelo Masarati wrote:


your mail was very useful to understand what's going on.  I think there
might be a solution with either 2.1 or 2.2, and recent improvements in
HEAD will make it even more efficient, provided it matches your
requirements.  There is still something I need to understand from your
mail; see below.

# Entry 3:

versionNumber: 2

cn: exampleSSOStorageV2
objectClass: exampleSSOStorage

1.a) Is there a __finite__ set of account RDNs? I mean, "exampleSSOStorageV2", "accountX" and so, but a limited, well defined number of types, which are known at configure time, so they can be enumerated in ACLs? 1.b) Or do they change and grow at run-time? 1.c) Furthermore, do users have children that are not accounts? 1.d) Or do accounts have children that are not delegations?

a) no
b) yes
c) yes
d) yes

My software stores the accounts a user has in any application he uses.

But after reading your post, I think you misunderstood my architecture.

under a user entry, there is some entries used by my software.
One of these entries is of class 'exampleSSOStorage'.
Under this entry are stored the user's accounts, using entries of class 'exampleSSOAccount'.

With the current access control, every user has write access to all the account entries under its 'exampleSSOStorage' subentry.
But it has no access to other users accounts entries.
My software implements a concept of delegation, which means that a user can use one of the accounts of another user.
To store this delegation information, the software creates an entry of class 'exampleSSOAccountDelegation' under the account every time an account is delegated to a user. And this entry references the user by storing his DN in the exampleUserEntityObject attribute.

Now, for the user to be able to access somebody else's account, he must have the LDAP read access right on the exampleSSOAccount object.

To achieve this, I had the idea to use the information stored in the exampleSSOAccountDelegation object, because it contains the DN of the user.

so i had the idea to write the access rule :

access to filter="(objectClass=exampleSSOAccount)" dn.regex="(.*)"
by group/exampleSSOAccountDelegation/exampleUserEntityObject.regex="(.*),$1"

so the user referenced in the exampleSSOAccountDelegation entry (in its exampleUserEntityObject attribute))will be able to access the exampleSSOAccount entry just above.

The exampleSSOAccountDelegation is just a way to store information related to the delegation, like the dn of the user which the account is delegated to, or the type of delegation, its expiration time, etc.

As you can see, the accounts objects are stored as exampleSSOAccount

objectClass entries, under an object of class exampleSSOStorage. The
delegation objects are of class exampleSSOAccountDelegation

4) Is the delegation's DN the identity you want to give access rights

for the user's entry?

Probably due to the fact that English is not my natural language, I

don't understand you.

.. or I need to reword my question :)

But I think my LDIF export will be a good explanation.

In this case, the access right rule would be :

access to
   by dn="uid=francois,ou=Tests FB,dc=example,dc=local" read

Indeed, I want a more generic rule :) and since "uid=francois,ou=Tests

FB,dc=example,dc=local" is stored in the exampleSSOAccountDelegation
object through its exampleUserEntityObject attribute :

access to


(Where 'group' has to be replaced with

But here it only works for one account of one user, so the very generic

rule would be :

access to filter="(objectClass=exampleSSOAccount)" dn.regex="(.*)"
   by group.regex="(.*),$1" read

But this doesn't work (see my previous posts)

Important precision : *One delegation object is created of each user

which the account is delegated to*. So there can be several

exampleSSOAccountDelegation objects under one exampleSSOAccount object.

And there is only one value of exampleUserEntityObject in a

exampleSSOAccountDelegation  entry.

So maybe I could find a way with dnattr... but I don't find one

Initially, I thought your intention was to give __delegation__ access to
the ___user__ entry, so in a rule

access to <what>
 by <who> <rights>

the <what> is __user__ and the <who> is __delegation__

In this case you can do

access to dn.regex="^uid=([^,]+),ou=Tests FB,dc=example,dc=local$"

The DN in the <who> clause, as opposed to groups, __IS__ evaluated as a

No, __delegation__ is not a user, its just a container to store some information related to the delegation

But now I seem to realize that you want to do the opposite, i.e. give
__user__ access to the __delegation__ entry, so in a rule

access to <what>
 by <who> <rights>

the <what> is __delegation__ and the <who> is __user__

In this case you can do (2.2)

access to dn.regex="^cn=[^,]+,cn=[^,],uid=([^,]+),ou=Tests
       by dn.exact,expand="uid=$1,ou=Users,dc=example,dc=local" <access>

or (2.1)

access to dn.regex="^cn=[^,]+,cn=[^,],uid=([^,]+),ou=Tests
by dn.regex="^uid=$1,ou=Users,dc=example,dc=local$" <access>

No, because the _what_ is the account (exampleSSOSaccount), and the _who_ is another user of the directory, who has its DN in the _delegation_ object under the account.


Of course these rules do not have granularity on the account or on the
delegation (everything whose RDN has "cn" as naming attribute is fine) but
I assume that's what you want.  In the latter case you can narrow the
selection by adding a filter on the objectClass of the delegation.

Hope it helps.