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.

> 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


*question everything*learn something*answer nothing*
Lucas Yamanishi
Systems Administrator, ADNET Systems, Inc.
7515 Mission Drive, Suite A100
Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A

Freeipa-users mailing list

Reply via email to