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

[Petr Vobornik]

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.

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?


> 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.

-- 
Petr Vobornik