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:
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
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
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"
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.
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.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code