On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote:
Sumit Bose wrote:
Wow, this is really great.
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
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
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
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?
You may want to have an option to require that the presented cert
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