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

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