[Freeipa-users] Custom ACI entries

[Rob Crittenden]

Lucas Yamanishi wrote:
> On 05/17/2012 09:34 AM, Rob Crittenden wrote:
>> ...
>>
>> The ACIs need a little bit of work. The name of the aci needs to
>> match the name of the ACI that permission is being granted to, with a
>> prefix of permission:. So it should look more like:
>>
>> aci: (targetattr =  "attribute1 ||  attribute2 ||  attribute3")
>> (version 3.0; acl "permission:Read custom attributes"; deny (all)
>> (userdn = "ldap:///anyone" and userdn != "ldap:///self" and groupdn
>> != "ldap:///cn=Read custom
>> attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
>>
>> For the second ACI you don't need add and delete, those are
>> entry-level permissions. You might want to add compare though.
>>
>> We also tend to separate things you can do to your own entry from
>> things you can do to others. So we would break this out into some
>> selfservice ACIs and permission ACIs. Not saying what you're doing
>> won't work.
>>
>> rob
>
> BTW, what's the origin of the naming restrictions?  Is it an IPA thing?

Yes, we are trying to hide the complexity of ACIs behind the permission 
concept. We take advantage of nested group membership and use that to 
delegate access. We create an ACI that grants permission to do something 
to a group (in this case a permission). This permission is then a member 
of a privilege which is a member of a role which itself has users, 
groups, etc as members. So being a member of a role grants access to all 
permissions associated with it.

An ACI is just a string of text so we need some mechanism to link an ACI 
with a permission object so we use this comment/name section. We added a 
prefix to distinguish between selfservice permissions and normal 
permissions (and perhaps future prefixes as well).

>
> Here are my updated ACIs:
>
> <pre>
>
> dn: dc=sesda2,dc=com
> changetype: modify
> add: aci
> aci: (targetattr =
>    "privateAttribute1 ||
>    privateAttribute2 ||
>    privateAttribute3 ||
>    privateAttribute4")
>   (version 3.0; acl "permission:Read custom attributes"; deny (all)
>    (userdn = "ldap:///anyone" and
>    groupdn != "ldap:///cn=Read custom
> attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
>
> dn: dc=sesda2,dc=com
> changetype: modify
> add: aci
> aci: (targetattr =
>    "privateAttribute1 ||
>    privateAttribute2")
>   (version 3.0; acl "permission:Does this need a special name?"; allow
> (read, search, compare)
>    userdn = "ldap:///self";)

Use the prefix selfservice and name it something like: selfservice: 
Users can read their own private attributes

> dn: dc=sesda2,dc=com
> changetype: modify
> add: aci
> aci: (targetattr =
>    "privateAttribute1 ||
>    privateAttribute2 ||
>    privateAttribute3 ||
>    privateAttribute4")
>   (version 3.0; acl "permission:Manage custom attributes"; allow
> (read, write, search, compare)
>    groupdn = "ldap:///cn=Manage custom
> attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com";)

Otherwise looks ok. ACIs often have subtle problems so I'd test 
casefully. Assuming these work ok you might try enhancing them to limit 
their scope to just users by adding (target = 
"ldap:///uid=*,cn=users,cn=accounts,dc=sesda2,dc=com"). This might speed 
up ACI processing ever so slightly, and ever ms counts.

rob