[Freeipa-devel] Proposal about ACI management in IPA v2

Fri Oct 8 21:20:23 UTC 2010

Rob Crittenden wrote:
> Dmitri Pal wrote:
>> Hello,
>>
>> For some background see: http://www.freeipa.com/page/Access_Control
>>
>> I took a look at the ACIs in DS. An ACI consists of 6 parts:
>> 1) Name
>> 2) Users and Groups that the permission is granted to
>> 3) The right (read, write, add, delete etc)
>> 4) Target - an object against which the operation is performed
>> effectively an LDAP filter
>> 5) Host - to have different rules for different clients (not interesting
>> for now)
>> 6) Time when the rule is active (we will assume all).
>
> I don't agree with this simplification. I'll try to comment in-line.
>
> An ACI has 3 parts: the target, the permissions and who are you 
> granting the rights to (the bind rule). They affect more than just 
> users and groups. They affect anything in the system, or everything in 
> the system. They can control any object in the tree: users, groups, 
> hosts, hostgroups, netgroups, services, hbac, sudo, etc. or attributes 
> in any object.
>
> There is also the placement of the ACI which controls what it affects. 
> We currently place all ACIs in the basedn of the tree (a necessary 
> simplification for now).
>
>> Our goal is to provide and easy to was to specify and manage ACIs vi UI
>> and CLI.
>> To accomplish this goal we need to provide a much simple abstraction
>> that can be reused  for CLI and UI.
>> But first let us limit the ACI itself and leave only the parts that are
>> really needed.
>> We really need Name, User/Group, Right and Target. We will not do
>> anything about Host and Time.
>> The right can be limited to:
>> write, add, delete.
>> Assume that any authenticated user can read, search and compare. We
>> should also assume that every user can manage a predefined subset of the
>> attributes in his entry. So we actually talking about three rights here:
>> add, delete and modify. For the sake of IPA v2 I am willing to go even
>> further in simplifying ACIs and say that there are three kinds of 
>> rights:
>> * full control which translates into add an object, delete an object and
>> modify any attribute (this is a superuser mode)
>> * operational control which translates into add an object, delete an
>> object and modify a predefined subset of the attributes
>> * tuneup control which translates into add an object, delete an object
>> and modify a predefined subset of the attributes
>
> Read is rather important, particularly for things like userPassword. 
> But yes, most acis will use either add, delete or write.
>
> Don't assume that users can manage their own entries. This in itself 
> is an ACI that people will want to control.
>
> I know we have to start somewhere with the rights abstractions but I 
> think these controls will be misunderstood and lead to problems.
>
>>
>> Target is the most complex one it consists from the attributes and
>> filters. This is where an abstraction will be really helpful.
>> For this I suggest we create an ACI helper object class. The object
>> class will consist of the following attributes
>> name - a unique name of the helper like: User - full control, User -
>> standard management, User - limited access, etc
>> filter - single value string attribute that denotes a filter that allows
>> to identify the object the helper applies to
>> right - a multi value attribute that specifies rights, in out cases
>> based on the three operations above it will be either triplet add,
>> modify, delete or just modify
>> attributes - a multi value string attribute that stores the set of
>> attributes the ACI applies to
>> negation - a boolean flag that specified how to interpret the attribute
>> list i.e. are those the attributes that the rule applies to or they are
>> the attributes excluded from the rule.
>>
>> here is the example:
>>
>> dn: cn=User - full control, cn=ipaconfig, dc=somewhere, dc=com
>> objectclass: ipaACIHelper
>> cn: User - full control
>> filter: ...
>> attributes: password
>> nagation: true
>
> I can see what you are trying to do but I am really, very strongly 
> against this. We can manage this data internally just as easily. I 
> think this is a recipe for getting the acis out of sync.
>
> We actually have most of this implemented today. What it lacks is a 
> way to *output* an aci so it can be easily represented in a UI or on 
> the command line. That is where our focus should be.
>
> I'm not sure I agree with the full/object/etc abstractions, I think 
> they would be easily abused/misunderstood because the definitions of 
> these aren't obvious (and don't actually grant what you might expect 
> them to).
>
> You also have to understand how the tree is put together and how we 
> use it. For example, to add a user you need 3 acis:
> - an aci to add a user to the tree
> - an aci granting permission to write the password
> - an aci granting permission to add a member to a group
>
> Also, the 389-ds team has very strong recommended against using deny 
> ACIs in the past which is why I don't support them in the current plugin.
>
>>
>> This is just an example and we can sort out the right names so do not
>> pick me if the attribute already exists and we should reuse it. It is
>> semantics at the moment.
>>
>> Any ACI has a name. We need to allow advanced administrators (and
>> ourselves) to manage raw ACIs. On the other hand we need to allow
>> managing "simplified" ACIs in CLI and UI.
>> For this I suggest we use the following linking between the actual ACIs
>> and helper object:
>> The ACI name will store a DN of the helper object.
>>
>> Let us look at the commands that associate ACIs with a "taskgroup":
>>
>> ipa aci-add -aci='User - full control ' taskgroup
>>
>> for this command the management plugin will will lookup helper object
>> and create an ACI based on the data stored in the helper object.
>>
>> ipa aci-del -aci='User - full control' taskgroup
>>
>> for this command the management plugin will find the aci that has the
>> name equal to the DN of the specified helper object.
>>
>> ipa aci-find -aci='User - full control' taskgroup
>>
>> will find the helper object by name, find an ACI by the DN of the helper
>> object.
>>
>> ipa aci-list  taskgroup
>
>>
>> will list the ACIs for the taskgroup. If the ACI name is a DN of a
>> helper object the contents of the helper object will be displayed. If
>> the ACI doe not map to the helper object then it will not be shown.
>>
>> This way only the ACIs that are attached to helper objects will be
>> visible through the UI and CLI and custom CLIs created by IPA at the
>> installation or CLIs created manually by admins will be accessible 
>> via LDAP.
>>
>> The helper object will be preloaded and predefined and thus not
>> replicated. This means that each new extension to IPA will need to add
>> its own helper entries. For SUDO for example it will be probably couple
>> entries. One to do everything and another to modify a subset of the
>> attributes in the rule.
>
> ACIs are ACIs. There is nothing a plugin would add except perhaps a 
> part of the DIT. See the type enum currently in the plugin.
>
>> What is good about this approach is that later we can add an interface
>> to create helper objects. Those are much better structured and would be
>> easier to manage. For example instead of actually typing filter we can
>> have a selectable list of the objects like "user", "group", "sudo",
>> "hbac rule" etc. (The mapping between name and actual filter might be
>> stored in another kind of the helper object - but we will get there
>> later). Yes that would mean that the admin would have to create a helper
>> object then to create ACI using this object, then combine the task into
>> role but it is manageable because the complex task is decomposed into
>> logical parts. I do not suggest that we do it in v2 but I think it is a
>> way to go in general in future.
>
> We actually have these objects implemented in the current plugin. The 
> following aci commands all work today:
>
> You can say "This taskgroup can add users":
>
> ipa aci-add 'Add Users' --type=user --taskgroup=add_users 
> --permissions=add
>
> This creates the aci:
>
> (target = 
> "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com")(version 
> 3.0;acl "Add Users";allow (add) groupdn = 
> "ldap:///cn=add_users,cn=taskgroups,cn=accounts,dc=example,dc=com";)
>
> It will even create the taskgroup for you if it doesn't already exist.
>
> Right now I just have defined users, groups and hosts but it is 
> trivial to add the others. I couldn't think of a reason the would want 
> this since we supply pre-canned versions of add/delete/modify for 
> those on install, but I can add them as options if desired.
>
> We also need to cover v1-style delegation: group A can write 
> attributes of group B.
>
> Secretaries can write the mailing address of engineers:
>
> ipa aci-add --attrs=streetAddress,postalCode,c,l,st 
> --memberof=engineering --group=secretaries --permissions=write 
> "Secretaries can write engineering addresses"
>
> (targetattr = "streetAddress || postalCode || c || l || 
> st")(targetfilter = 
> "(memberOf=cn=secretaries,cn=groups,cn=accounts,dc=example,dc=com)")(version 
> 3.0;acl "Secretaries can write engineering addresses";allow (write) 
> groupdn = 
> "ldap:///cn=secretaries,cn=groups,cn=accounts,dc=example,dc=com";)
>
> Or even simple things like "I want my engineers to be able to add hosts"
>
> ipa aci-add --type=host --permissions=write --group=engineering 
> 'Engineers can add hosts'
>
> (target = 
> "ldap:///fqdn=*,cn=computers,cn=accounts,dc=example,dc=com")(version 
> 3.0;acl "Engineers can add hosts";allow (write) groupdn = 
> "ldap:///cn=engineering,cn=groups,cn=accounts,dc=example,dc=com";)
>
> Ideally these would be mostly done through existing taskgroups instead:
>
> ipa taskgroup-add-member --groups=engineering addhosts
>
> Or even more preferably via rolegroups:
>
> ipa rolegroup-add-member --groups=engineering hostadmin
>
> The aci's here are actual output from the plugin. This is where we 
> need the work. I already have an internal abstraction of the acis so I 
> can operate on them. I merely need to display this instead of the aci 
> string and I think we'll be good to go. Some way to manage the 
> attribute list without requiring one to type the whole thing would be 
> nice too.
>
>>
>> Hope this approach does not have much flaws. Yes it will require some
>> work in the ACI space but I hope it is not a huge rework.
>>
>
> This would represent a tremendous amount of work. I think we would be 
> better served fixing the way that acis are output so the UI (and by 
> extension cli) can better represent the data to users. The --raw 
> option can display the raw aci.
>
> Working with acis is always going to be a bit of a nasty business 
> because by definition you have to deal directly with LDAP attribute 
> names, the DIT and how we create and manage objects in the framework.
Might I suggest looking at the ACI editor in the 389-console - IMHO it 
hides as much as it can - one big problem is the fact that we do not 
have a client side ACI parser.
>
> rob
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel