[Freeipa-devel] Krb service delegation rules in CLI

[Martin Kosek]

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.

Martin