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

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