Sumit Bose wrote:
On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote:
Sumit Bose wrote:
Hi,
Wow, this is really great.
Hi Rob,
thank you for the feedback.
I think I'd pre-plan to support different configuration per issuer subject,
with one named default. It shouldn't be a lot more work and will
future-proof things for you, particularly in how the rules are stored in
LDAP.
I worry a bit about matching without comparing the certificate for the case
where you don't examine issuer.
Do I understand it correctly that you are looking for rules which will
always and only match for certificate from a given issuer? E.g. if all
matching rules will have the <ISSUER> set like
<ISSUER>CN=ca,DC=abd,DC=com<EKU>clientAuth
<ISSUER>CN=ca,DC=def,DC=com<EKU>msScLogin
certificates from the abc issue must have clientAuth set to be valid for
authentication and certificates from issuer def must have msScLogin set.
But you are right, if one rule does not have issuer set like
<ISSUER>CN=ca,DC=abd,DC=com<EKU>clientAuth
<EKU>msScLogin
then a certificate from issuer abc which does not have clientAuth set
but msScLogin would be accepted as well.
Do you think it would help to make <ISSUER> a required field but allow
that the lazy admin can just enter a '*' to match any issuer?
Yes, that is basically what I was proposing, and mostly to ensure that
the data is stored in such away that adding rules per issuer would be
easy/possible in the future. It probably hits 80/20 by supporting only a
single set of rules for the 1.0 release.
You may want to have an option to require that the presented cert match the
one stored in LDAP (off by default). I realize that you specifically mention
this can be problematic, but it can also be quite useful. It can be used,
for example, to disable a login by removing the certificate from the user's
entry. It also ensures that some carefully crafted certificate doesn't allow
a bad actor to map to a user account.
This happens when no mapping rule is given. Then SSSD will fall
back to search/map the user with the whole certificate. And if the
certificate is removed from the LDAP entry of the user Smartcard
authentication will fail as soon as the user entry in the cache of SSSD
is expired.
I wonder if some might want both at the same time. Match using rules and
then also confirm the certificate matches, if it is available in the
entry, with a require/optional setting to decide what to do in case the
cert isn't in LDAP.
rob
--
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
