[Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin

[Simo Sorce]

On Wed, 2015-05-27 at 18:46 +0300, Alexander Bokovoy wrote:
> On Wed, 27 May 2015, Rob Crittenden wrote:
> >Petr Vobornik wrote:
> >>On 05/20/2015 06:02 PM, Rob Crittenden wrote:
> >>>Rob Crittenden wrote:
> >>>>Rob Crittenden wrote:
> >>>>>Add a plugin to manage service delegations, like the one allowing the
> >>>>>HTTP service to obtain an ldap service ticket on behalf of the user.
> >>>>>
> >>>>>This does not include impersonation targets, so one cannot yet limit by
> >>>>>user what tickets can be obtained.
> >>>>>
> >>>>>There is also no referential integrity for the memberPrincipal
> >>>>>attribute
> >>>>>since it is a string and not a DN. I don't see a way around this that
> >>>>>isn't either clunky or requires a 389-ds plugin, both of which are
> >>>>>overkill in this case IMHO.
> >>>>>
> >>>>>If you wonder why all the overrides it's because all of this is stored
> >>>>>in the same container, and membership-like functions are used for a
> >>>>>non-DN attribute (memberPrincipal).
> >>>>>
> >>>>>I used Alexander's patch in the ticket as a jumping off point.
> >>>>
> >>>>Removed a couple of hardcoded domain/realm elements in the tests.
> >>>
> >>>I must be getting rustly. Forgot to include ACIs. Added now.
> >>>
> >>>rob
> >>>
> >>
> >>Thanks for the design[1] and patches.
> >>
> >>First some high level questions before any unnecessary changes are made.
> >>
> >> From API point of view wouldn't it be better to distinguish rules and
> >>targets by object name so we could avoid usage of the --type option.
> >>I.e., why expose internal schema limitations in the API?
> >>
> >>Type could be implied by the object name and commands can do what they
> >>do now. They could even have a common base class if needed.
> >>
> >>E.g.:
> >>
> >>servicedelegationrule-add MYRULE
> >>servicedelegationrule-find
> >>servicedelegationrule-del MYRULE
> >>servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
> >>--principals={..,..}
> >>servicedelegationrule-remove_member MYRULE
> >>--targets={MYTARGET,MYTARGET2} --principals={..,..}
> >>
> >>servicedelegationtarget-add MYTARGET
> >>servicedelegationtarget-find
> >>servicedelegationtarget-del MYTARGET
> >>servicedelegationtarget-add_member MYTARGET --principals={..,..}
> >>servicedelegationtarget-remove_member MYTARGET --principals={..,..}
> >>
> >>Yes, I used delegation instead of constraint. What is the rationale
> >>behind 'constraint'? To me 'constraint' specifies what kind of
> >>delegation we want to set but a goal of S4U2 proxy is to allow something
> >>which is not allowed by default not to create a new constraint.
> >>
> >>[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
> >
> >I considered that but we already have this precedent in automember so 
> >I went with it. This is complex enough with the fake memberPrincipal 
> >stuff, I don't want to explode it with a baseclass and two subclasses 
> >as well, plus doubling the number of new API commands.
> >
> >Technically this is called constrained delegation. I was trying to 
> >keep the name short and still descriptive. There is already aci 
> >delegation which is a completely separate thing.
> I agree with Rob. There is also a need to address principals which
> aren't directly accessible as IPA objects in the framework (think about
> trusts, for example). 

Shouldn't the commands then be: constraineddelegation-add etc...
serviceconstraint doesn't really help understanding what this is all
about. If service is in the name I agree with Petr that
servicedelegation makes much more sense.

On the API I also do not like to split rules into 2 apis, but I see no
other option really.

Something like the following makes it clear what you are operating on:
ipa servicedelegationtarget-add <target> [principals]
ipa servicedelegation-add <rule> --members [principals] --targets [targets]

Example:
ipa servicedelegationtarget-add ipa-ldap ldap/ipa1.example.com
ldap/ipa2.example.com
This would add ldap/ipa1.example.com at EXAMPLE.COM and
ldap/ipa2.example.com at EXAMPLE.COM to cn=ipa-ldap-delegation-targets
(note that rule name is shorter than DN and principals are automatically
augmented with the REALM part if not provided on the command line)

ipa servicedelegation-add ipa-http --targets ipa-ldap
This would create the cn=ipa-http-delegation rule and add
cn=ipa-ldap-delegation-targets,... to it (note again that the rule name
and target name are shortcuts wrt the actual DNs used)

ipa servicedelegation-mod ipa-http --add-members HTTP/ipa1.example.com
HTTP/ipa2.example.com
This would add member principals to cn=ipa-http-delegation


The full list of APIs would be:
ipa servicedelegation-add <rule> [--members principals] [--targets targets]
ipa servicedelegation-del <rule>
ipa servicedelegation-mod <rule> [--add-members Ps] [--del-members Ps] [--add-targets Ts] [--del-targets Ts]
ipa servicedelegation-show <rule>
ipa servicedelegation-find [rule]

ipa servicedelegtarget-add <target> [--members principals]
ipa servicedelegtarget-del <target>
ipa servicedelegtarget-mod <target> [--add-members Ps] [--del-members Ps]
ipa servicedelegtarget-show <target>
ipa servicedelegtarget-find [target]


HTH,
Simo.



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