[Freeipa-devel] Krb service delegation rules in CLI

[Simo Sorce]

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.


-- 
Simo Sorce * Red Hat, Inc * New York