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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
