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? > 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. bye, Sumit > > 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