[Freeipa-devel] Krb service delegation rules in CLI

[Martin Kosek]

On 09/23/2014 08:58 PM, Simo Sorce wrote:
> On Tue, 23 Sep 2014 17:18:38 +0200
> Martin Kosek <mkosek at redhat.com> wrote:
> 
>> On 09/22/2014 09:48 PM, Alexander Bokovoy wrote:
>>> On Mon, 22 Sep 2014, Martin Basti wrote:
>>>> Hello,
>>>>
>>>> Related ticket: https://fedorahosted.org/freeipa/ticket/3644
>>>>
>>>>
>>>> 1) API
>>>>
>>>> The ipaKrb5DelegationACL objectclass requires targets which are
>>>> stored in extra objectclass.
>>>>
>>>> A) we allow users to create groups of principals and then
>>>> associate them as targets -- user can use same group for multiple
>>>> delegation ACL
>>>>
>>>> B) users specify only list of target principals (no groups)
>>>>
>>>> B seems better to me.
>>> No.
>>>
>>> You have three clearly separate object types here:
>>>
>>> 1. Principals -- any object in the tree that has krbPrincipalAux
>>> supplemental auxiliary object class. These objects can be anywhere
>>> in the tree, we can decide on limiting subtrees to search.
>>>
>>> 2. Delegation ACLs -- any object that has ipaKrb5DelegationACL
>>> supplemental structural object class. These objects can be anywhere
>>> under cn=s4u2proxy,$SUFFIX
>>>
>>> 3. Groups of principals  -- any object that has groupOfPrincipals
>>> _and_ doesn't have ipaKrb5DelegationACL object classes. These
>>> objects can be anywhere in the tree, we can decide on limiting
>>> subtrees to search and can decide on a specific subtree to put new
>>> groups of principals.
>>>
>>> For (1) you just need to be able to reference principals, this only
>>> requires a search filter to define DN of the principal based on
>>> krbPrincipalName or krbCanonicalName, with support for 'shortcuts'
>>> (specifying principal without realm which is our realm).
>>>
>>> (1) is only used to resolve principals for (2) and (3).
>>>
>>> For (2) you need to implement a proper object handling, like any
>>> other IPA object that supports:
>>>  -- multiple values for ipaAllowToImpersonate
>>>  -- multiple values for ipaAllowedTarget
>>> CLI would look something like this:
>>>  ipa krbdelegation-add
>>>                   -show
>>>                   -find
>>>                   -mod
>>>                   -add-source
>>>                   -add-target
>>>                   -del-source
>>>                   -del-target
>>>                   -del
>>>
>>> For (3) you need to implement a proper object handling where
>>> creating the object would happen in the predefined subtree but
>>> search or modify would be possible for any object matched by a
>>> proper filter.
>>>
>>> CLI would look something like this:
>>>  ipa krbprincipalgroup-add
>>>                       -show
>>>                       -find
>>>                       -mod
>>>                       -add-member
>>>                       -del-member
>>>
>>>
>>> The way we use right now groupOfPrincipals, the objects referenced
>>> are placed in different subtrees, according to their primary role.
>>> That's right, as krbPrincipalAux is an auxiliary class, and is
>>> added on top of other object classes to turn other objects into
>>> principals. We also use groupOfPrincipals not only for Kerberos
>>> delegation ACLs, that's why support for multiple subtrees is needed.
>>>
>>> Creating new groupOfPrincipals objects can be allowed in a single
>>> designated place, cn=s4u2proxy,$SUFFIX, because this is primary use
>>> of this API.
>>
>> Alexander's proposal makes sense to me. I would just personally name
>> the commands differently to share the same prefix. I.e.
>>
>> ipa krbdelegation-*
>> and
>> ipa krbdelegationgroup-*
>>
>> as we are not creating general purpose principal groups but only
>> groups for S4U2Proxy usage.
>>
>> I would also reconsider your request to search for the objects in the
>> whole s4u2proxy tree. Across FreeIPA framework, we handle objects in
>> static and defined location of our tree, not in the entire subtree.
>>
>> I think we should although indeed consider adding group of principals
>> to own nsContainer (like cn=targets) as otherwise we will have a
>> clash between krbdelegation rule names and krbdelegationgroup names.
> 
> Keep in mind that we already have a few rules in there and the groups
> are in the same container, the names are different as the groups are
> named <rule-name>-targets, so we'll have to keep using a subtree
> search, but that is fine cn=s4u2proxy has no subtree atm.
> 
> Simo.

Ok, it is true I was also thinking how to deal with existing s4u2 proxy rules.
It would be best to simply move current targets to cn=targets too, but if they
are already referred to from elsewhere it may be a too drastic move (though
would allow us to start with clean approach and no exceptions).

However, I still think we should have a special container for user custom rules
(cn=targets or similar) to not deal with name clashes on targets groups and
delegation rules.

Martin