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

[Dmitri Pal]

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).

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

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

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.
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.

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.

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


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