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

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to