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

[Rob Crittenden]

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.

rob