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

[Jan Cholasta]

Dne 27.5.2015 v 19:38 Rob Crittenden napsal(a):
> 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={..,..}

+1, but I would split servicedelegationrule-{add,remove}-member into 
separate commands:

servicedelegationrule-add-member --principals=
servicedelegationrule-remove-member --principals=
servicedelegationrule-add-target --targets=
servicedelegationrule-remove-target --targets=

because one means "services which can delegate" and the other "services 
to which can be delegated".

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

+1

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

I very much agree.

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


-- 
Jan Cholasta