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

Reply via email to