On Mon, Jan 09, 2017 at 08:46:22AM +0100, Jan Cholasta wrote: > On 6.1.2017 10:30, Sumit Bose wrote: > > On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: > > > On 5.1.2017 10:39, Sumit Bose wrote: > > > > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > > > > > On 18.10.2016 07:34, Jan Cholasta wrote: > > > > > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > > > > > Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > > > > > ===== Issuer specific matching ===== > > > > > > > > > Although the MIT Kerberos rules allow to select the issuer of > > > > > > > > > a > > > > > > > > > certificate there are use cases where a more specific > > > > > > > > > selection is > > > > > > > > > needed. E.g. if there are some default matching rules for all > > > > > > > > > issuers > > > > > > > > > and some other issuer specific rules where the default rules > > > > > > > > > should > > > > > > > > > not apply. To make this possible with the above scheme the > > > > > > > > > default > > > > > > > > > rules must have an <ISSUER> clause which matches all but the > > > > > > > > > issuer > > > > > > > > > with the specific rules. Writing regular-expressions to not > > > > > > > > > match a > > > > > > > > > specific string or a list of strings is at least error-prone > > > > > > > > > if not > > > > > > > > > impossible. > > > > > > > > > > > > > > > > > > To make it easier to define issuer specific rules and default > > > > > > > > > rules at > > > > > > > > > the same time and optional issuer string can be added to the > > > > > > > > > rule to > > > > > > > > > indicate that for the given issuer only those rules should be > > > > > > > > > considered. Given the use-case I think it is acceptable to > > > > > > > > > require > > > > > > > > > that the full issuer must be specified here in LDAP order > > > > > > > > > (see below) > > > > > > > > > and case-sensitive matching is used. > > > > > > > > > > > > > > > > This could also be solved by adding priority to rules - if two > > > > > > > > rules > > > > > > > > match, the one with higher priority (the issuer specific rule) > > > > > > > > is > > > > > > > > preferred over the one with lower priority (the default rule). > > > > > > > > IMO this > > > > > > > > is better than an optional issuer string as it offers greater > > > > > > > > flexibility. > > > > > > > > > > > > > > The use cases I've seen haven't had to do with priority, though > > > > > > > that > > > > > > > would be a nice enhancement, but with only allowing certificates > > > > > > > issued > > > > > > > by a specific CA to be allowed (this is pretty common in web > > > > > > > servers). > > > > > > > Being able to say "only do the matching on certificates issued by > > > > > > > foo" > > > > > > > is valuable. > > > > > > > > > > > > Sure, I'm not suggesting that matching by issuer should be removed, > > > > > > only > > > > > > that rule precedence should not be determined by the issuer field > > > > > > setting. > > > > > > > > > > > > > > > > Bump. Sumit, what is your opinion on this? > > > > > > > > I'm fine with an optional(?) priority as well. Since priorities are > > > > already used in the pwpolicies this should be already known to the > > > > experienced admin. I guess we just have stick with "A lower value > > > > indicates a higher priority" to not confuse users. That's why I think > > > > that the priority should be optional here and a missing value indicates > > > > the lowest priority (default rules). > > > > > > In pwpolicy and sudorule, the priority is required and has to be unique. > > > Maybe we should do this for certificate mapping rules as well? > > > > I think there is no requirement that only a single rule should match > > hence I think the priority here must not be unique. > > Is there a requirement that it must be possible for multiple rules to match? > If not, we could begin with a simpler (for admin) solution with unique > priorities and lift the restriction later when/if it becomes necessary. But > I don't have a strong opinion on this.
me neither (I was hoping other people might chime in as well) My reasoning just was that not requiring uniqueness is more flexible (but of course it is easier to lift the restriction later than enforce it later). Additionally imo it would be simpler for the admin because the admin does not have to think about how to order a list of rules which are logically on the same level (e.g. rules for different issuers). But as said I do not have a strong opinion here either. bye, Sumit > > > > > > > > > > > > > > Are you thinking of using the CoS scheme here as well would a priority > > > > attribute be sufficient because we do not want to reference internal > > > > objects in the mapping rules? > > > > > > I'm not sure how CoS would be helpful here, I think a simple interger > > > attribute would be perfectly sufficient. > > > > I agree. > > > > bye, > > Sumit > > > > > > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > > -- > > > > > Jan Cholasta > > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org