Access Control
 | Screencast |
The access control instruction (ACI) can be defined in the conf/mapping.xml.
<entry dn="ou=users,dc=example,dc=com"> ... <aci subject="..."> <dn>...</dn> <target>...</target> <attributes>...</attributes> <scope>...</scope> <action>...</action> <permission>...</permission> </aci> </entry>
Subject
ACI's subject determines to which entity the ACI is applicable.
| Subject | Description |
|---|---|
| anybody | Anybody (default) |
| anonymous | Unauthenticated users |
| authenticated | Authenticated users |
| self | User accessing his/her own entry |
| user | A specific user |
| group | Members of a specific group (not supported) |
The root user always has access to anything.
Distinguished Name
The <dn>...</dn> element is only required when the subject is set to "user" or "group". The value is the DN of the user or group.
Target
ACI's target determines whether the ACI is applied to the entire object or only to some attributes.
| Target | Description |
|---|---|
| OBJECT | The entry where the ACI is defined (default) |
| ATTRIBUTES | The entry's attributes where the ACI is defined |
Attributes
The <attributes>...</attributes> is only required when the target is set to ATTRIBUTES.
Scope
ACI's scope determines whether the ACI will be propagated to the decendants.
| Scope | Description |
|---|---|
| SUBTREE | The ACI will affect the subtree based on this entry (default) |
| OBJECT | The ACI will affect this entry only |
Action
ACI's action determines whether to grant/deny the permissions.
| Action | Description |
|---|---|
| grant | Granting permission (default) |
| deny | Denying permission |
Permission
ACI's permission determines the type of operation being granted/denied.
| Permission | Description |
|---|---|
| r | Permission to read this entry |
| w | Permission to modify this entry |
| s | Permission to search this entry |
| a | Permission to add a child entry |
| d | Permission to delete this entry |
Evaluation
ACI's are evaluated starting from the root entry, then moving down to the target entry. Within an entry, the ACI's are evaluated in the order they are defined, from top to bottom. The evaluation stops as soon as it finds an ACI that explicitly grants/denies permission for the subject.
Examples
The example files are available in PENROSE_SERVER_HOME/samples/acl.
See the partition/mapping.xml:
<entry dn="dc=ACL,dc=Example,dc=com">
...
<aci>
<permission>rs</permission>
</aci>
</entry>
The above ACI gives rights to anybody to view this entry and its children (unless overriden by the ACI defined in the children).
Then see this child entry:
<entry dn="cn=Manager,dc=ACL,dc=Example,dc=com"> ... <aci subject="self"> <permission>rs</permission> </aci> <aci> <action>deny</action> <permission>rs</permission> </aci> </entry>
The first ACI gives the manager (cn=Manager,dc=ACL,dc=Example,dc=com) the right to view itself. The second ACI hides this entry from anybody else, overriding the ACI defined in its parent.
Next see another child entry which is the top entry of a subtree:
<entry dn="ou=Users,dc=ACL,dc=Example,dc=com"> ... <aci subject="anonymous"> <action>deny</action> <permission>rs</permission> </aci> </entry>
The above ACI hides this subtree from anonymous users. However, anybody else (i.e. authenticated users) are still able to view it because this right has been inherited from the parent.
Then see this dynamic entry:
<entry dn="uid=...,ou=Users,dc=ACL,dc=Example,dc=com"> .. <aci subject="self"> <permission>rws</permission> </aci> <aci subject="user"> <dn>cn=Manager,dc=ACL,dc=Example,dc=com</dn> <target>ATTRIBUTES</target> <attributes>userPassword</attributes> <action>deny</action> <permission>rs</permission> </aci> <aci subject="user"> <dn>cn=Manager,dc=ACL,dc=Example,dc=com</dn> <permission>rws</permission> </aci> <aci> <action>deny</action> <permission>rs</permission> </aci> </entry>
The first ACI allows each dynamic entry to view and update itself. The second ACI prevents the manager from reading the userPassword attribute, but the third ACI grants the manager the right to view and update any attributes in the entry. This means that the manager can change the userPassword but cannot read it. The fourth ACI prevents anybody else from viewing the dynamic entries.
If you search anonymously it will return only the root entry:
ldapsearch -h localhost -p 10389 -x -b "dc=ACL,dc=Example,dc=com"
dn: dc=ACL,dc=Example,dc=com
objectClass: dcObject
objectClass: organization
dc: ACL
o: ACL
If you search as one of the dynamic user, you will get this:
ldapsearch -h localhost -p 10389 -D uid=swhite,ou=Users,dc=ACL,dc=Example,dc=com -w swh1t3 -x -b "dc=ACL,dc=Example,dc=com"
dn: dc=ACL,dc=Example,dc=com
objectClass: dcObject
objectClass: organization
dc: ACL
o: ACL
dn: ou=Users,dc=ACL,dc=Example,dc=com
objectClass: organizationalUnit
ou: Users
dn: uid=swhite,ou=Users,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: swhite
userPassword:: c3doMXQz
sn: White
If you search as the manager, you will get all entries minus the userPassword attribute of the dynamic users.
ldapsearch -h localhost -p 10389 -D cn=Manager,dc=ACL,dc=Example,dc=com -w secret -x -b "dc=ACL,dc=Example,dc=com"
dn: dc=ACL,dc=Example,dc=com
objectClass: dcObject
objectClass: organization
dc: ACL
o: ACL
dn: cn=Manager,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword:: c2VjcmV0
sn: Manager
cn: Manager
dn: ou=Users,dc=ACL,dc=Example,dc=com
objectClass: organizationalUnit
ou: Users
dn: uid=jstockton,ou=Users,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: jstockton
sn: Stockton
cn: Jim Stockton
dn: uid=lwalker,ou=Users,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: lwalker
sn: Walker
cn: Lee Walker
...
If you search as the admin user you will get everything:
ldapsearch -h localhost -p 10389 -D uid=admin,ou=system -w secret -x -b "dc=ACL,dc=Example,dc=com"
dn: dc=ACL,dc=Example,dc=com
objectClass: dcObject
objectClass: organization
dc: ACL
o: ACL
dn: cn=Manager,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword:: c2VjcmV0
sn: Manager
cn: Manager
dn: ou=Users,dc=ACL,dc=Example,dc=com
objectClass: organizationalUnit
ou: Users
dn: uid=jstockton,ou=Users,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: jstockton
userPassword:: ajV0MGNrdDBu
sn: Stockton
cn: Jim Stockton
dn: uid=lwalker,ou=Users,dc=ACL,dc=Example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: lwalker
userPassword:: bHc0bGszcg==
sn: Walker
cn: Lee Walker
...