[Freeipa-users] Custom ACI entries

[Dmitri Pal]

On 05/17/2012 10:47 AM, Lucas Yamanishi wrote:
> On 05/17/2012 09:34 AM, Rob Crittenden wrote:
>> Lucas Yamanishi wrote:
>>> Hi everybody,
>>>
>>> I've added some custom schema to my directory, but it's useless to me if
>>> if I can't control read permissions on it.  This is obviously a little
>>> tricky since (Free)IPA allows everybody to ready everything by default.
>>>   With that, what's the best way to restrict access to user attributes?
>>> Is there anything like this in the roadmap?
>> Right now there is are no plans to support deny ACIs natively in the
>> permission plugin. That isn't set into stone, we just need some convincing.
> Then let me make the case:
>
> I know IPA is aimed mainly at authentication and authorization, but it
> provides enough base schema and tree structure to do basic asset and
> personnel management.  More importantly, it's easier to setup than a
> pure 389 Directory.  This makes it ideal for small to medium sized
> organizations that don't need the extra utility a separate directory
> provides.  Additionaly, the well-designed webui makes it easy to
> delegate tasks to non-technical personnel.  The requirements to achieve
> this end are two: add native support for a restricted set of schema
> extensions and fine-grained access controls to those attributes.
>
> For schema extensions, support could (and should) be limited only to
> additional attributes on a restricted set of existing objects.  For
> example, additions to users and hosts.  This would satisfy requirements
> for a majority of small to medium sized organizations, I'd think.


Building a generic mechanism is really a lot of work.
It might be simpler to do it differently, i.e. incrementally add support
for additional attributes.
Do you have the schema that you added handy?
What is the application that uses it? Is it popular? Is it open source?
If it is it might make sense to just support these attributes our of box
if the schema is loaded.
 

>> The best way to do this is what you've done, manually creating ACIs. The
>> problem with deny ACIs is they can get very hard to unwind when trying
>> to figure out why things aren't working.
> How do you mean?
>
>>> For the interim I've crafted some custom aci entries.  Where should I
>>> put them?  Will they work?  Here they are:
>>>
>>>> aci: (targetattr =
>>>>    "attribute1 ||
>>>>    attribute2 ||
>>>>    attribute3")
>>>>   (version 3.0; acl "custom attributes base"; deny (all)
>>>>    (userdn = "ldap:///anyone" and
>>>>    userdn != "ldap:///self" and
>>>>    groupdn != "ldap:///cn=Read custom
>>>> attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
>>>>
>>>> aci: (targetattr =
>>>>    "attribute1 ||
>>>>    attribute2 ||
>>>>    attribute3")
>>>>   (version 3.0; acl "custom attributes update"; allow (add, read,
>>>> write, search, delete)
>>>>    (userdn = "ldap:///self" or
>>>>    groupdn = "ldap:///cn=Manage custom
>>>> attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
>>>
>> We put all ACIs into the basedn, so for you dc=sesda2,dc=com.
>>
>> This is going to be tricky since you want to delegate these but you
>> can't create them natively. This means you need to create both the aci
>> and the permission entry.
>>
>> A sample permission would look like:
>>
>> dn: cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com
>> objectClass: top
>> objectClass: groupofnames
>> objectClass: ipapermission
>> cn: Read custom attributes
> Can't I add these via "ipa permission-add" or the webui?
>
>> 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
>
> Thanks!
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/