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

[Rob Crittenden]

Petr Vobornik wrote:
> On 05/27/2015 05:46 PM, 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.
>
> It could tolerated in automember given that hostgroup and group rules
> have exactly the same schema and purpose. The only difference is a
> different target.
>
> On the other hand, here, the purpose of both types is different. One is
> a rule, second a target. Separation of the names would tell it to the
> users.
>
> Number of API commands is a topic for different discussion. In short, it
> could be handled better in CLI and future doc.
>
> I don't want to discuss implementation details(complexity) yet. Issue
> with API is that we are stuck with it and can't change it(much).
>
>>>
>>> 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 understand that. The existing delegation might be misleading and
> should be distinguished from s4u2. But imagine that somebody told you
> that he created a new "service constraint rule of service A to service
> B". Since there is no mention of word delegation nor S4U I wouldn't know
> that it's related to ticket delegation. I would think the *opposite*.
> That he constrained service A to do something with service B. But a
> "service delegation rule", "constrained delegation rule" or "ticket
> delegation rule" says what it is actually about.
>
> Rather than avoiding descriptive commands we should improve a speed bash
> completion.

Perhaps, but it still possible to be excessive.

>
> A feeble attempt to remove service from the object name:
> A question: Even thought the kerberos feature is called S4U (service for
> user), is it limited to service principals? Services are of course the
> primary target but in theory they don't have to be, right?

What is the user case for non-services? Sure, you could probably use 
this to allow paul to get an ldap ticket for dave, but why would you? It 
would be nice for delegating calendar entries for a personal assistant, 
for example, but would be an audit nightmare.

>
>> 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).
>
> I don't think this part is affected at all. The API's have the same
> capabilities.
>

I'm not going to argue too much about this. I imagine that a vast 
majority of users will never use this at all, and even then probably not 
more than once or twice, so adding a ton of new commands seems like 
major overkill to me.

rob