ACL for Constrained Delegation?
Simo Sorce
simo at redhat.com
Thu Feb 20 22:27:37 EST 2014
On Fri, 2014-02-21 at 00:05 +0100, Rick van Rein wrote:
> Hi Simo,
>
> > In the default case you generally allow all in these situations.
>
> You mean, you’d like to be able to add the ACL class, no further
> attributes and then let everyone in? Why then mention the ACL, I
> wonder.
No, the only attribute that is allowed to be missing is
AllowedToImpersonate. If any other one is missing you get no
authorization.
> The rest of the ACL design says “…and if none of the rules match, than
> the answer is NO” and the exception for “unless there is no ACL rule,
> then it is YES” is an inconsistency in the structure. Such flipping
> points are usually where error and dismay are born.
You misunderstood how this works, if there is no target or member
principal there is nothing to match, so no ACL apply so no access is
granted.
>
> > This compromise comes fro the fact that there is no real grouping
> > mechanism in the KDC nor a way to experess the concept of "all", a regex
> > would not really do it nuless you are thinking of ".*”
>
> I was thinking of that regex, yes, but didn’t know what syntax to
> write down :) It’d be a group named ALL, in your example.
Unfortunately AlowToImpersonate is not a free form field, we'd need to
add something else.
> > We could change the code so that you have to add the literal "ALL"
> > maybe, I am not opposed, and could easily migrate FreeIPA users to that
> > syntax.
>
> That last bit is impressive :)
Unfortunately I kind of have to take it back.
I forgot that AllowToImpersonate has actually DN syntax, so you cannot
simply store "ALL" in there. We would need to standardize a DN that
represent all users or add a separate attribute to define 'categories'
as an additional filter.
This was the actual reason why the default is 'all' when it is missing,
mostly because all our use cases allow a specific service to proxy any
users but only for specific targets. After all it makes no sense to have
no allowed clients (why would you create an ACI if that were the case,
absence of an ACI already prevents access).
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Kerberos
mailing list