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